ABCs of Requirements Engineering

1. gets assigned to a change agent  
2. change agent makes change
3. change gets validated
4. change request gets closed 

All changes are discussed in relation to the requirements baseline (e.g., the set of approved requirements for a particular release).

As part of step 1, a Change Request Form (CRF) should be created to capture all pertinent information about a change.  In addition, you may wish to automate the change request form using a change management or incident tracking tool.  If so, ensure a proper tool evaluation occurs.   

CM Support - The RM process is effectively a CM Change Control Process but specifically for the requirements baseline.  

Note: For details about establishing a Change Control Process (including process example), visit the book, “Software Configuration Management Implementation Roadmap,” Chapter 4, section 6.2. “Develop an SCM Change Control Process.”     

Establish an project-level Change Control Board (CCB)

The second facet of managing requirements is to establish a CCB at the project level.  This CCB should be made up of key project representatives who are empowered to make project decisions that focus on the impact of the change to the release schedule and quality of the release deliverables.  This typically includes the Project Manager, Test lead, Developer lead, CM lead, and customer representative (e.g., Marketing or actual customer).  These folks should be trained in the established Requirements Management process mentioned above. 

Often times within a project release, new requirements are uncovered and it must be determined if they should go into the current release or be deferred to a subsequent release.  If the recommendation is to defer it to a subsequent release, then the change request should be sent to the application-level CCB for their ruling. 

CM support – the change control board (CCB) is a key element of configuration management.  The CCB, like the CM discipline focuses on the importance of managing and controlling change. 

Establish the CCB Conduct Guidelines

The third facet of managing requirements is to establish a CCB Conduct Guidelines.  These guidelines provide rules to help objectify the CCB process in order to more effectively and efficiently rule on each change.  It will include determining the CCB meeting logistics, CCB meeting process, CCB voting privileges, Voting approval method, and Waiving policy.  This guideline should be established and reviewed with the CCB members.     

Note: For more details about the CCB Conduct Guidelines (and example template), visit the book, “Software Configuration Management Implementation Roadmap”, Chapter 4, section 6.2.1 “Prepare Change Control Board (CCB) Conduct Guidelines”.    

Implement the Requirements Management Process

The fourth facet of managing requirements is to implement the Requirements Management (RM) process for use on an on-going basis.  Review the Requirements Management process, the Change Request Form (CRF), and the CCB Conduct Guidelines with all CCB members.  Per the CCB Conduct Guidelines, set up periodic CCB meetings or hold them when change requests come in.  Rule on the changes per the RM process and CCB Conduct Guidelines.  Post the results of the CCB meeting to all impacted personnel.  On occasion, validate that the RM process is being used to determine if changes are being objectively processed in a timely manner.      

Traceability of Requirements

Traceability may be defined as the relationship between requirements and the downstream items (e.g., code, test cases, etc) that realize the requirements.  The main benefit of establishing traceability between requirements, code, and test items is that it ensures that only what is required is being developed and everything that is developed is actually tested.  This reduces the gap of missing requirements in the finished product and reduces the