links Archives - Jama Software

Tag Archive for: links

The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive’s viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way.

Tracing requirements is a manually intensive task that requires organizational commitment and an effective process. Defining traceability links is not much work if you collect the information as development proceeds, but it’s tedious and expensive to do on a completed system. Keeping the link information current as the system undergoes development and maintenance takes discipline. If the traceability information becomes obsolete, you’ll probably never reconstruct it. Outdated traceability data wastes time by sending developers and maintainers down the wrong path, so it’s actually worse than having no data at all.

Requirements Traceability Procedure

If you’re serious about this effort, you need to explicitly make gathering and managing requirements traceability data the responsibility of certain individuals. Otherwise, it just won’t happen. Typically, a business analyst or a quality assurance engineer collects, stores, and reports on the traceability information. Consider following this sequence of steps when you begin to implement requirements traceability on a specific project:

Select the link relationships you want to define from the possibilities shown in Figure 2 from the first article in this series on requirements traceability.
Take another look at the second article in this series and choose the type of traceability matrix you want to use: the single matrix shown in Table 1 or several of the matrices illustrated in Table 2. Select a mechanism for storing the data—a table in a text document, a spreadsheet, or a commercial requirements management tool.
Identify the parts of the product for which you want to maintain traceability information. Start with the critical core functions, the high-risk portions, or the portions that you expect to undergo the most maintenance and evolution over the product’s life.
Modify your development procedures and checklists to remind developers to update the links after implementing a requirement or an approved change. The traceability data should be updated as soon as someone completes a task that creates or changes a link in the requirements chain.
Define the tagging conventions you will use to uniquely identify all system elements so they can be linked together. If necessary, write scripts that will parse the system files to construct and update the traceability matrices. If you don’t have unique and persistent labels on requirements, design elements, and other system elements, there’s no way you can document the connections between them.
Educate the team about the concepts and importance of requirements tracing, your objectives for this activity, where you will store the traceability data, and the techniques for defining the links—for example, using the tracing features of a requirements management tool.
Identify the individuals who will supply each type of link information and the person who will coordinate the traceability activities and manage the data. Obtain commitments from all of them to do their part.
As development proceeds, have each participant provide the requested traceability information as they complete small bodies of work. Stress the need to assemble the traceability data as they work, rather than attempting to reconstruct it at a major milestone or at the end of the project.
Audit the traceability information periodically to make sure it is being kept current. If a requirement is reported as implemented and verified, yet its traceability data is incomplete or inaccurate, your traceability process isn’t working as you intend.

This procedure is described as though you were starting to collect traceability information at the outset of a new project. If you’re maintaining a legacy system, odds are that you have some traceability data available. There’s no time like the present to begin accumulating this useful information. The next time you have to add an enhancement or make a modification, write down what you discover about connections between code, tests, designs, and requirements. Build the recording of traceability data into your procedure for modifying an existing software component. This small amount of effort might make it easier the next time someone has to work on that same part of the system. You’ll never reconstruct a complete requirements traceability matrix, but you can grow a body of knowledge a bit at a time during the application’s life.

Is Requirements Traceability Feasible? Is it Necessary?

You might conclude that creating a requirements traceability matrix is more expensive than it’s worth or that it’s not feasible for your project. That’s fine: it’s your decision. But consider the following counter-example. A seminar attendee who worked at an aircraft manufacturer told me that the requirements specification for his team’s part of the company’s latest jetliner was a stack of paper six feet thick. They had a complete requirements traceability matrix. I’ve flown on that very model of airplane several times, and I was happy to hear that the developers had managed their requirements so carefully. Managing traceability on a huge product with many interrelated subsystems is a lot of work. This aircraft manufacturer knows it is essential; the Federal Aviation Administration agrees.

Not all companies build products that can have grave consequences if the software has problems. However, you should take requirements tracing seriously, especially for your business’s core information systems. You should decide to use any improved requirements engineering practice based on both the costs of applying the technique and the risks of not using it. As with all software processes, make an economic decision to invest your valuable time where you expect the greatest payback.

Check out Links in the Requirements Chain, Part 1

Check out Links in the Requirements Chain, Part 2

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

The first part in this series of articles presented an overview of requirements traceability, identified the potential kinds of traceability links you could define among a project’s artifacts, and stated several motivations for tracing requirements. This article, adapted from my book Software Requirements, 2nd Edition, describes the requirements traceability matrix.

The Requirements Traceability Matrix

The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. Table 1 illustrates a portion of one such matrix. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements. Then I set up a table formatted as in Table 1 with only the Functional Requirement column populated. As fellow team members and I worked on the project, we gradually filled in the blank cells in the matrix.

Table 1. One Kind of Requirements Traceability Matrix

Table 1 shows how each functional requirement is linked backward to a specific user requirement (represented in the form of use cases in this example), and forward to one or more design, code, and test elements. Design elements could be objects in analysis models such as data flow diagrams, tables in a relational data model, or object classes. Code references can be class methods, stored procedures, source code filenames, or procedures or functions within the source file. You can add more columns to extend the links to other work products, such as online help documentation. Including more traceability detail takes more work, but it also gives you the precise locations of the related software elements, which can save time during change impact analysis and system maintenance.

You should fill in the information as the work gets done, not as it gets planned. That is, enter “catalog.sort()” in the Code column of the first row in Table 1 only when the code has been written, has passed its unit tests, and has been integrated into the source code baseline for the product. This way a reader knows that populated cells in the requirements traceability matrix indicate completed work, not just good intentions.

When completing the matrix column for system test cases, note that listing the test cases for each requirement does not indicate that the software has passed that test. It simply indicates that tests have been written to verify the requirement at the appropriate time. Tracking testing status is a separate matter.

Nonfunctional requirements such as performance goals and quality attributes don’t always trace directly into code. A response-time requirement might dictate the use of certain hardware, algorithms, database structures, or architectural choices. A portability requirement could restrict the language features or coding conventions the programmers use, but it won’t necessarily turn into specific code segments that enable portability. Other quality attributes are indeed implemented in code, though. Integrity requirements for user authentication lead to derived functional requirements that are implemented through, say, passwords or biometrics functionality. In those cases, trace the corresponding functional requirements backward to their parent nonfunctional requirement and forward into downstream deliverables as usual. Figure 1 illustrates a possible traceability chain involving nonfunctional requirements.

Figure 1. Traceability chain for requirements dealing with application security.

Traceability links can define one-to-one, one-to-many, or many-to-many relationships between system elements. The format in Table 1 accommodates these cardinalities by letting you enter several items in each table cell. Here are some examples of the possible link cardinalities:

• One-to-one. One design element is implemented in one code module.

• One-to-many. One functional requirement is verified by multiple test cases.

• Many-to-many. Each use case leads to multiple functional requirements, and certain functional requirements are common to several use cases. Similarly, a shared or repeated design element might satisfy a number of functional requirements. Ideally, you will capture all these interconnections, but in practice many-to-many relationships can become complex and difficult to manage.

Another way to represent traceability information is through a set of matrices that define links between pairs of system elements, such as:

• One type of requirement to other requirements of that same type.

• One type of requirement to requirements of another type.

• One type of requirement to test cases.

You can use these matrices to define various relationships that are possible between pairs of requirements, such as “specifies/is specified by,” “depends on,” “is parent of,” and “constrains/is constrained by.”

Table 2 illustrates a two-way traceability matrix. Most cells in the matrix are empty. Each cell at the intersection of two linked components is marked to indicate the connection. You can use different symbols in the cells to explicitly indicate “traced-to” and “traced-from” or other relationships. Table 2 uses an arrow to indicate that a functional requirement is traced from a particular use case. These matrices are more amenable to automated tool support than is the single traceability table illustrated in Table 1.

Table 2. Requirements Traceability Matrix Showing Links Between Use Cases and Functional Requirements

Traceability links should be defined by whoever has the appropriate information available. Table 3 identifies some typical sources of knowledge about links between various types of source and target objects. Determine the roles and individuals who should supply each type of traceability information for your project. Expect some pushback from busy people whom the BA or project manager asks to provide this data. Those practitioners are entitled to an explanation of what requirements tracing is, why it adds value, and why they’re being asked to contribute to the process. Point out that the incremental cost of capturing traceability information at the time the work is done is small; it’s primarily a matter of habit and discipline.

Table 3. Likely Sources of Traceability Link Information

Tools for Requirements Tracing

It’s impossible to perform requirements tracing manually for any but very small applications. You can use a spreadsheet to maintain traceability data for up to a couple hundred requirements, but larger systems demand a more robust solution. Requirements tracing can’t be fully automated because the knowledge of the links originates in the development team members’ minds. However, once you’ve identified the links, tools can help you manage the vast quantity of traceability information.

There are numerous commercial requirements management tools that have strong requirements tracing capabilities. Two sources of information about such tools are http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx and http://www.volere.co.uk/tools.htm. You can store requirements and other information in a tool’s database and define links between the various types of stored objects. Some tools let you differentiate “traced-to” and “traced-from” relationships, automatically defining the complementary links. That is, if you indicate that requirement R is traced to test case T, the tool will also show the symmetrical relationship in which T is traced from R.

Some tools automatically flag a link as suspect whenever the object on either end of the link is modified. The suspect links have a visual indicator such as a red question mark or a diagonal red line in a cell in the requirements traceability matrix. The suspect link indicators tell you to check, say, whether you need to change certain functional requirements to remain consistent with a modified use case. This feature helps ensure that you have accounted for the known ripple effects of a change.

Check out Links in the Requirements Chain, Part 1.

Check out Links in the Requirements Chain, Part 3.

The final article in this series will propose a process for incorporating requirements traceability practices into your project activities.

Derived requirements traceability is a form of requirements management focused on tracing requirements that aren’t explicitly defined in higher-level requirements, but which are necessary for meeting them and for making the overall system work as expected. In derived requirements traceability, teams will document the dependencies and logical links between these lower-level requirements and other system elements.

Derived Requirements, Explained

For example, let’s say a hypothetical automotive system has a higher-level requirement stating that it must be capable of traveling at very high speeds. A derived requirement in this case might say that the system also needs to be lightweight. While this requirement is not defined by the project stakeholders, satisfying it is essential to the engineering process of the entire system. If the end result is not light enough, the original requirement for fast travel won’t be met, either.

Another way to look at it: Derived requirements are decomposed from other requirements, including business and stakeholder requirements. Adequately tracing them serves several general purposes:

It facilitates impact analysis, by helping identify all the work products that might need modification before implementing a proposed change.
It follows the life of a requirement, both forward and backward in relation to customer needs, and from origin through implementation.
It creates a roadmap, showing at which points each requirement or business rule was implemented.
It simplifies the packaging up of requirements baselines, which are snapshots of approved requirements assigned to product releases at points in time.
It helps meet certain medical regulatory requirements, such as the design controls under FDA CFR 21 820.30 for aligning device design inputs and outputs.

In practice, proper derived requirements traceability will involve cataloging all of the connections between derived requirements and other types of requirements, plus business rules, architecture and design components, source code modules, test cases, help files, and documentation. This process ensures that the product in question is ultimately maintainable, compliant, and tightly aligned with customer expectations.

Enabling Traceability as Part of Requirements Management

For sufficient derived requirements traceability, each requirement must have a unique and persistent label that allows for unambiguous tracking throughout the project. A centralized, modern requirements management solution is preferable to numerous discrete requirements documents for this purpose.

Not only does such a management tool provide one convenient place for collecting feedback and collaborating in real time on reviews and approvals, but it also supports live traceability of upstream and downstream relationships, with clear visibility into the impact of changes on all levels of requirements as well as test coverage. Accordingly, project teams can set up four distinct types of traceability links for their derived requirements.

Figure 1. Four types of requirements traceability.

The Four Types of Derived Requirements Traceability

1. Forward to Requirements

When customer needs evolve, requirements may have to be adjusted in response. By making these adjustments, project teams can keep pace with changes in customers priorities, introductions of new business rules, and modifications of existing rules, among other events.

2. Backward From Requirements

Tracking backward from requirements can provide clarity into the origin of each derived requirement. For instance, a requirements management tool could show the link between the derived requirement, the requirement it came from, and the customer use case being addressed.

3. Forward From Requirements

Once derived requirements begin flowing into downstream deliverables during product development, it’s possible to draw trace relationships between requirements and their corresponding elements. This type of link provides assurance that every requirement is satisfied by a particular component.

4. Backward to Requirements

Finally, this type of link allows for visibility into why certain features were created. Consider how most applications include lines of code that don’t directly relate to stakeholder requirements. Even so, it is important to know why a software engineer wrote that code in the first place.

While a full accounting of all four types is beyond the scope of this piece, let’s look at a more in-depth example of the fourth type. Suppose a tester discovers unexpected functionality with no corresponding requirement. It could indicate two divergent possibilities:

The underlying code might have been implemented to meet a legitimate implied (derived) requirement, which could then be added to the requirements specification.
Alternatively, it might simply be orphan code that no longer belongs in the current product.

Traceability links create clarity in such situations, shining a light on how the different pieces of a system all fit together. Conversely, test cases derived from – and traced back to – individual requirements offer a mechanism for detecting unimplemented requirements, because the tester won’t find the expected functionality.

Figure 2. Some possible requirements traceability links.

There are many types of traceability relationships possible within a project, and not all of them will be needed on every project. However, there are good motivations for implementing derived requirements traceability, via a best-in-breed solution with flexibility that can be leveraged as needed for a given project.

The Main Motivations for Derived Requirements Traceability

At a high level, traceability contributes to a more efficient product lifecycle and superior project management. More specific reasons for implementing it include:

Certification

Traceability data can support certification of safety-critical products, by demonstrating that all requirements were implemented.

Impact analysis

By tracing derived requirements, it’s less likely that something will be overlooked when determining the effects of changes to requirements.

Maintenance

Clear traceability simplifies maintenance, as changes (e.g., in response to updates to government regulations or corporate policies) can be performed with more confidence. A modern requirements management tool makes it easier to show where each applicable rule was addressed in requirements.

Project tracking

Traceability information offers an accurate record of the implementation status of planned functionality, with missing links indicating work products not yet created.

Reengineering

List functions in a legacy system set for replacement and use traceability data to record where they were addressed in the new system’s requirements and software components.

Reuse

With derived requirements traceability in place, it’s more practical to reuse product components by identifying packages of related requirements, designs, code, and tests.

Risk reduction

Documenting component interconnections reduces risk in the event that a key team member with essential knowledge about the system departs the project.

Testing

The links between requirements, tests, and code help indicate the likely locations of bugs when a test yields an unexpected result. Also, knowing which tests verify which requirements will save time by allowing for the elimination of redundant tests.

The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.

Learn more about how Jama Connect streamlines tracking and tracing requirements.

SEE THE SOLUTION