Feb
21
Requirements Analysis KA Introduction (v2.0)
February 21, 2007 |
Knowledge Area Definition and Scope
The Requirements Analysis Knowledge Area describes the tasks and techniques used by a business analyst to convert stakeholder needs or stated requirements into a description of the required capabilities of a potential solution that will fulfill the actual needs of the stakeholders.
Requirements analysis is performed to increase the understanding of the business analyst, stakeholders, and project team of the nature of the problem they are trying to solve and the range of viable solutions.
Inputs
There are two primary inputs to requirements analysis:
- Business Requirements, as identified through enterprise analysis;
- Stated Requirements, as identified through requirements elicitation
Tasks
Requirements Analysis occurs whenever a stakeholder need is identified and needs to be addressed.
These tasks may occur multiple times in the lifecycle of a given project, depending on the analysis approach chosen. While it is not possible to discuss all possible combinations and permutations within the scope of the BABOK, a few examples can demonstrate the variability of the task flow.
- A BPM project will likely iterate through the analysis and modeling of a business process or processes before the requirements for an IT system to support those processes are defined. Accordingly, the business analyst will initially focus on the development of Process Models (q.v). Once all stakeholders are in agreement on the process, analysis will be performed to determine what effort is needed to enable the processes to be supported by IT systems.
- An IT project implemented using an Agile lifecycle will typically use Scenarios as the major requirements artifact. Each iteration of the system will define, design, and implement a small selection of scenarios. Additional requirements models will be created on an as-needed basis to support the efforts of the development team.
Even when the requirements development effort for a project is limited to a single “Analysis Phase”, it is unlikely that requirements analysis will only be performed once. Requirements analysis is a learning process, with the business analyst working through the elicitation→analysis→communication cycle until there is a consensus that the requirements are verified and achievable.
The tasks defined as part of the Requirements Analysis and Documentation KA include:
- Structure requirements
- Specify requirements
- Model requirements
- Determine assumptions and constraints
- Verify requirements
Outputs
The output of this KA is specified or modeled requirement(s) that have been verified by the business analyst.
A requirement that cannot be verified will require the business analyst to elicit further information from the stakeholders. Analysis must continue until the requirement can be verified.
Once a requirement has been successfully verified it must be approved by the stakeholders in the project and by the project team and scheduled for implementation. If approval is not forthcoming, elicitation and further analysis will be required.
Requirements elicitation continues in conjunction with requirements analysis until:
- Requirements are validated with the project stakeholders;
- Consensus is obtained on a shared understanding of the validated requirements; and
- The project team is capable of implementing those requirements.
Finally, the requirement must be captured in a form that makes it accessible to stakeholders and to the project team. Methods to capture requirements (including requirements management tools, documents, and other approaches) are described in the Requirements Communication KA.
Comments
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats