WHY REQUIREMENTS TRACEABILITY?

The requirements phase is the least understood phase of software development. Skipping the requirements phase and moving into the design phase is a natural tendency.

Given that the requirements phase is misunderstood, is it any wonder that terms such as “requirements traceability” and “requirements traceability matrix” are misunderstood as well?

Deliverables of a Typical Software Project

A typical software project will create the following deliverables:

The Software Requirements Specification (SRS) is usually written by a Business Analyst, typically as narrative--that is it contains large paragraphs of text describing the general wants and needs of the users. Sometimes there are accompanying diagrams. More advanced projects document “use cases” describing the user’s business process and associate system behavior.

The Software Design Specification (SDS) is usually written by a Programmer. The SDS is a more technical description of the programs that will fulfill requirements written in the SRS.

The Test Plan is written by the Quality Assurance Analyst. The QA Analyst gathers up all the SRS documents, SDS documents, and any other miscellaneous documents, and attempts to write a Test Plan. The Test Plan describes the steps the QA Analyst will take to prove that the system meets requirements.

Uniquely Identifying Requirements

If the System Requirement Specification (SRS) has been written in narrative, it is often difficult to identify and keep track of legitimate requirement statements. A good technique is to highlight requirement statements, and give each one of them a requirement id, as follows:

Example 1: Business Analyst’s SRS

The system should be able to keep track of projects by assigning a yellow, red or green light to indicate green for “everything is okay”, yellow for “things are not quite on track and red for “needs to be reviewed” [SRS0001]. The Portfolio Manager should be able to easily review the list of projects in their portfolio [SRS0002] , and based on the traffic lights, decide which project they should drill down in to the detail to review [SRS0003]. The Portfolio manager should be able to quickly contact the project manager [SRS0004] to ask questions or attempt to resolve an issue.

The same paragraph, written as straight requirements:

Requirement ID Requirement
SRS0001 A project’s status may be quickly reviewed by examining their “traffic lights”: Green (everything is okay), Yellow (not quite on track) and Red (needs to be reviewed).
SRS0002 The Portfolio Manager may easily review a list of projects in their portfolio.
SRS0003 The Portfolio Manager reviews the traffic lights associated with a project and decide to drill down into greater detail of review.
SRS0004 The Portfolio Manager can easily contact a project manager.

A typical one hundred page SRS may document several hundred uniquely identified project requirement statements.

How can we make sure that all the SRS requirements have made their way into the System Design Specification?

Tracing Requirements to the System Design Specification

The System Design Specification (SDS) is typically written by a Programmer. The programmer is providing a more technical description of the system that will also meet the stated requirements of the system.

Programmers sometimes leave out requirements stated in the System Requirement Specification (SRS). Requirements are left out because they are not well identified or understood. Sometimes the sheer volume of requirements overwhelms the Programmer.

Programmers are also known to create new requirements in their SDS. Programmers add new requirements because they could not create a workable solution without them. Programmers also add new requirements because they give rise to interesting technical challenges.

The following is an example of a Programmer’s attempt to write technical specifications for the requirements statements written in Example 1:

Example 2: Programmer’s SDS

If the project status is “1”, display the green light traffic icon. If the project status “2”, display the yellow light traffic icon. If the status is 3, display the red light Icon.

List of project manager’s projects:

Select * from project where project_portfolio_manager_id = session.project_portoflio manager id order by project_portfolio_manager_name.

I will outer join the above with projects file so that the portfolio manager can not only see their own project, but other projects as well.

The four requirements identified in the SRS may or may not have been satisfied in the above statements. The highlighting technique will be used to uniquely identify requirements in the SDS and try to match them up to requirement id’s in the SRS:

If the project status is “1”, display the green light traffic icon. If the project status “2”, display the yellow light traffic icon. If the status is 3, display the red light Icon. [SRS0001]

List of project manager’s projects: [SRS0002

Select * from project where project_portfolio_manager_id = session.project_portoflio manager id order by project_portfolio_manager_name.

I will outer join the above with projects file so that the portfolio managers can not only see their own project, but other projects as well. [New Requirement]

Analyzing the above, the Programmer wrote specifications addressing two requirements in the SRS (SRS0001 and SRS0002), missed two requirements (where are requirements SRS0003 and SRS0004??) and added a new requirement.

Here is the “requirements traceability matrix” so far:

Requirement ID SRS SDS
SRS0001 Yes Yes
SRS0002 Yes Yes
SRS0003 Yes No
SRS0004 Yes No

Already there is trouble because the Programmer has not designed a solution that addresses two of the SRS requirements. On a good project, the programmer’s SDS would be reviewed. The review would point out that the SDS is missing two requirements (SRS003 and SRS0004). The Programmer would be required to add more statements to the SDS to make sure the missing requirements were addressed.

The “new” requirement would be checked with the author of the SRS, and a project decision would be made whether to include or exclude the Programmer’s suggested requirement.

Tracing Requirements to the Test Plan

The Quality Assurance (QA) Analyst gathers to System Requirement Specification(s) (SRS) and System Design Specifications (SDS) and other miscellaneous documents in an attempt to create a test plan whether the system meets requirements.

If the SRS has documented use cases, the job of the QA Analyst is much easier. As provided in the previous examples, it is assumed that SRS requirements were stated as paragraphs of text. Requirement statements were highlighted, and unique requirement id’s were assigned to each requirement statement.

Example 3: QA Analyst’s Test Plan (with requirement id’s)

Test Plan: Review Project
TC # Step Input Expected Result Pass/Fail Req #
1 Portfolio manager review a list of projects. * None. List of projects that the portfolio manager manages.   SRS0002
2 Reviews overall status None Project status’ should be yellow, red, or green   SRS0001
3 Review detailed status Selects project “Replace timesheets system”. Schedule should be status red, cost should be status red, and quality should be status yellow.   SRS0003

From the above, it is obvious that the QA Analyst is attempting to reconstruct a system “flow” with the documentation provided. Here is the “requirements traceability matrix” so far:

Requirement ID SRS SDS Test Plan
SRS0001 Yes Yes Yes
SRS0002 Yes Yes Yes
SRS0003 Yes No Yes
SRS0004 Yes No No

The QA analyst has forgotten the requirement the fourth requirement, SRS0004. Also, the QA analyst has embellished the meaning of requirement SRS0003 because of lack of detail describing the behavior of the system (no use cases).

At this point, the QA analyst could go back to the Programmer and the Business Analyst to seek further clarification. On good projects, the Test Plans are written at the same time as the SRS document. The QA Analyst will point out where requirements are not specific enough to be tested.

Fine Tuning Requirements

Requirements sometimes get “missed” as project moves through the process of creating the System Requirement Specification (SRS) to the System Design Specification (SDS) and Test Plan. The Requirements Traceability Matrix will point out where more work is needed to ensure requirements are included in the SDS and Test Plan.

As the Programmer develops the SDS, and the QA Analyst develops the Test Plan, there are often opportunities to contact the authors of SRS or SDS to seek clarification of requirements. Perhaps the requirements are not specific enough, or cannot be tested. More requirements may need to be added to create a workable, testable solution.

The process of revising requirements between the SRS, SDS and test plan feel similar to the process of tuning a stringed instrument. First, gross level requirement changes are necessary, followed by finer and finer requirement changes until the number and significance of requirement changes diminish.

Eventually, the Business Analyst, Programmer, and QA Analyst will agree that all requirements are accounted for, the solution is workable and all requirements can be tested. This is the true art of requirements traceability. Visit Softreq.com

RETURN TO LESSONS FROM EXPERTS

Lesson by Terry Reiber, president of Software Requirements, Inc.