Why are we working on this project?

Asking these 9 questions when exploring business requirements helps focus all stakeholders toward a common objective

Image by Gerd Altmann from Pixabay

Business requirements sit at the top of several three-level models of software requirements information (Wiegers and Beatty 2013, IIBA 2015). Business requirements include the information that guides creating a solution to achieve specific business results. They answer the question, “Why are we undertaking this project?” We explore business requirements to help align all project stakeholders toward the desired outcomes. Business requirements include statements of the business opportunities being created or exploited, objectives, success metrics, vision statement, and scope definitions.

Business requirements could originate from a senior manager who understands the problem, a primary customer who recognizes a need, or a product visionary who sees a market opportunity. Such people might already have established a business case for the effort. They might find it valuable to work with a BA to craft a richer set of business requirements.

The project manager (PM) or product owner (PO) has a strong interest in determining the business requirements. Perhaps the first question the PM or PO and business analyst (BA) must assess for any proposed requirement is whether it’s in scope for the overall project. You can’t make this judgment unless the scope has been determined based on the business objectives.

If a proposed requirement is out of scope, the team doesn’t need to think about it anymore (although it might come back into scope in the future.) If the requirement is in scope for the project, it must be allocated to a specific release or iteration. These sets of allocated requirements determine the scope for each planned iteration.

When new requirement requests come along later, as they always do, the team must evaluate each one’s priority against the backlog of work already allocated to that iteration. Do you defer that new requirement to a later iteration, bump a lower priority allocated requirement to a later iteration, or increase the iteration’s scope by adding the new requirement to it? You can’t just keep cramming more functionality into a planned development cycle and…