Requirements management is the process of capturing, assessing and justifying stakeholders’ wants and needs.
A clear and agreed expression of requirements and their acceptance criteria is essential for the success of any project, programme or portfolio. Requirements may be expressed as physical deliverables or business benefits, as aspirations or solutions, and as functional or technical needs.
The first step in the process is to gather all types of requirements. Most requirements will be generated by internal and external stakeholders, such as clients and users, but there will be a background of legal or regulatory requirements that must also be included.
The various requirements are assessed to ensure they are practical, achievable, and define what is needed rather than how they will be achieved. A well specified requirement is:
- uniquely identifiable: it addresses only one core requirement;
- current: it is up to date and relevant to the business need;
- consistent: it does not contradict any other requirement;
- understandable: concisely stated and not open to different interpretations;
- verifiable: compliance can be verified through inspection, demonstration, test or analysis;
- traceable: the requirement can be traced from the originating need, through the plan, to what is delivered;
- prioritised: its relative importance is understood.
A simple process for requirements management has four steps:
- gather requirements from stakeholders;
- analyse the requirements to look for overlaps, gaps and conflicts;
- justify the requirements to distinguish wants from needs;
- baseline the needs before commencing the solutions development process.
These steps will be undertaken in different ways, depending on sector practice and the individual development methodologies used. For example, the approach for software development using Agile methods would be different from that using a waterfall approach; managing requirements for business transformation will be different from construction.
Value management is an established, structured approach to both requirements management and solutions development. This is a consultative approach that focuses on the value that can be generated by stakeholder requirements.
Value is a subjective term and means different things to different people. In the P3 environment it is a means of maximising value for money and is represented by the ratio where value is proportional to the satisfaction of requirements divided by the use of resources.
The goal of value management is not to maximise the satisfaction of requirements, nor to minimise the use of resources, but to establish the balance that maximises the ratio.
The first four steps of a value management process that relate to requirements management are shown in figure 3.9.
Figure 3.9: Value management process
Framing the work involves establishing the high-level principles within which requirements will be managed. It will establish how functions such as stakeholder management, risk management and resource management will be integrated with requirements management to maximise value.
This step also involves an early assessment of the high-level requirements by developing a value profile that estimates the relative contribution to the value of each requirement.
The gathering of requirements can be done in any number of ways. It ranges from personal interviews, surveys and workshops, to focus groups, modelling and simulation.
Some methodologies, including Agile approaches, are designed to enable the continuous gathering and refinement of requirements on the assumption that the stakeholders may not be sure of their needs.
One of the advantages of a formal method, such as value management, is that it provides lessons learned that can be used to review how similar requirements may have been managed previously.
Analysing requirements combines information from functions such as schedule management and investment appraisal with specific value-based techniques such as function analysis and function cost analysis. The result is a thorough understanding of requirements and the value they contribute to the overall objective.
The ‘process’ step is primarily about providing feedback to stakeholders, building consensus, and generating ideas. The results of the analysis are communicated through individual consultation or group workshops. This leads to a debate about functionality and alternative ideas. The result is a baselined set of options for functional requirements.
High-level requirements are defined during the concept phase of the project life cycle. These need to be detailed enough to complete a project brief. This, in turn, is used to make an investment decision (i.e. whether or not to proceed to the definition phase).
The level of detail captured during the concept phase, therefore, needs to be sufficient to justify proceeding to the definition phase.
For projects that are part of a programme, these high-level requirements will be derived from the programme requirements. They will relate to an output and, if the programme requirements are sufficiently well described, the process may be correspondingly brief, as it simply needs to add the final details.
For stand-alone projects the first consideration is whether the requirements are expressed as outputs, outcomes or benefits. This will govern whether the project includes benefits realisation as part of an extended project life cycle.
Some methodologies, including Agile approaches, are designed to enable the continuous gathering and refinement of requirements on the assumption that the stakeholders may not be sure of their needs at the outset.
In an Agile project the requirements management process must be efficient and dynamic. It must use rigorous prioritisation mechanisms, such as MoSCoW, to ensure that only valuable and justifiable requirements are included in each phase of work.
Programme requirements will be expressed as benefits. Deciding outputs that will be required to deliver the benefits is an aspect of solutions development, but as each output is defined, requirements management will be used to gather and analyse detailed requirements for the output.
The programme management team is responsible for requirements management as it applies to the programme’s benefits. In this respect, requirements management runs concurrently with the early stages of benefits management. The team must then decide how much responsibility for requirements management will be delegated to the project teams.
Where value management is implemented, the programme management team must balance value across the projects. For example, the distribution of resources may result in greater overall value being generated across the programme, even though this appears to reduce value from the perspective of a particular project.
A common dividing line between the programme and projects is that the programme will express the functional requirements needed from an output in order to realise the required benefits. It is then for the project team to manage the technical requirements that will deliver the required functionality.
Figure 3.10: Relationship between project and programme requirements management
During the concept phase of a programme the main focus will be on establishing the key benefits of the programme, but it will also be necessary to identify possible projects, with initial estimates of cost, in order to prepare a draft business case.
When a programme is given the go-ahead to continue to the definition phase, the requirements management process will refine the understanding of the benefits. This phase of the programme life cycle will also perform requirements management for the projects in the first tranche of the programme in order to develop a more detailed business case.
The top-level requirements of a portfolio will be expressed in terms of the organisation’s strategic objectives. These will be a mixture of stand-alone and interrelated requirements. The requirements management process at portfolio level assesses the strategic objectives and clarifies them with the executive board.
The assessment of requirements will be central to the definition phase of the portfolio life cycle, as interrelated objectives may be collected into a programme and stand-alone objectives delivered through projects. This will contribute to the definition and categorisation phases of the portfolio life cycle.
Most requirements management activity will be delegated to the project and programme management teams, but the portfolio management team must perform three key functions:
- The team act as the interface between the projects and programmes, on the one hand, and the executive board which owns the strategy, on the other. On behalf of the executive board, the portfolio management team must ensure that their requirements are accurately translated into projects and programmes. On behalf of the project and programme management teams, it must ensure that the strategic requirements are adequately defined so that the projects and programmes have sufficient information to deliver the right outputs and benefits.
- The team must coordinate projects and programmes to ensure that the many, localised, requirements management processes work in harmony. This may involve taking central responsibility for dealing with key stakeholders; it will involve vetting detailed project and programme requirements to monitor gaps, overlaps and conflicts.
- Applying value management will enable the prioritising and balancing processes in the portfolio life cycle to make decisions based on the value generated by the different projects and programmes.