Requirements may be focused on outcomes (e.g. describing what people should be able to do as a result of commissioning a new building), where the main concern is to describe what is wanted rather than how it should be delivered. Alternatively, requirements may need to be specified in precise terms (e.g. when ordering a technical component to fit with existing office machinery).

Requirements may be described in any way between these two extremes. The important issue is that those specifying the requirement have an adequate understanding of what the users need and how the market is likely to meet that need.

Requirements need to be expressed in a way that keeps any likely changes to a minimum. Changes to requirements once the project moves into delivery can have major impacts on scope, cost and timescale and are one of the major causes of project failure.

This extract has been reproduced with permission from A Practical Guide to Project Planning, TSO 2016. If you’d like to read more you can purchase the copy of the book here.

Establishing the requirements is a process in itself. Initially there may be much ambiguity and, wherever possible, this ambiguity should be removed. There is a tendency to rush this activity; however, if there is not clarity about what need to be produced, what hope is there of delivering it? Ambiguity in requirements is often the source of failure in projects.

Technique

In order to specify business requirements, the following should be considered:

Context: The organizational setting in which the requirements are emerging. It should be recognized that all requirements have attributes that are a rich source of management information. Each project should select the attributes that are critical to its success (e.g. customer benefit, effort, development priority etc.).
Requirements: This includes understanding the boundaries, determining the stakeholders, recognizing goals, using scenarios, investigating feasibility, and understanding risks.
Modelling and analysis: Understanding the effects of the changes at different levels of the organization.
Communications: Use of appropriate language, documentation and other illustrations to maintain appropriate two-way dialogue (i.e. consultation) and understanding with stakeholders. Also ensuring that requirements are traceable.
Gaining agreements: Validation, negotiation, conflict resolution and prioritization of requirements.
Evolution: Ensuring that the solution to meeting the requirements is responsive to environmental change and that any changes in requirements can be managed and controlled effectively (involves impact analysis and configuration management).

When we have defined the objectives and understand which stakeholders are interested in what, we need to bring all the information together so the extent of what the project will need to deliver is understood. Requirements are basically the business changes that the project will need to deliver.

At this point, the requirements may take a variety of forms from a specific (objective) technical requirement through to an evolving expectation. The key thing is to capture all the requirements, as they will shape what stakeholders are expecting and will need to be included or excluded from the scope of the project in the next stage.

There is a danger that requirements are driven by the features of a supplier’s products, so care needs to be taken to differentiate (as obstacles) such requirements when they arise, as these will affect the options for delivering the solution.

At the end of this activity a document detailing business requirements should be produced. This needs to capture the following information:

Reference: Unique ID for the requirement
Requirement: Description of the requirement
Business impact: The effect of having this requirement or facility
Originator: The person or group who requested the requirement
Objective(s) served: There should be a link between the requirement and the objectives.

Example

The clearest way to document the business requirements is probably by using a table, as shown below (which uses the training course project as an example). Such a table can quickly give you an overview of what the project is required to deliver and how it is aligned with the business objectives.

Requirements of the training course project

Introduction The Content The Technique The Example

On this page