How to Simplify Requirements Gathering & More With Reuse
Reuse Software Requirements to Save Time
Reusing requirements helps teams save time and money — during requirements gathering and future product maintenance —without sacrificing quality. But it does come with challenges.
By following some best practices, however, you can ensure that the time you spend to make your requirements reusable will be well worth the effort.
What is Requirements Gathering?
Requirements gathering is the first part of the requirements management process in which you research, discover, and document the intended goals and capabilities of the solution you are building.
Requirements come in many types and styles, depending on your industry, the nature of your product, and preferred development methodologies. But no matter what you call them, you will likely have requirements that describe:
- The problems or objectives the solution is intended to solve.
- Who will use the solution.
- What capabilities the solution must have.
- Regulations, risks and constraints that impact the solution implementation.
[LEARN HOW TO: WRITE A SOFTWARE REQUIREMENTS SPECIFICATION >>]
Is Requirement Reuse for You?
Most discussions of requirements gathering focus on the best ways to solicit requirements from stakeholders and customers. The focus is often on the 1.0 version of whatever you’re building and not on considerations of how to leverage that initial effort in the future.
If you’re expecting to create future versions of your product or build other products using some of the same features and constraints already identified, then your product is a good candidate for benefiting from requirements reuse.
Reusing requirements is both faster and cheaper than writing all new requirements. Existing requirements can act as a sort of checklist to make sure requirements aren’t overlooked. And quality gets a jumpstart because reused requirements have already been through a round of validation and testing.
[WHITE PAPER: 9 TIPS FOR WRITNG USEFUL REQUIREMENTS >>]
While reusing requirements is meant to save you loads of time, there are two catches:
- Existing requirements selected for reuse still need to be reviewed for accuracy and applicability as part of your requirements gathering effort. But that’s still less work than starting from scratch.
- Writing reusable requirements might mean rewriting old ones. This can take some additional time on the front end.
But, this extra effort will pay off in the long run, as you reuse requirements over and over again. Let’s look at the benefits and how to do it.
6 Tips For Reusing Your Requirements
So how do you go about establishing reusable requirements in a sustainable way? Here are 6 pro tips.
1. Establish a Repository
Obviously, your first step is to create a distinct, searchable repository for reusable requirements. Ideally, this repository would be the same as what you’re using for managing requirements throughout the product lifecycle. The key is to set this up using metadata. You’ll need metadata to easily search through a large collection of requirements and identify related requirements.
2. Tweak Existing Requirements
You likely have many requirements that can be reused if you make some minor changes to specifics. For example, if you created an app for an iPhone, a requirement on that product may have been “Accept payment using Apple Pay.” By tweaking this requirement to something more generic, like “Accept payment,” it can now be reused for apps on other platforms.
3. Write New Requirements with the Intention of Reuse
For all new requirements you write, consider how it can be worded so that you can use it later. You want to make it general enough to fit other projects, but still useful now. While this does take more time, it saves you even more time on future projects.
4. Beware of Unnecessary Granularity
By keeping requirements generic, it may be tempting to document specifics of each requirement separately. This creates more time, not less. Consider the example from this book of requirements best practices:
“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.”
5. Develop a Pattern
A requirement pattern specifies the information that should be gathered, elements to include, and other advice to help identify issues that merit attention. Writing requirements based on patterns ensures that critical information is not overlooked. And you end up with a substantially-written requirement that is easier to create for reuse.
6. Link Dependencies
You’ll have requirements that need to be reused together. One may depend on another requirement to work, or another requirement might depend on it to work. Establish links that make dependencies traceable to each other so they don’t get missed during reuse. Most requirements management solutions give you the ability to link related items.
Make Requirements Management Even Easier
If you’re manually tracking requirements, the most effective way you can save time is to use a requirements management solution. Helix RM makes it easy to share your requirements between releases and products. It provides traceability to easily see what dependencies exist — and the impact of a change made to a requirement.
You can try it free for 30 days — see the difference it makes for your own requirements.