July 8, 2015

Different Methods of Requirements Reuse in TestTrack

Helix ALM
Requirements Management
To reuse or not to reuse—that is the question. Any company developing software, hardware, and firmware for a specific product line faces the question of requirements reuse when creating requirements together for similar but different products. In this blog post, I’ll demonstrate the different ways I can reuse requirements with TestTrack, using a car windshield wiper as the product I’m developing.

Are the Requirements Reusable?

The first question I need to answer is, can I reuse my product requirements? The primary requirement for a windshield wiper is that it must do one thing: clear the view for the driver. While windshield wipers are slightly different for every car model, the features, firmware, and software are similar and share many requirements. Likewise, the wiper, firmware, and software all must meet ISO and IEC standards, which are the same for all wipers. All three components must also fulfill the safety goals defined by the functional safety requirements. It seems that most of the requirements needed for one wiper model can be reused for other models. How can TestTrack help me reuse requirements properly?

Requirements Reuse by Sharing

If a requirement in one document applies to another document, TestTrack can append the requirement to the end of the other document. When appending, TestTrack gives users the option to “Share the existing requirements with the selected requirement document.” This adds the requirement to the selected document and creates a share between the requirements. If a shared requirement is modified, the changes are made in all documents the requirement is included in. If the appended requirement has child requirements, they are also appended to the document. Appended requirements can be shared between documents or a new copy of the requirement can be appended. [caption id="attachment_17044" align="aligncenter" width="902"]Requirements reuse of functional requirements in a document between two different product variants. Requirements reuse of functional requirements in a document between two different product variants.[/caption]   Similarly, I can also add existing requirements to documents with TestTrack. Requirements can be shared between documents or a new copy can be created. For my wiper, I can reuse the ISO standards. ISO standards are identical for all wipers, so I can use simple sharing to reuse all ISO requirements in any wiper requirements specification. [caption id="attachment_17041" align="aligncenter" width="902"]Requirements reuse of ISO standards Requirements reuse of ISO standards for two different products inside folders.[/caption]  

Requirements Reuse by Copying

What if I want to reuse the front windshield wipers requirements for the rear wiper? While the rear wiper is similar, the hardware is different enough that I can’t reuse the exact requirements created for the front wipers. Fortunately, I don’t need to start all over again. Rather than appending or adding requirements to a new document, I can copy the requirements. The requirement contents are the same when the copy is created, but there is no link between the requirements. Any changes made in the original requirement are not reflected in the copied requirement, and vice versa. In other words, I can reuse the requirements I’ve already written to create new requirements for the rear wiper, but there isn’t any sharing; in the end, these are different requirements. By using TestTrack to copy requirements, I have the structure I need but I don’t need to start from the scratch—even if the requirements are different in the detailed description.

Requirements Reuse by Duplicating

The firmware and software for my wipers runs on a common platform, which has its own set of requirements. So what happens when that platform changes? I can’t immediately put the new platform into every wiper model. I have to copy all the platform’s requirements and use them to define the new platform. The requirements for the new platform may have the same summaries as the requirements for the old platform, but description and specific fields may be different. Should I reuse the requirements by copying or duplicating? In this case, I should duplicate. Duplicating TestTrack requirements is a way of reusing requirements with relationships, meaning a named link to the original requirement is created (e.g., “Duplicated From”). When duplicating a requirement to create a new requirement, both are linked together, allowing me to easily trace back to the original requirement. [caption id="attachment_17046" align="aligncenter" width="415"]Derived requirement with a link to the original. Derived requirement with a link to the original.[/caption]   Many TestTrack users create these types of links when reusing requirements. TestTrack also allows me to filter the requirements list to show all related requirements. Additionally, TestTrack allows me to create a custom field and then use item-mapping rules to automatically keep the original tag when duplicating a requirement.

Requirements Reuse with Change Notification

The hardware for the front and rear windshield wipers is identical, so I can share the requirements between the two. The firmware is based on the hardware, so I can create the firmware requirements from the hardware requirements by duplicating and maintaining the links. But what if a hardware requirement changes? Do I have to look up all the firmware requirements to see if they’re still valid? Not with TestTrack. Once a requirement is duplicated in TestTrack, I can mark it as suspect and be alerted if the original requirement changes. (Alternately, I can flag the original requirement as suspect to be alerted when the duplicate changes.) [caption id="attachment_17049" align="aligncenter" width="902"]After duplicating a requirement, the original changed. I received a change notification because the duplicated requirement was automatically marked suspect. After duplicating a requirement, the original changed. I received a change notification because the duplicated requirement was automatically marked suspect.[/caption] Therefore, if I flag the hardware requirements as suspect, the team maintaining the firmware requirements will be alerted if the hardware requirements change. They can then review the firmware requirements to determine whether they are still valid for the changed hardware or if the firmware needs to be changed. [caption id="attachment_17051" align="aligncenter" width="902"]The firmware team can view this change report to compare the original requirement to the new version. The firmware team can view this change report to compare the original requirement to the new version.[/caption]

Requirements Reuse with Change Control

TestTrack supports versioning of requirements through snapshots. A requirement is automatically versioned when a document snapshot is created and a requirement is modified later. When I change a requirement in a document, the requirement does not change in any snapshot of the same or different document, so I have a change control for the requirement and can view historical requirement versions to see any changes between my changed version and any other version of the requirement. [caption id="attachment_17053" align="aligncenter" width="417"]Every change is documented through document snapshots. Every change is documented through document snapshots.[/caption] This can be useful when I need to see if a firmware requirement was valid in a specific version, and whether that requirement has since changed. A snapshot can also be helpful because it creates a new version of every firmware requirement, preserving a change control record with a detailed description what has changed since the snapshot was created. [caption id="attachment_17055" align="aligncenter" width="902"]Duplicated requirements derived from the original requirement. Duplicated requirements derived from the original requirement.[/caption]


I hope this has helped you understand how you can reuse requirements in TestTrack. For more on requirements reuse, read Seapine’s white paper, 6 Best Practices for Requirements Reuse.