Documenting Requirements

Documenting Requirements

Unhappy Bank decided on the below approach of documenting requirements.

Standardised Format

All business analysts use the same format. This helped to ensure that all requirements were captured consistently and can be easily referenced.

Include all relevant information

All relevant information about each requirement were include, such as its priority, status, and any dependencies or constraints. Furthermore, dropped requirements were included for future reference.

Clear and concise language

Requirements where written in a clear language and technical jargon or complex terminology was avoided. That way different stakeholders could easily understand the requirements they were suppose to sign off.

Visual aids

Visual aids were used in documentation, such as diagrams or flowcharts, to help illustrate complex requirements or processes.

Updated Documentation

Business analysts tried to keep the requirements documentation always up-to-date throughout the project by revising it as necessary and ensuring that it remained aligned with the project objectives.

Version Control

Version control ensured that any movement in requirements was clearly recorded and version numbers could be used for comparison to ensure all parties were working with the correct version.

First a document was created in draft form. Format 0.n. For example requirement T-007 could be numbered T-007v0.1 indicating that this is the first draft version of the technical requirement 007. The next version was T-007v0.2 and so on. Finally when a document was baselined (or signed-off) the version number was changed to indicate this. For example T-007v0.11 -> T-007v1.0

Once a document was baselined, no changes could be made without the approval of appropriate authority.