Improvement Service website header

Contact

You might also like...

What is requirements documentation?

Requirements come in a number of forms 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 this standard documentation set will depend on a number of factors, including; Local policy, lifecycle for delivery, structure of development team, the level to which requirements apply, the relationships between requirements and any supporting models.

 

The requirements documentation is an integral part of the business analysis work as it will usually form the basis from which the final business solutions are delivered to the organisation.  After the requirements have been documented fully they will then be reviewed by all interested stakeholders to ensure they are all correct, with appropriate and clear descriptions.

 

The requirements are elicited through the various analytical techniques used throughout the earlier phases in the business analysis lifecycle.

 

Who is involved in completing the requirements document?

The completion of the requirements document is usually the responsibility of the business analyst, who will have spent sufficient time gathering and eliciting the requirements through various analytical techniques earlier on in the business analysis lifecycle.

 

How is the requirements document created?

Traditionally the requirements document will be laid out in the following manner:

 

  • Introduction and background
    This section should outline the business situation and the context of the project.  This section outlines the objectives and scope of the project.
  • Business process models
    Referring back to process models constructed earlier on in the analysis, the requirements document should include any process maps that are relevant to the business changes to be made as part of the change project.  These should illustrate the ‘to-be’ desired end situation expected after the changes are to be implemented.
  • Function model
    Function models should include diagrams illustrating the functionality of the proposed system/solution.  These are usually drawn in use case diagrams, which show the relationships between different requirements.
  • Data model
    Data models are used to give a detailed data definition and evaluation of for example software build projects or to procure new software.  These should also show the relationships between various data groups.
  • Requirements catalogue
    The requirements catalogue, the integral part of any requirements document, should outline the specific information of each requirement.  The catalogue is the key aspect to the auditing of any requirements as it 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.
  • Glossary of terms
    It is critical for the clear communication of the requirements document that it includes a glossary of terms.  The glossary of terms should provide clear definitions for each of the requirements so to ensure they can be read and understood easily.  Within each department there will be different terms and analogies used which can often be misconstrued between different departments, particularly between the business side and IT.

 

Requirements can usually be split into the following categories. Although not exhaustive, this list represents some of the most common requirements.

Requirements Documentation

Kelly Hunkin

Senior Business Analyst

Tel: 01506 283885

 

Heather Adams

Business Analyst

Tel: 01506 282879

 

Email the Business Analysis team

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
      Availability
      Usability
      Accessibility
      Capacity

Things to consider?

It is important to make sure all requirements are signed off by their responsible owners.  At which point the requirements document can be passed over to IT or the project team to deliver the changes.  It is worth noting that the requirements document may require some supporting system models such as class diagrams or use cases.

 

 

Return to Business Analysis Framework

 

phone icon
Our address
COSLA logo SOLACE logo

© Improvement Service, 2017. All Rights Reserved