To accelerate time to market and cut costs, many product development teams can take requirements written for similar projects and reuse them for a new project. Not sure how to get started with requirements reuse? Our newest guide, 6 Best Practices for Requirements Reuse, can help!
This guide provides an overview of the following key reuse practices:
- Document the requirements
- Tune up existing requirements
- Begin with the end in mind
- Avoid excessive granularity
- Develop a pattern
- Link the dependencies
These best practices can help your team achieve time- and cost-savings goals without sacrificing product quality. The tool you use to write and manage requirements can help too. For example, TestTrack includes handy features to help you reuse requirements. We hope you’ll find this free guide helpful and learn some new ways to get the most out of your requirements.
It’s no secret that we also use the products we develop at Seapine Software. Earlier this week, I was running some tests and had a flashback to the (dark) days before requirements management was introduced in TestTrack. It quickly dawned on me the importance of managing requirements alongside test cases, test runs, and other artifacts in TestTrack. Plus, it was a good example of how linking and traceability in TestTrack makes everyone’s job much easier.
I was running some test runs from a regression suite and came across one that didn’t make sense to me. I decided to check the functional design to see how the feature was actually supposed to work. Since we link test runs with the test case they are generated from, it was easy to go directly from the test run to the related test case. However, when looking at the test case, I realized it was written before we managed requirements in TestTrack. So, I had to hunt for the Microsoft Word design document in Surround SCM. Then, I had to take the time to comb through the Word document to find the specific requirement that described the functionality. Not fun and kind of time-consuming.
Continue reading “Making a QA Analyst’s Life Easier: Linking Requirements and Tests in TestTrack”
There will inevitably be changes to a product’s requirements during the course of a project. Some requirements churn is natural in the beginning, as the developers refine their understanding of the product and the technologies being used to develop it.
In most cases, requirements stabilize after they become part of a baseline and the relevant stakeholders have signed off. If the amount of churn is still high after this point, it can drive up costs, impact quality, or force you to sacrifice key features or functionality in order to get the product out the door on time.
In our new guide, 5 Practices for Reducing Requirements Churn, we discuss how to keep requirements churn from becoming excessive. From using shorter release cycles and reducing review fatigue to improving visibility and exposing the impact of change, this free guide can help your project go as smoothly as possible.
Download 5 Practices for Reducing Requirements Churn and learn how to reduce unnecessary churn to keep your project on time and on budget.
TestTrack’s impact analysis tools take the guesswork out of understanding and approving requirement changes. You can quickly understand the scope of changes in the context of the entire project and make better choices about which changes to approve.
To perform impact analysis on a specific requirement, open the requirement and click the Traceability tab. Click Impact Analysis and then select the option for Forward Impact, Backward Impact, or both.
Continue reading “How to Perform Impact Analysis with TestTrack”
We’ve made breaking down requirements much easier with TestTrack 2014.1. Now you have the ability to create requirements and tasks from another requirement with a single click. Let’s take a simple example, where you’re creating system specs from product requirements and then breaking down each system spec into a set of tasks for the team. Using Item Mapping Rules, you can quickly create the logic necessary to enable single-click creation of a task from a system specification.
Continue reading “Breaking Down Requirements in TestTrack”
More and more companies are finding that building their trace matrix early, and maintaining that information throughout the development cycle, can greatly improve their development process. Early in the process, the trace matrix improves the collaboration between design and verification resulting in more efficient and effective testing. By incorporating risk and hazard artifacts into the matrix, it also helps the team to better mitigate hazards and prove their risk-based approach to the FDA.
Matt Harp takes a deeper look at the benefits you can gain by completing your trace matrix earlier in “Trace Early, Trace Often to Improve Your Development Process,” an article on R&D Magazine’s web site. Take a few minutes and read it now.
How early in the process do you create your traceability matrix? At the beginning of a project, so you can take advantage of it throughout the development process? Or do you wait until the end, and generate it as an item on your compliance checklist?