Improvement Service website header
Change Management


What is requirements documentation?

Requirements come in many forms and come from a wide range of sources. For consistency, communication and change-control purposes, it is important to document and store them in a standard way across the organisation. The level of detail and specific content of the requirements documentation will depend on several factors including: policy, lifecycle for delivery, structure of the development team, the level to which requirements apply, the relationships between requirements, any supporting models etc.


Requirements documentation is an integral business analysis function as it will usually form the basis on which the final business solutions are delivered within the organisation. After the requirements have been documented fully they should be reviewed by all interested stakeholders to ensure they are correct, relevant and clear.


How do you create requirements documentation?

A requirements document is a compilation of a variety of documents together. Generally, the following are found in requirements documentation:


Introduction and background

This section should outline the business situation, the context, objectives and scope of the project.


Business process models

The requirements document should include any relevant process maps that have been created as part of the earlier analysis. You may include the ‘as is’ process models, but you should always ensure you include the ‘to be’ models showing the desired situation after the changes are implemented.


Function model

Function models, such as any use case diagrams, should be included. These illustrate the functionality of the proposed system/solution.


Data model

Data models are used to provide more definition and greater detail in respect of the data, to supplement the requirements catalogue. For example, you would include a data model in software build projects. These should also show the relationships between various data groups.


Requirements catalogue

The requirements catalogue, the integral part of any requirements document, should outline each requirement in detail. Requirements are elicited using the various analytical techniques described in previous steps. Those requirements then need to be “cleaned” i.e. the various requirements should not be ambiguous, irrelevant or contain multiple requirements in one. They can also be prioritised using the MoSCoW acronym (Must have, Should have, Could have, Won’t have this time). The catalogue is the key piece of information used to communicate between the business and IT who may use it to develop/procure a new software/process. It is important to make sure all requirements are signed off by their responsible owners.


Although non-exhaustive, this list represents some of the more common requirements categories.



Requirements Documentation

Kelly Hunkin

Senior Business Analyst

Tel: 01506 283885


Heather Adams

Business Analyst

Tel: 01506 282879


Paige Barclay

BA Officer

Tel: 01506 203800


Email the Change Management team

You might also like...

Business Solution
General Technical Functional Non-Functional
Business Constraints Hardware Data Entry Performance
Business Policies Software Data Maintenance Security
Legal Interoperability Procedural Access
Branding Internet Retrieval Backup and Recovery
Cultural     Archiving and Retention
Language     Maintainability
      Business Continuity

When documenting requirements, you should also ensure that there is full traceability of requirements. Backwards traceability allows you to follow the requirement to its source, which is important in case there are any issues or ambiguity and you need further information. You also need to ensure forward traceability to where the requirement is ultimately going to be implemented, to ensure that it is implemented properly.


Glossary of terms

To ensure clear communication of the requirements documentation, a glossary of terms should be included. The glossary of terms should provide clear definitions for each of the requirements to ensure they can be read and understood easily. Each department may have its own terminology and acronyms and it is vital that these are not misconstrued, particularly between the business side of the organisation and IT.


Things to consider

Once complete, the requirements documentation can be passed to IT or the project team to deliver the changes. It is worth noting that the requirements documentation may require some supporting system models such as class diagrams or use cases.


phone icon
Our address
COSLA logo SOLACE logo

© Improvement Service, 2018. All Rights Reserved