As the process of capturing and documenting business requirements matures, there is often a watershed moment when an organization must decide whether to perform traceability of requirements as part of that process. Most companies involved with a formal methodology for software development utilize some degree of traceability; but those not familiar with it could be put off by the overhead of requirements management (RM), of which traceability is a component. Therefore, it helps to understand some of the value aspects of instituting traceability.
The International Institute of Business Analysis’ (IIBA) defines requirements traceability:
The ability to identify and document the lineage of each requirement, including its derivation (backward traceability), its allocation (forward traceability), and its relationship to other requirements.
A General View of Traceability
There is no question that there is additional cost involved with moving to a traceability schema for requirements if this has not been done before, and it occurs both in the preliminary setup of requirements and the maintenance of them afterward. However, this post hopes to provide practitioners and managers some insight into the process of consideration of traceability into an organization, especially those that are having trouble justifying it.
Enhanced Scope Control
Linking higher-level requirements to requirements at deeper, granular levels ensures that the project members understand the relationships between stakeholder needs. It also provides a view of requested change against the entire relationship structure of requirements. If a change is requested in lower-level functional requirements, the analyst and stakeholders can immediately determine if the request is able to trace back to the high-level need. If not, the request is denied or placed into a subsequent release.
Taking the traced requirements a step further into Design, the hierarchical structure is used to check that each requirement has a corresponding design element and concurrently ensures that there are no design elements that don’t trace back to requirements. This prevents the insertion, whether intentional or sub-consciously, of functionality that has no relationship to the stakeholder goals and objectives.
Enhanced Project Definition and Release Mgmt
Since a project is a dynamic entity that includes much change, it’s important to be able to identify what actually comprises the deliverable as items are added and removed along the path to implementation. Traceability and corresponding requirement attributes provide a view of the hierarchical structure of progressively detailed and linked requirements along with release attributes. This is what the analyst uses to define the baseline requirements upon sign-off/approval by the stakeholders. As this information is carried forward through design, construction and testing, a tangible picture of what the project is comprised of is available to release managers, who must prepare large volumes of content for implementation.
When organizations that utilize requirements traceability also enter their design and code elements into the same repository, a view emerges that shows how all pieces are tied together. Therefore, if development runs into trouble implementing a feature, it can be pulled from a release. There is now immediate knowledge available to determine what design elements, requirements and test cases are related to it which the project teams can use to adjust the deliverable and change the release configuration.
Higher Visibility to Change Impacts
As requirements repositories grow, they increase in value. Over time, as requirements are linked together and the view of the requirement lineage builds across various aspects of the project. These relationships merge together into a cohesive view of the customer directives to build the application, what the application looks like at a modular level and how the application resides in the total organizational technical architecture. A systemic view like this positions the team members to immediately assess impacts to not only their own area of expertise, but also across the span of all project areas. Then, infrastructure architects can assess the alterations that may need to be made to the framework the organization uses to guide application development….or prevent the change to ensure the integrity of the infrastructure.
Enhanced Visibility to Program Impacts and Impact Analysis
Taking the ability to assess project change a step further, the use of a requirements repository that spans across an entire program of projects further enhances the assessment capability. For example, an organization that implements a business rule across several projects will have the ability to determine impacts to change of the singular business rule in all effected areas. Immediately the value of these relationships grows, as early estimations are more accurate, as is preliminary discovery of the potential work effort. This information is critical to clearly determining whether the available resource capacity can handle the change within the release.
Traceability to Business Process, Operational Units and Technical Components
Program impact visibility is also valuable in future planning for upcoming technical framework changes. Imagine trying to move into a SOA or Cloud computing scenario without understanding how current service offerings are tied together or constructed individually. In situations like this, there could be huge and unforeseen impacts to system performance and capacity simply due to the fact that the core information about the existing system is so scattered.
Exposing existing technology to new uses has the ability to cause extreme impacts to the system as it currently exists. Having the ability to assess that prevents the need for the technical team to react to adverse situations by being able to accurately predict situations and test for them prior to implementation. Less rework caused by defects or system failures equals enhanced productivity and happier customers.
Prioritization
Most analysts have experienced stakeholders that want all requirements implemented immediately, with each one being critical to the delivery. In reality, some MUST be more or less important than the other. A properly traced requirements repository illustrates the trail of criticality throughout the requirements and ensures that requirements designated as critical are not tied to a higher-level stakeholder needs that has been deemed as a lower priority. An effective checks-and-balances system like this is important for planning out the work breakdown structure and assigning resources to tasks at the lower levels of the SDLC. Therefore, it’s important to get a clear picture of relative importance between requirements early.
Reusable Requirements Repository
Reusing requirements is a debatable practice that can often be hard to accomplish, unlike reusing code modules. Requirements tend to be a bit too specific to offer much in the way of reuse. However, there are certain aspects of requirements that lend themselves to reuse, such as use cases, business rules and granular system requirements like fields. Traceability helps the possibility of reuse in two ways. First, traceability creates the view to allow the practitioner to visualize where specific requirements may be used again, such as use cases. An example use case that defines functionality for a business process for one project under a traced program repository of requirements can be identified as a candidate for similar functionality in a different area, thus ensuring the overarching process is implemented consistently. When the parent process becomes a candidate for changes, analysts can determine all areas that use it an may consequently be affected. The same scenario could be applied to business rules, which often function similarly in various locations. On the back side, traceability again provides the ability to analyze impacts to reused requirements in order to ensure that a change to the original source doesn’t adversely impact the entire family of used instances. If that is necessary, one merely needs to break the link and instantiate a new version.
Automation of Requirement Capabilities
While this article intentionally omits detailed discussion of the different implementations of tracing, it is worth mentioning that pairing a traced repository with an automated requirements management tool (RM) provides some very valuable capabilities to project teams that a simple, untraced repository of requirements does not. Many of the new generations of RM tools provide an aspect of automated notification of change. This capability significantly enhances the ability of a team to immediately understand change before or during its occurrence. A scenario in which a thoroughly traced requirement is changed would have automated notification sent to designated owners of linked requirements. The notification event provides a reactive capability for team members to learn of the change and to provide early feedback that might raise red flags and prevent future delivery or implementation problems. Next generation tools are now broadening the capabilities afforded to project teams by including requirements repositories with standard trace functionality into modeling tools, such as Sparx Systems’ Enterprise Architect. In these tools, practitioners can actively drag-and-drop requirements into models and be immediately provided with impact views to the traced requirements and model changes.
It should be noted that traceability and requirements management starts very early in the SDLC, but continues throughout the entire cycle. The addition of this process forces a change in the way non-analyst team members work with requirements; it essentially makes ownership of, and interaction with, requirements a team function. In a narrow view, this can be construed as adding overhead to individual roles where requirements maintenance didn’t exist before. However, in the broader scope of the project lifecycle, requirements management and traceability also places accountability and information directly into the hands of the team member as the requirement moves through the SDLC. No longer is it a view controlled by an analyst, but shared throughout to ensure higher quality, less rework, better planning, increased productivity and shared value.
The investment of new technology and/or processes can be very large to organizations trying to get a handle on controlling their environments and working conditions. When considering solution impacts to technical functionality, licensing, resourcing and process improvement, it’s important to have an understanding of what the proposed solution can bring as justification. While it may be easier to store requirements in project documentation or simple bucket repositories, the negatives of a lost opportunity to enhance the application development working environment must also be evaluated. Considering all the value-added benefits, it’s worth thinking about the above to understand what one cannot accomplish without traceability.
Author: Doug Goldberg is a Senior Business Analyst in the Healthcare Industry. He has over 15 years experience in business and technical analysis relating to software development. Doug is currently involved in the IIBA (Dallas Chapter and International, studying for the CBAP certification, and volunteering as an analyst mentor to several persons. You can contact Doug at [email protected], follow him on Twitter: @DougGtheBA or connect with him on LinkedIn.