6 Best Practices for Requirements Reuse

To accelerate time to market and cut development costs, many product teams take requirements written for similar projects and reuse them for a new project. Requirements reuse allows teams to achieve their time- and cost-saving goals without sacrificing product quality.

Defeating the Project Management Triangle

The three goals that drive almost all product development are faster, better, and cheaper. Standard project management logic says you can have any two of the three, but never all three at the same time—the Project Management Triangle conundrum. In other words:

Project Management Triangle
  • You can have it fast and cheap, but it won't be high quality.
  • You can have it fast and high quality, but costs will be high.
  • You can have it cheap and high quality, but it will take a long time to develop.

When done right, requirements reuse can help you to defeat the Product Management Triangle and achieve all three benefits. Sharing requirements across projects is faster and cheaper than writing new requirements, so you accelerate time to market and cut development costs. Because the requirements have already been verified and tested, quality doesn't suffer; in fact, you even reduce risk by using what has already worked.

The Catch

Is there a catch? Actually, there are two. First, most requirements are not going to be reusable, so you will have to write new requirements for each project. Second, it often takes more effort to write high quality, reusable requirements than it does to write requirements intended for just one project.

This extra effort pays off in the long run. According to a 2010 survey by Valley Forge Consulting of teams practicing requirements reuse, the average reuse rate was 45 percent; however, 16 percent of survey participants reported high reuse rates in the range of 80 to 100 percent. The study report found that 16 percent "indicates that implementing a highly effective requirements reuse process is achievable in practice."

To make sure writing reusable requirements is as painless as possible, keep the following best practices in mind.

1. Document the Requirements

As a first step, this one is fairly obvious. You can't reuse a requirement unless you have it documented somewhere. Create a separate, searchable repository for reusable requirements, and start building a pool of good candidates to use for future projects.

2. Tune Up Existing Requirements

It's unlikely you'll be able to reuse any requirements from past projects without making a few changes, so you'll need to examine your inventory of existing requirements to how they'll need to be tweaked to become reusable. Make sure the requirements you want to reuse have the necessary information, such as how exceptions should be handled. Rewriting these requirements to include this missing information not only makes them reusable, it also makes them more valuable to the project for which they were originally written.

3. Write Domain-Agnostic Requirements

If a requirement is too domain-specific, it probably won't be reusable. Try to keep each requirement generic enough so it can apply to many systems. Don't go too far, though; if a requirement is too generic, you won't save much effort because you'll have to fill in the details for the next project. It's a fine line to walk, which is one of the reasons why it can take more effort to write reusable requirements.

4. Avoid Excessive Granularity

You may think the answer to keeping requirements generic is to document the details of each requirement separately. Unfortunately, this creates more work in the long run, not less. In their book Software Requirements, 3rd Edition, Karl Weigers and Joy Beatty offer this cautionary tale:

"A team tasked with writing requirements for a new project was obsessed with reuse. The BAs thought that if they documented all the details for each requirement separately, then they could be reused. They ended up with more than 14,000 requirements! The repository contained entries that should have been just one requirement, but had been structured as a parent with multiple child requirements, each giving a specific detail about the parent. Requirements this detailed were only relevant to that one application."

The sheer number of requirements made testing a nightmare. Test cases took forever to write, and traceability became impossible to manage. These and related factors led to the project being a year late—and to add insult to injury, no reusable requirements were created.

5. Develop a Pattern

A requirements pattern can help you write highly reusable requirements. Stephen Withall, author of Software Requirement Patterns, says the aim of requirement patterns is to enable you to write higher quality requirements more quickly and with less effort: 

"They achieve these benefits by letting you take advantage of all the effort that went into writing them, because of the simple equation that says it's possible to devote considerably more time and thought to developing a pattern than you could ever afford to  expend on writing a single requirement. So a requirement pattern represents encapsulated expertise that you can call on whenever you need it."

Patterns help you write better requirements by keeping critical information from being overlooked. Because you start with a substantially‑written requirement, you can write reusable requirements faster and easier.

A requirement pattern can contain background information, advice, or links to other resources that might be helpful for writing highly reusable requirements.

6. Link the Dependencies

Some requirements need to be reused together. Either they depend on another requirement to work, or they have a requirement (or several) that depends on it to work. To ensure these dependent requirements don't get missed during reuse, establish links and make the dependents traceable to each other.

Most requirements management tools available today have some ability to link related items, either at the individual requirement level or at the document level. Document-level links don't provide enough traceability to be very useful, however. If possible, use a requirements management solution that links at the requirement level.

Conclusion

By implementing these six best practices, you can more easily reuse requirements written for previous projects. Documenting existing requirements and tweaking them for better reusability lays the foundation for reuse, which you can then build upon with generic, broad requirements. Establishing a pattern will help keep your focus on reusability when creating new requirements, and strong traceability will prevent dependents from being forgotten when you start a new project.

With a little extra effort on the front end, you'll soon have a pool of good reuse candidates, and you'll begin to see projects completed faster, cheaper, and with higher quality.


Related Articles

More...

Getting in touch with the leader in process-centric product development solutions is easy!