For a given software project, if the overarching audit department at our organization requires certain requirements...
to be met on the project (i.e, the use of a certain tool to manage project time, a project to have a clear quantifiable business objective documented and agreed to by the business, all contractual labor have a signed SOW, etc.), should the business analyst (BA) not capture these in their requirements document for the project? To me these are "project requirements" as stated by the audit department stakeholder and are required to be met by the project being undertaken. Please advise. I believe it's beneficial but am getting pushback from PLs. As a BA we want to ensure we capture all requirements for that project, both functionally and nonfunctionally.
If I'm understanding the question, it's referring to organizational requirements about the prescribed processes and procedures one must follow when performing any project in that organization. Ordinarily, such types of requirements would be maintained in a central manner for reference by participants on all projects. In this instance, it appears that the audit department is serving such a central role.
It doesn't hurt to note those project process requirements in the project documentation, but I think such note should be very brief and mainly refer back to the central posting. If use of particular project management tools is prescribed, then those tools should be used for capturing and updating relevant information about planned and actual tasks, resources and schedules involved in the business analysis. Statements of work (SOWs) are project management descriptions of the work to be carried out, such as to perform the business analysis and to implement a solution to meet the requirements identified in the business analysis. SOWs typically would not be included in the documents produced by a business analyst.
Typically, the bulk of the requirements a business analyst is charged with identifying relate to the project's content. Hopefully the organization understands that chances of project success are improved dramatically by first adequately identifying the REAL business requirements. Identifying clear quantifiable business objectives is a necessary start. It's important that the objectives be accurate, which too often is not the case and unfortunately is seldom recognized.
Realize that the objectives alone are not the REAL business requirements and are not sufficient for designing a product/system/software solution. Rather, REAL business requirements are business deliverable whats that provide value by achieving the objectives when delivered by a product/system/software solution how.
Such whats include business functionality, business rules and quality factors (which often are referred to, inappropriately I believe, as "nonfunctional") such as usability, security and performance. The whats need to be driven selectively down to further detail where they are sufficiently clear and complete. No matter how far down in detail they go, they continue to be business deliverable whats and never turn into hows. The hows are a response to the whats, which is why it's so important to first identify and detail those business requirements.
Dig Deeper on Penetration Testing
Related Q&A from Robin F. Goldsmith
Using a WBS can help make a big task like requirements easier. Expert Robin Goldsmith explains how developers and testers can make the most of this ... Continue Reading
How do you engage high-level business executives in the process of writing business requirements? Continue Reading
Why don't users seem to appreciate typical software QA testing status reports? Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.