ABCs of Requirements Engineering

perform a tool evaluation that focuses on identifying the needs for a Requirements tool. 

Once the tool choice is made, create the requirements list template(s) within the tool.  Ensure it includes the fields or attributes (e.g., unique identifier, priority, requirement category, version number, etc.) that will be assigned to each requirement.   

CM support –  because requirements change (much like code does), it is important to apply a form of version control as an attribute or field, whether in an automated requirements tool or manually in a spreadsheet.  Every time a requirement changes, the version number for that requirement should increment to reflect this change.  Note: versioning of a requirement can be one of the criteria used to select an automated vendor requirements tool.  

Approving Requirements

There are three key facets for getting requirements approved.  They are identifying the right folks to establish and approve the requirements baseline, determining which requirements goes into the release, and approving the requirements. 

Establish an Application-level Change Control Board (CCB)   

The first facet for approving requirements focuses on establishing a Change Control Board (CCB) at the application level. Those assigned to the CCB should be considered stakeholders of the application and are empowered to establish requirements baselines per release and approve or reject new requirements or changes to existing requirements across the application lifecycle.  This may include, but not limited too, the Application Owner (a.k.a., Product Manager), Test Manager, Development Manager, and Customer representative (this may be Marketing). 

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.   

Align Requirements to Releases    

The second facet of approving requirements focuses on allocating requirements to the releases of an application based on the priority and estimated effort of the requirements.   This is the task of the application-level CCB.  Their first goal is establishing a baseline of requirements for the latest release (then subsequent releases). 

The ability to determine if the requirements are attainable in a release is based on the requirements estimates given along with the estimated effort of the bug fixes and other changes being included in a release.  Otherwise, several of the requirements (or bug fixes) may need to be deferred to subsequent releases (whether a major, minor, or patch release).   

Approve the Requirements Baseline for a Release   

The third facet focuses on approving the set of requirements to establish a requirements baseline for a given release.  This again is the task for the application-level CCB.  They will review the set of requirements, ensure the estimates of effort align with the schedule, and then approve the set of requirements to establish the contents for a release.  This becomes the requirements baseline for a release and changes will be managed too it at the project level.

CM support – approving the baseline is a change control board (CCB) task, which is a key element of configuration management. 

Management of Requirements

Requirements Management refers to managing changes to an approved requirements baseline for a release.  There are four key facets to managing a requirement.  They are to establish a Requirements Management (RM) process, establish a project-level CCB, establish a CCB Conduct Guidelines, and implement the RM process.     

Establish a Requirements Management Process

The first facet of managing requirements is to establish a Requirements Management (RM) process.  Typical steps in an RM process include:

1. change request get submitted
2. change gets analyzed for impact & effort
3. change gets reviewed and ruled on (accept, reject, etc) by the CCB
4. change