Requirements Management

Introduction

At this stage all requirements have been signed off. Anything beyond, should be considered as a change request. Business analysts should have documented all requirements and should be able to track a requirement either forwards/backwards (why does it exist?), or vertically (is it aligned with business strategy?). The requirements can now be used as inputs for development tasks and testing tasks.

Elements of Requirements Management

Below are the main elements of requirements.

  • Identifying requirements: Identifying uniquely with a reference. It is advised to use unique codes that can be easily searched.
  • Source of the requirement: Documented in the requirements catalogue.
  • Owner of the requirement: Person or document the requirement should be traced back.
  • Cross-references for the requirement: All related documents and requirements should be cross-referenced
  • Change control: Process for a proposed change
  • Version control
  • Storage of the documented requirements: Documents should be placed under configuration control

Change Control

A crucial aspect of managing requirements is change control, which aims to establish a strong record of any modifications made to requirements and validate their justification. Even after stakeholders have approved the requirements, they may change their preferences. By implementing a clear change control process, organizations can prevent scope creep and maintain control over the project.

The process begins by documenting the change request, including who raised it, a description of the proposed changes, and the justification for the change. Next, stakeholders should be consulted to evaluate the potential impact of the change, such as the cost, timeline, and resources required to implement it. Based on the stakeholder’s feedback, the appropriate authority, such as the project manager or change control board, should decide whether to approve or reject the change request.

If the change is approved, the next step is to update the requirements documentation, ensuring that the changes are accurately recorded and that all stakeholders are informed of the changes. In addition, the change control process should include a mechanism for tracking and monitoring the progress of the change, such as regular status updates and checkpoints.

Version Control

The process of version control guarantees that every transition between draft and baselined requirements, as well as any modifications made, is documented through the assignment of a unique identifier and an updated version number. This systematic approach allows for a clear record of changes made to requirements, enabling parties to compare different versions and ensuring everyone is using the correct one.

This is the version control processed that was implemented in Unhappy Bank. First a requirement was documented in draft form. The document had the title “Title-0.n”. For example requirement T-007 could be numbered T-007v0.1 indicating that this is the first draft version of the requirement 007. After the appropriate stakeholders signed off the requirement, the document would be renamed to “T-007v1.0”. That meant that the requirement was baselined. No changes could be made without going through the change control process as discussed in the previous section. Lastly, if a change control was decided then the document would be renamed to “T-007v1.1” and follow the same process until it was baselined to “T-007v2.0”.