Number 7 in the series, “How to Shoot Yourself in the Foot: 7 ways to do software requirements poorly to set your project up for failure and what to do instead.”

1. Short-change Time Spent on Software Requirements or Don’t do Them at All
2. Don’t Listen to Your Customer’s Needs
3. Don’t use Models
4. Use Weasel Words
5. Don’t Prioritize Requirements
6. Don’t  Baseline and Change Control Requirements
7. Don’t do Requirements Traceability

Your project has completed on time and under budget. System testing is complete. Defects have been fixed and validated. Maybe your system has even been deployed and has passed the customer’s acceptance tests. You know you are amazing and look forward to basking in the glory of a job well done. Nothing can prevent your victory lap. The project is a success, right?  Not if you neglected to do requirements traceability! Even if the project passed the user’s acceptance tests, without requirements traceability you most likely have handed them landmines that will blow up their business at an unknown time in the future. The tests passed, but did the tests cover all of the requirements? Was the test effort weighted to focus on the highest priority requirements that give the business the most value? You might say, “I did do traceability as part of my final report at the end of the project.”  This is not good enough, because it is too late. If you waited to the very end of the SDLC (Software Development Life Cycle), at best you confirmed that you built the product right, but you may not have built the right product. And if you do determine that you did not build the right product, you don’t have time left to react at this point. It is too late to take meaningful corrective action that affects business value.

I believe traceability is most often not done, or done superficially due to 3 main reasons:

1. The management team doesn’t believe it adds any real business value and therefore won’t allocate time to do it thoroughly or at all
2. Project stakeholders view traceability as something that is done primarily to comply with standards (e.g. CMMI, ISO’s 9001:2000 for software development) and therefore can be done at the very end of a project solely to put a check in the box to avoid possible audit non-conformities
3. Lack of tool support in the organization.

Definition:

Software traceability is a mapping between 2 SDLC objects. It is simply being able to define and track the relationship between two SDLC objects. Traceability is bi-directional. One can trace from a parent object to an object derived from it and vice versa. Note that these can be many-to-many relationships. For example, one can trace from a business requirement to the functional requirements that address it and the other way.

Value of Traceability:

Software Requirements Traceability is required for aerospace and medical devices. For example, DO-178B is a standard for software in commercial airplanes. In his book, Software Requirements Karl Weigers stated “Even if your products don’t cause loss of life or limb if they fail, you should take requirements traceability seriously.”

Traceability enables the following types of questions to be answered. I am using ‘forward’ to denote a trace direction from SDLC parent object to SDLC derived object and ‘backward’ to denote a trace from SDLC derived object back to SDLC parent object. This is just a sample of questions. There are other high value questions and other stakeholders that could ask these questions.

Doing It:

Tracing should be done as early as possible in the project. For example: Tracing between business requirements and functional requirement should be done as soon as there are both. Tracing from test results back to functional requirements will by necessity need to be done later in the project cycle when testing is executed.

There are few basic rules that need to be followed for tracing to work, whether it is done using an Excel spreadsheet or a tool. The power of a requirements tool is that it will provide automation to deal with the manual drudge aspects of tracing.

1. All elements to be traced must be labeled uniquely (For example: Functional Requirement IDs, Use Case IDs, Test Case IDs, etc.).
2. The elements to be traced must each be clearly defined.  By this I mean a clearly defined boundary, so that there are obvious traces forward and backward
3. Time has to be allocated for team members fill in the actual traces for their own artifacts.
4. Tracing from requirements to testing requires that the requirement is testable, test suites and/or test cases exist and the tests have been run.  (Tracing from the actual test run back to requirements will require a tool for a non-trivial project be able to manage the volume of data.)

Here is an example of the column headings for a manual traceability matrix done in Excel:

• Business Requirement ID
• Business Requirement
• Functional Requirement ID
• Functional Requirement
• Test Case ID
• Test Case Title
• Test Run ID
• Test Run Status

As you might guess, this would produce a huge table for any moderate or large project. If you don’t have any automated tools, one way to manage the size is to split it into sub-tables. For example, do the business requirements to functional requirements trace separate from the Functional Requirements to Test Cases trace.

Automation:

Requirements management tools make it much easier to analyze and maintain the large number of traces that exist in any moderate or large project. Here are some of the major players:

• Caliber
• Doors
• RequisitePro
• TFS 2010

Conclusion:

Traceability is valuable because it helps find missing requirements, missing test cases and most of all uncovers missing or inadequate focus on the business requirements for the project.

Don’t shoot yourself in the foot on your next project! Resolve today to effectively trace requirements through the SDLC to confirm that the right product was built right. The choice is yours.

Next time I will conclude this series with some quizzes as a way of review.