What should a business analyst's requirements document include?

What should a business analyst's requirements document include?

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.

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

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.

This was first published in January 2009