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.
A requirements document is a compilation of a variety of documents together. Generally, the following are found in requirements documentation:
This section should outline the business situation, the context, objectives and scope of the project.
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 models, such as any use case diagrams, should be included. These illustrate the functionality of the proposed system/solution.
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.
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.
Senior Business Analyst
Tel: 01506 283885
Tel: 01506 282879
Tel: 01506 203800
The Improvement Service (IS) is the national improvement organisation for local government in Scotland.
Our purpose is to help councils and their partners to improve the health, quality of life and opportunities of all people in Scotland through community leadership, strong local governance and the delivery of high quality, efficient local services.
Through a series of principles, the IS works to promote improvement in local government and among its partners to support them improve outcomes and reduce the outcome gaps within populations and within areas.
The IS delivers a range of products and services that support CPPs to build their capacity to deliver the public service reform agenda.
The IS has a non-partisan role to support all elected members in Scotland.
The Improvement Services produces a series of newsletters on a range of subjects, including myaccount, elected members, tellmescotland as well as the main IS newsletter. Subscribe on this page.
|Business Constraints||Hardware||Data Entry||Performance|
|Business Policies||Software||Data Maintenance||Security|
|Branding||Internet||Retrieval||Backup and Recovery|
|Cultural||Archiving and Retention|
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.
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.
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.