Requirements Management
This article revisits the managing project requirements initially discussed in Unit 2. The project team and their clients or other stakeholders must agree on what is expected when the project is complete, or someone will be left dissatisfied. An important aspect of this shared understanding is whether the requirements are expressed as outputs, outcomes, or benefits. This can depend upon the type of project and the perceived needs of the decision-maker that has requested the project. Misunderstanding the basic nature of what the client or stakeholder wants can derail even the most elegantly managed project.
General
Requirements management establishes stakeholders' wants and needs, and then reviews these to create a set of baseline requirements for use in solutions development and benefits management. Its goals are to:
- ensure that all relevant stakeholders have the opportunity to express their wants and needs;
- reconcile multiple stakeholder requirements to create a single viable set of objectives;
- achieve stakeholder consensus on a baseline set of requirements.
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, business benefits, aspirations, functions, or technical needs.
The planning step will define the techniques and approaches that will be used to work with stakeholders to capture and agree requirements. The initiation step will ensure the necessary resources are mobilised and requirements management can start.
The planning and initiation steps are usually performed as part of an overarching scope management procedure but may be separated out where requirements are particularly complex or extensive.
The first specific step in the procedure is to capture all types of requirements. Most will be generated by internal and external stakeholders (such as clients and users) but there may also be a background of legal or regulatory requirements that must also be included.
The requirements must be analysed to ensure they are practical, achievable and define 'what' is required rather than 'how' it will be achieved. A well specified requirement has the following characteristics:
- unique: it addresses only one core requirement;
- current: it is up to date and relevant to the business need;
- consistent: it doesn't conflict with other requirements;
- understandable: it is clear and unambiguous;
- verifiable: the compliance of products designed to meet the requirement can be verified through inspection, demonstration or testing;
- traceable: the requirement can be traced from the originating need, through the delivery process to the delivered product;
- prioritised: its importance is understood relative to other requirements.
The remaining steps will be undertaken according to the context of the work. For example, the approach for software development using a parallel life cycle and an agile approach would be different from that using a serial life cycle; managing requirements for business transformation will be different from construction.
Capturing requirements can be done in any number of ways ranging from personal interviews, surveys and workshops, to focus groups, modelling and simulation.
Some development methodologies, including agile, are designed to enable the continuous capture and refinement of requirements on the assumption that the stakeholders may not be sure of their needs at the outset.
Analysing requirements involves looking for any gaps, overlaps, or conflicts in what different stakeholders have asked for. It will need some initial high level solutions development, planning, and benefits management to appreciate the implications of the requirements. The result is a thorough understanding of requirements and the way they contribute to the overall objective.
The consult step is primarily about providing feedback to stakeholders and building consensus. The results of the analysis are communicated through individual consultation or group workshops. This leads to a debate about the functionality and alternative ideas.
Consultation may well result in further requirements being captured and analysed. The eventual result is a baselined set of options for functional requirements. These can then be used to examine alternative solutions during solutions development.
One well established technique that addresses requirements management, solutions development and some aspects of benefits management is called value management. While 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:
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 of the two.
Source: Eddie Obeng, https://www.praxisframework.org/en/knowledge/requirements-management
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.