Our website uses cookies. By continuing to use our website you are agreeing to our use of cookies.
Close this message.

eLearning Log in

Login here using your username and password

Forgotten login?

How do I catalogue project requirements?

Introduction

During information gathering it is highly likely that you will come across conflicting requirements or those that are described differently but may be the same. It is also distinctly possible that requirements being fed into your project may also have been given to other projects.

It is therefore useful to categorize the information to enable analysis and comparison. Different projects will have different requirements. However, a standard organizational approach is required to ensure consistency.

At this point the priority is to capture the requirements rather than make decisions about the feasibility of delivering them. Early in the project lifecycle some requirements may look unrealistic or unachievable, but may become feasible later, or there may be another project that can pick them up at some stage. Similarly, requirements that look straightforward may hide complexity or innovations that are yet to be understood, and until that information is available requirements should be simply catalogued.

Requirements will need some sort of business change to happen. This may be to create, amend or remove some service or related aspects

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.

Technique

It is important to establish some criteria for cataloguing, sorting and filtering requirements to enable us to have different views of the requirements through a common syntax.

These are many criteria that could be used. Here are some standard categories for requirements together with their suggested abbreviations:

  • Accommodation: (AC)  Changes to or provision of accommodation or other related facilities management services
  • Business process: (BP)  Development or change to a business process
  • Human resources: (HR)  Changes to structures, skills or numbers of staff
  • IT software: (ITS)  Changes to or provision of IT software
  • IT hardware: (ITH)  Changes to or provision of IT hardware
  • Statutory: (ST)  Change that is needed to meet a legal requirement
  • Web: (WB)  Provision of or changes to internal or external information provision via the internet
  • Policy: (PO)  Change that is needed to an organization’s policy
  • Training: (TR)  Provision of a training service
  • Reporting: (RP)  Development of reporting or changes to the way information is presented
  • Supply chain: (SC)  Establishing or delivering changes to the way services are procured
  • Construction: (CO)  Change that requires building of new facilities
  • Telecoms: (TP)  Provision of or changes to telephony, telecoms or voice and data-related services.

Example

The requirements category can be added to the basic requirements shown in the table below as an example of the training course project.

Requirements and categories for the training course project

For more complex requirements it will be necessary to have multiple categories for each, and in that case a table such as the one shown below may suffice, with each category being given a column.

Example of requirements with multiple categories

Once the requirements have been established, they should be agreed with the stakeholders. This will require a second round of communications to ensure that the requirements have been correctly understood and captured.

On this page