Chapter 31. User needs and requirements

The user needs and requirements drive the design of solution so that the desired outcomes can be achieved, and subsequent benefits realised. Requirements describe what is required for an organisation to meet its objectives and are usually stated in terms of what a person or group needs to do. They cover the expectations of:

• those sponsoring the work in terms of fulfilling an aspect of government policy or a government organisation’s internal objectives, say for improved efficiency
• the users of a solution, whether an online tool, say for completing tax returns, or a driver using a new or upgraded road

Figure 31.1 shows where requirements are in the policy-to-delivery chain as described in Chapter 23: Traceability management.

Many organisations have specific requirements they impose on their solutions to enable the efficient use of parts and interoperability between solutions. There can also be statutory requirements which must be complied with relating to solution design, such as those arising from:

• the Public Sector Equality Duty and accessibility regulations (see Chapter 5: Equality, inclusion and diversity),
• environmental and sustainability law (see Chapter 6: Environment and sustainability)
• health and safety law (see Chapter 7: Health, safety and security)
• information and data protection law (see Chapter 24: Information and data management)

See 8.6.3 on taking account of external constraints for further examples.

The methods and processes for managing user needs and requirements vary in terminology, approach and the way they are documented. For example, some methods use the term ‘user story’ instead of ‘user need’.

Requirements management methods are generally part of an overall design methodology for a particular type of output. ‘User needs’ and ‘system requirements’ can differ, with system requirements sometimes associated more with the design of the solution (See Chapter 32: Solution design).

The approaches, however, have many features in common, and while a portfolio, programme or project manager does not need to be a specialist in those methods, sufficient understanding is needed so that they can be satisfied that requirements are being sought, documented, tracked and controlled. If requirements are not visible and in control, the overall portfolio, programme or project is not in control. Table 31.1 describes some commonly used types of requirements.

Success depends on making sure the relevant stakeholders understand and agree the requirements. If using a formal requirements management method, the approach for achieving this should be defined in that method. Agreement depends on people understanding the requirements and the resultant solution, whilst keeping business needs and user experience to the forefront.

Requirements can be described using plain or technical language or conceptual models. How to describe and record requirements should be based on the type of requirement (see Table 31.1) and who the requirement is typically described to.

The use of plain language means that, whatever the stakeholder’s background, they can understand. However, there is a risk that the requirement may be ambiguous with other requirements and interpreted differently across stakeholder perspectives.

The use of technical language or conceptual models allows requirements to be described more succinctly, and stakeholders with the appropriate perspective can understand them with reduced ambiguity. Examples of conceptual models can include use cases, goal models and activity diagrams.

Irrespective of the language used, requirements should have the following features as set out in Table 31.2.

Table 31.2 Characteristics of a requirements register

For all but the simplest solutions, a systems approach, as outlined in Part F: Introduction, should be taken, ensuring the business needs are met and that all the aspects of the overall solution work together.

Requirements identified at one level in the solution can be allocated to various sub-systems so that the supplier of each sub-system understands their scope and what is expected of them. The solution hierarchy is essential when contracting to suppliers as it determines the requirements which should be included in their respective contracts.

As the work proceeds, new requirements, areas for prioritisation or areas for focus are likely to emerge. Value management techniques can help make sure that emerging requirements are prioritised against the existing requirements in serving a purpose for stakeholders and their efficiency to deliver the strategic objectives.

Agile methods are particularly useful for software or process related work as the tools and techniques used are particularly good at developing requirements in parallel with designing the solution. Different options for a solution have different system requirements while meeting the same user need.

A solution rarely meets every requirement in full, so a range of possible solutions should be considered. Changes to cost and time as more detail on both requirements and solution design becomes available should be allowed when planning with an appropriate horizon (see Chapter 16: Planning).

There is nearly always a trade-off to make when selecting a solution option, as some solutions meet the requirements better than others. Each option should be assessed for risk which can result in changes to requirements and scope, and lead to the redefining or rejecting of one or more options for the solution.

The choice of the solution should be based on the relative priorities for each requirement.

Depending on the complexity of the portfolio, programme or project, prioritisation techniques can vary from single to multi criteria analytical, such as:

• ranking requirements by stakeholders on one criteria
• top ten technique, where a select number of the most important requirements for a select criterion are identified and then ranked
• the Kano approach, where requirements are classified as dissatisfiers, satisfiers or delighters and prioritised with respect to acceptance by stakeholders

A common technique is the MoSCoW approach:

• Must have
• Should have
• Could have
• Won’t have

A simple or weighted priority numbering is also often used. Prioritisation indicates what to include in the solution. Low priority requirements can be descoped and high priority ones brought forward.

This prioritisation of requirements, using a backlog, is central in agile delivery for deciding what to address in each sprint or iteration, but the concept can be used for any type of deliverable.

Managing user needs and requirements is a specialist discipline, and the approach and the form of documentation and tools used depends on the methodology chosen for the particular aspect of the work. Regardless of the method adopted, it is vital to understand the context for the work and define the management approach.

When defining and managing requirements, the context in which the work is undertaken and the solution operated needs to be understood as it has a fundamental impact on the design. A systems approach is helpful when deciding on the boundaries of solutions, especially when required to act alongside other systems (as a system of systems).

A requirements management framework should be defined and established which is appropriate to the outputs and work required. For most work, several methods are likely to be needed, each reflecting the customary processes for that type of work. They should, however, be organised so that the results can be consolidated for monitoring and reporting purposes (see 31.6.3 for the key activities in managing user needs).

Reporting measures can include the number of requirements verified against the plan and indicators of requirements stability, such as the number of obsolete requirements, new requirements, requirements to be defined, unchanged requirements and fulfilled requirements.

Central to managing requirements and the framework is the provision and maintenance of a register of user needs and requirements. The sum of all the requirements should cover all needs with respect to the solution.

For large solutions there is unlikely to be a single register but rather a hierarchy, with individual registers for specific parts of the solution. The detail held within a requirements register usually reflects the type of output and the solution delivery approach adopted.

The requirements register includes details such as:

• a unique identification code
• description of the requirements
• type of requirement
• the version of the requirement
• author of the requirement
• stability of the requirement, the likelihood of changes
• associated risks
• prioritisation of the requirement
• name of the person who owns the requirement

The management of user needs and requirements comprises a set of continuous activities undertaken throughout the life of a programme or project. The activities are iterative and involve managing requirements in aggregate and for component parts of a solution. The activities are recursive through the solution hierarchy and are summarised in Figure 31.2.

The approach to managing user needs and requirements should be defined including any processes, methods, tools and techniques to be used. This forms part of the overall governance and management framework for the work (see Chapter 4: Governance and management). The important aspects of this activity are discussed in more detail in 31.6.2.3 on defining the users needs and requirements management framework. The framework should be maintained to address relevant feedback from its use.

It is important to maintain an overall understanding of how the solutions requirements are being derived, managed and fulfilled. Requirements should be planned in a hierarchy and traceable to those parts of the design that fulfil them. Some requirements can be validated discretely, and others have to be validated after integration of parts or all of the solution. Once work is under way, an overall view of progress towards fulfilling requirements needs to be assessed and corrective action taken, if needed (see Chapter 17: Controlling).

The user needs and requirements management framework should be monitored to make sure it remains effective and appropriate as the work proceeds.

The stakeholders of a solution include anyone who has a legitimate interest in the solution, ranging from those sponsoring the programme or project, to others impacted throughout the solution’s life cycle. Users include not just end users (such as a train passenger or benefits applicant) but also those involved in the ongoing operation, maintenance and disposal of a solution. Some can represent themselves, but others need to be represented by a nominated individual who has their interests in mind. Ensure that a broad and diverse range of stakeholders, including those who might be opposed, is identified. See Chapter 26: Stakeholder engagement.

The initial task in defining and analysing stakeholders’ requirements is to understand their needs in each life cycle phase and build scenarios (often called user journeys) of how they expect to interact with the solution. From there a definitive set of stakeholder requirements can be defined. Once the solution design is under way elaboration of the requirements is done alongside the definition of system requirements and initial solution design work (see Chapter 32: Solution design)

System requirements are the foundation for the design of a solution from a technical and operational viewpoint. A range of analysis techniques and trade-offs can be applied iteratively to transform stakeholders’ needs into system requirements. The system requirements specify the characteristics of a solution, attributes, functions and performance expected to meet the users’ needs.

Once a set of stakeholder and system requirements has been defined they should be reviewed and validated by the stakeholders and approved by the nominated role. Once approved they should form the ‘requirements baseline’ against which traceable components of the design and later validation can be undertaken. Changes to requirements require the baseline to be changed. See Chapter 22: Change control and Chapter 23: Traceability management.

Once a solution or workable part of a solution has been built and its component parts verified as being compliant with the system requirements or specifications, it should undergo final validation (often called a trial). This should be in as near a real-life environment as possible to provide objective evidence that the solution, when in use, is likely to fulfil its business objectives and the stakeholders’ needs. See Chapter 34: Verification and validation.

Once the work has been completed and requirements management is no longer needed, the requirements management framework should be merged into the management framework for the solution or closed, and retaining information and data in accordance with the sponsoring organisation’s information retention policy (see Chapter 24: Information and data management).