ABCs of Requirements Engineering

enough Sessions

You may have sessions for one or more groups of people depending on the size and type of participants.  You may consider having a requirements session for external customers, another for internal customers and marketing, and yet another for the systems folks.  Another approach is to include all folks in the sessions to generate a better understanding of requirements across participant types.  Typically, several requirements elicitation sessions are needed to extract requirements and hone them so they are somewhat concise and clear. 

Documenting Requirements

There are four key facets to documenting requirements. This includes getting to clear and concise requirements, estimating effort per requirement, prioritizing each requirement, and utilizing the right tool then template to store the requirements. 

Getting to Clear Requirements

The first facet to documenting requirements is to ensure that each requirement is unambiguous, concise, verifiable, complete, consistent, traceable, and have a unique identifier. 

Establishing a unique identifier can be as simple as number that is incremented upwards for each new requirement.  The unique identifier is applied to each requirement.  This also establishes the groundwork for enabling traceability.  Without an easy to identify unique identifier, it is difficult to enable tracing to and from the requirements.    

The ability to ensure that requirements are unambiguous, concise, verifiable, complete and consistent relies heavily on the requirements skills and experience of those facilitating and documenting the requirements.  Experience has found that having test personnel review the requirements is a good way to get the requirements into a less ambiguous, more concise, and verifiable level.  This is because testers have the responsibility to test the requirement so they must really understand the requirements and ensure it can be verified (e.g., tested). 

Estimating Requirement Effort

The second facet to documenting requirements focuses on estimating the effort of each requirement.  This is typically the job of a business or system analyst (e.g., someone who has project estimation skills) who reviews each requirement, identifies what items are impacted, estimates the effort of each impacted item (includes design, development, and testing effort), then calculates the total effort.  This data will be useful in helping prioritize requirements and identify which requirements should form the requirements baseline for a release.   

Prioritizing Requirements

The third facet to documenting requirements focuses on prioritizing the requirements.  This is where either the customer and/or application owner prioritize the requirements to understand the relative importance.  Consider establishing a priority grid with definitions for “priority 1,” “priority 2,” and so on.  This can be a challenging task since it seems to be human nature to make most requirements a “priority 1.”  If this becomes the case then either establish a “priority 1 high,” “priority 1 medium,” and “priority 1 low;” or rank the requirements that are “priority 1.”     

Using the Right Requirements Tool then Template

The fourth facet to documenting requirements focuses on selecting and utilizing an appropriate requirements tool so that the requirements can be more easily reviewed and managed.   You can either use an automated vendor requirements tool or a manual spreadsheet.  For smaller projects, you may find a template in spreadsheet tool may be adequate for your needs. 

If you have a more complex or large project, an automated vendor tool can be a wise choice.  The advantages of an automated requirements tool is that it allows numerous fields or attributes per requirement (e.g., priority, requirement category, etc.) and it can provide a history of the requirements and what has changed.  If traceability is important, select a requirements tool that provides an automated mechanism for traceability.  If an automated requirements tools is being considered,