Software Requirements Traceability – How Low Do We Go?

Tracing software requirements throughout the project is considered a good practice in software engineering. There are numerous studies that have shown the benefit of traceability and how traceability can avoid defects in software projects.

The generally accepted practice of tracing software requirements includes elements such as architecture and other design components, source code modules, tests, help files and documentation. But how low should traceability go?

A project that I was on recently, the testing organization asked for traceability of the software requirements. The functional requirements are traced to the business requirements. The business rules and the UI data elements are traced to the functional requirements. As the project progressed, additional mappings to design, documentation and test cases will be added. All of the tracing is done in MS Excel, which is also problematic, but that is a different issue for a different post.

While I have traced software requirements before, I have never traced down to the UI data element level. Is there value in tracing down to this level? When I asked the testing organization why they desired this level of tracing, their answer was the standard, “to make sure that we have test cases that cover everything”. But is there really value in tracing down to this level?

I did some research , and could not find any direct references to tracing down to this level. My research did show that some military contracts and defense contracts may call for tracing to this level. But for projects outside of the military or defense world, it is rare.

Tracing to this level is expensive, no doubt about that, especially if the tracing is done properly. For example, a UI data element could be valid for a number of software requirements. Is it enough to trace it to the first software requirement where it is valid? Or is it more proper to trace it to every software requirement where it is valid? Given a basic UI data element such as customer name, it could trace to quite a few software requirements in a large system.

What if the software requirements change? Maintaining a valid traceability can be challenging, especially if the tracing is done manually (which, in this case it is). Every time a software requirement is changed, or a UI data element is added, deleted, renamed, the traceability matrix should be updated. The larger the system, the more complex and cumbersome this becomes.

So while I can applaud the desire of the test organization to ensure that every UI data element within the system is tested and valid per a software requirement, is it worth the cost?

BRD vs. Functional Software Requirements

Business requirements vs Functional requirements

We often get the question asking “what is the difference between business requirements and functional requirements?” In prior posts I have discussed that these distinctions are actually artificial and are artifacts of an organization structure that requires people in “the business” to produce a “business requirements document (BRD)” vs. some other group that will produce a “system requirements specification (SRS)”. The difference ultimately is just the level of detail. But given that we do have to live with BRD’s and SRS’s, how do we decide what goes into each document?

As you may know, at Seilevel we use a model called the Requirements Object Model (ROM) which describes a hierarchy of business needs and features. At the top of the hierarchy we expect a statement of Problems, Objectives and Strategies that tie directly in to corporate strategies. At the bottom of the business level, we expect specific Problems, Objectives and Strategies that drive a particular program.

To determine what goes into the BRD and what goes into an SRS, the best place to start is by thinking in terms of who uses the BRD vs. the SRS and what decisions do they need to make from it. If you think of a typical process model, executives must be presented with information following each phase to determine if the project should continue. Based on the information gathered in each phase, the team presents a summary to the executive who decides whether to proceed. This model can easily be incorporated into an agile or iterative approach which I will cover in another blog post.

Select – Executives are presented with a number of possible projects with conceptual business cases. Based on the corporate strategy and the value of the businesses cases, they select which projects get tentative funding based on a very high level view of the product concept.

Envision – The team gathers more detail around the problems the business is experiencing, the features to solve them and the final business case. The development team uses this information to construct a high level estimate of the total cost. Based on the cost and the return specified in the business case, executives decide to go ahead to the next phase.

Plan – The team creates a detailed set of specifications and design along with a release plan for what will be released when. Based on this, the executives determine, based on the timing of achieving the value, whether the project should proceed.

Build – The team begins building. Exit criteria are based on the level of quality and the value of the features actually implemented. Executives review the business case in the context of the features actually implemented and decide to proceed based on this information.

Deploy – The project can only be declared a success once metrics have been collected to determine if the business value was actually achieved and the business case met.

In this model, the purpose of the BRD is to provide executive stakeholders with enough information to determine if the project has a sound business case. This means that finance needs to understand the features well enough to assign a dollar value on the return and IT needs to understand the features to create a design concept that allows initial sizing of the project.

The purpose of the SRS is for IT to perform an accurate sizing and create a delivery schedule. Based on the delivery schedule, the business case can be reevaluated to determine if the project should go forward.

The BRD should focus on linking features to the business case to enable executives to determine whether the business value warrants more study and to set overarching priorities of features. The SRS should focus on linking features to the design to so that executives can determine if the value can be achieved in a timely fashion and at an acceptable cost.