Capturing and defining requirements using the stakeholders
Defining requirements requires identification of all stakeholders, then obtaining and documenting their requirements. The documentation should list all assumptions, exclusions and constraints and the acceptance, Handover and closeout criteria.
When defining the requirements, it is important to distinguish wants from needs
Next, it is important to identify the sources or the requirements. One requirement may have multiple sources, but it is important to identify the owners of each requirement.
The owners will need to understand each of the sources views on assumptions, exclusions and constraints, so that a common understanding of the requirements can be met by means agreed with all stakeholders.
Any dependencies between those requirements will need to be captured and this includes all those within the scope of work and those at the strategic, programme, portfolio, levels where this applies.
Consider horizontal linkage of requirements between projects, plus those requirements and constraints that have an interface or a dependency with existing ongoing activities.
The next step is to identify and define the individual elements of each user and customer requirement that can be linked to individual elements of the suppliers system requirements document, which in turn link to the individual elements of the technical specification, which also links to the individual elements of the work breakdown structure and the associated statement of work.
Each product described by the work breakdown structure (WBS) should satisfy an element of the requirements.
The levels of traceability between requirements models must be determined in order to allow for planning the resources and schedule implications for managing requirements.
The system requirements drive the work to be completed within the systems design process and subsequent subsystem and component design, so the link between the system requirements structure and the work breakdown structure must be established.
Requirements are decomposed into capabilities, features or attributes of the project’s deliverables at a sufficient level of detail to allow verification and validation.
This is shown in the diagram below:
Once requirements are defined, the acceptance criteria for each requirement should be approved by the customer. The method of verification for the criteria should also be agreed upon. This could include analysis, inspection, demonstration or test, or simulation.
A clearly defined requirement increases the chances of the project sponsor being able to make a clear decision regarding acceptance after completion.
Requirements may be traded where appropriate, to balance time, cost, quality and safety parameters within the scope of work, using an approved change control process.
Once requirements have been clearly defined and agreed, they should be clearly documented, and the strategy for the delivery of the requirements should be detailed within the requirements strategy and the schedule.
The requirement should be baselined before commencing the design and delivery process.