Previous heading | Top | Next heading

Project requirements statement

Better Practice results: The accurate definition of requirements improves the accuracy of estimates of project benefits and costs, aids implementation and subsequent stakeholder satisfaction.

The project requirements statement defines the capability and performance that the project will provide. The requirements are used to guide the design of specific project deliverables, and to assess whether those deliverables are satisfactory²⁴ for the intended purpose. The project requirements describe what is needed; the deliverables are how that is accomplished; and the outcomes describe why the project is worthwhile.

Important issues for attention by the project sponsor are:

• the completeness of requirements – for example, as well as requirements for developing an ICT system, there may be requirements for legislative change, and staff training;
• the adequacy of consultation in developing the requirements – such as with end users, and understanding the perspective of potential suppliers; and
• the relative importance of different requirements.

In addition, given the central role of the intended operational manager in using the project products to deliver business outcomes, it is important to gain the operational manager's agreement:²⁵

• on the requirements that will serve as the operational acceptance criteria for the project products; and
• that the proposed business outcomes will be achievable with those products.

An example of a high-level project requirement is 'the ability to register and assess 20 000 grant applications per year'. This requirement could be met by a range of options, including a completely manual processing approach, or a fully automated Internet-based computer system. To be implemented, this high-level requirement needs to be expanded, for example, to explain the specific requirements for correctly assessing a grant application.

A component of the business case closely related to requirements is constraints, or 'not negotiable' elements. Some constraints may be set by the project funder or sponsor – for example, the project should finish by a certain date, or have a limit on its budget. In some cases it may be convenient to include these with requirements – the most important point is that they be clearly identified. Other constraints may involve the need to meet standards, or to use

Defining project requirements is a prerequisite for designing potential solutions. Each solution identified is an option that can be assessed on a cost-benefit basis:

• In many cases, the benefits of a project can be derived from the requirements statement. For example, meeting a requirement that 'an applicant's claim history be available online to assessment staff' can allow the calculation of a cost-saving benefit by comparison with the current cost of obtaining the information manually.
• While costs can sometimes be estimated directly from the requirements, more reliable costings can be obtained by estimating the cost of a particular set of project deliverables which fulfill the requirements. The costs can then be used to assess the cost-benefit of that set of deliverables.

These interrelationships are shown in the following diagram:

Requirements can be described in varying degrees of detail. For example, a business case for a $100 000 project may summarise the requirements in a few pages. On the other hand, the requirements documentation to accurately cost the development of a major computer system may be quite lengthy.

The requirements statement should be developed to a degree of detail appropriate to the use to which it will be put – that is, it must be 'fit for purpose'.

One benefit of progressive approval, such as the ICT Two Pass Review process, is that it allows an assessment of whether the cost of detailed requirements analysis is justified. For example, a requirements process costing $20 000 may be part of a first pass business case which obtains approval to spend $200 000 preparing a detailed requirements statement and second pass business case for a $30 million project.

The requirements statement for a project will usually be developed by the project planning team, and then reviewed by the project sponsor. Decision-makers are often more focused on costs and business outcomes than the detail of requirements. However, given that costs and benefits can often only be assessed from requirements, it is better practice for the project sponsor to assure themselves that the requirements statement is complete and is appropriate to the project's objectives.

Important issues for attention by the project sponsor in reviewing the requirements statement in a business case are set out in the following table.

ISSUE	COMMENT
Completeness of requirements	For practical reasons, the business case will describe the requirements in summary. Nevertheless they are the basis of project costings, and need to be complete in the breadth of matters covered. Requirements also need to be expressed with sufficient clarity to allow their use in developing options.
Adequacy of consultation	The quality and completeness of the requirements is likely to be affected by the extent of consultation and the extent of agreement obtained.
Avoiding unnecessarily expensive requirements	An apparently small change to the requirements can dramatically change the cost of a project. for example, a system rated with a higher security classification may cost twice as much; a system with a one second response time may cost twice as much as one with a four second response time. accordingly it is prudent to gain advice (either from the business case team, or independently) as to whether the cost is particularly sensitive to any specific requirement, and assess whether that requirement could be reduced without detriment to the overall project objective.
Project options with variations of the requirements	There can be a set of options to provide a given set of project requirements (with a given level of benefit). it can also be useful to consider options that vary the requirements (and also have varied benefits). for example, one project option may only include the business requirement of accepting grant applications, and another option would also automatically assess applications.
Omission of one or more categories of requirements	On occasion an entire category of requirements may not be mentioned in the business case – perhaps because the requirements are assumed to be understood. it is prudent to check that each category of requirements is covered in the business case. Misunderstandings on issues such as capacity, usability, security, business continuity, and audit requirements can lead to substantial cost increases and delays as the project progresses. (See Appendix D – Categories and examples of requirements at page 106.)

---

Previous: Outcomes and cost

Next: Options