ABCs of Requirements Engineering

chance of releasing code that has been untested.    

There are two key facets to traceability.  The first is that all traceable items must be uniquely identified and controlled.  The second is that all links between traceable items must be identified, established, and maintained.  It should be noted that traceability tends to be an advanced practice in the requirements arena since it effectively crosses thru design, coding, and into test and is challenging to implement.  The first challenge is the effort involved may be high compared to the perceived and real benefit of establishing traceability.  The second challenge is that traceability cannot be implemented on an ad-hoc basis, but must be implemented as a program across the application lifecycle. Otherwise, the benefits will not be realized.   

Uniquely Identify all Requirements, Code, and Test Cases

The first facet to traceability is that all traceable items that will be traced to and from must be uniquely identified and version controlled.  Therefore, in order to perform valid traceability, the team must have requirements that are unique, have a requirements identifier (ID), and be versioned.  Also, all code and test items (e.g., test cases, test scripts, etc) must be uniquely identified and should be version controlled to make the items easier to identify and manage.    

Create Traceable Links to establish a Traceable Relationship Path

The second facet to traceability is that once items are uniquely identified and controlled, links must be established and maintained between traceable items.  The links established between a requirement and its downstream items form the traceable relationship path.  Once the traceable relationship path is established, it is easier to ensure that requirements are being developed and fully tested.  Below is an example of five traceable relationship paths.    

CM Support – if traceability is desired between requirements, code, and test scripts, then code and test items should be version controlled in a CM repository.  For more advanced and automated traceability, an integration between a Configuration Management tool and the Requirements tool may be advantageous.  That way, all configuration items (code, test scripts, etc) that support the requirements can be versioned, easily identified, and have links (e.g., hyperlinks) amongst those in the traceable relationship path.     

Summary
Many times, application teams reduce the Requirements Engineering effort on a release due to a perceived short-term time-to-market gain.  While a project may appear to improve its schedule up front by spending less time in the requirements phase, it ends up spending more money in cost-overruns because it was not clear what it was building causing key functionality to be missed, nor clear on what it should be testing causing large sections of untested functionality being released.  This affects not only the current release, but also subsequent releases of the application.   

For an application to have successful releases and avoid cost overruns, a Requirements Engineering practice must be in place.  This process should include the ability to elicit requirements, document requirements, approve and baseline requirements, manage the requirements after approval, and trace from the requirements thru test. CM can help develop a solid Requirements Engineering practice by providing version control and change control processes.  These CM processes can be tailored to fit the needs of requirements engineering which will lead to a more successful application lifecycle and releases therein.

References

• Chapter “4.  Establish an SCM Infrastructure for an Application” of the “ Software Configuration Management Implementation Roadmap ” by Mario E. Moreira, 2004, Wiley, Ltd Publishing
• Effective Requirements Practices ”. By Ralph R. Young, 2001, Addison- Wesley

•  “An Analysis of the Requirements Traceability Problem”, by Orlena C.Z. Gotel