Reusing Requirements - Part One
Learn how to Reuse Requirements in Azure DevOps
Azure DevOps is an incredible platform that provides a single-source of truth.
For many teams that statement alone is enough for teams to consider using the world’s leading ALM platform for their requirements management as well. Being able to tie development tasks to requirements, and those to Test Cases is hard to pass up.
But what if you don’t care about having all of the features of a full ALM platform?
What if you only need a solution for your Requirements Management needs?
You can use all of the rich features of Modern Requirements4DevOps to turn your Azure DevOps project into a full-featured Requirements Management solution. One of these features is the ability to reuse requirements across different projects, collections, and servers using the Modern Requirements4DevOps Reuse tool.
Looking to reuse requirements?
You’re in the right place.
What you’ll learn in this short article:
- Benefits of reusing requirements
- The three methods of reusing requirements
- How reusing requirements can be used effectively
The Benefits of Reusing Requirements
When we talk about the benefits of requirements reuse there is one thing that needs to be addressed first.
The most common question I get from hardware teams is “How could this possibly benefit teams who aren’t software-related?”
So before we begin, requirements reuse is not just for software teams.
Requirements reuse is a topic that often catches people’s attention.
This is because in the world economy we are seeing companies dramatically increasing in specificity. This leads to companies building products within a specific domain, or around a given solution, and really narrowing in on the few things they can be really successful at.
This means that as you build projects, solutions, or systems, often a company can usually reuse elements of a previous project that could have been similar. This is where requirements reuse fits into the picture.
Teams who build web applications might build a new project using the same technologies or setup as a project they tackled previously. They may also adopt a similar interface structure, backend architecture, etc.
By enabling a team to reuse those requirements in the next project they are able to reduce the amount of overhead required in getting started in a new project.
For some people this might already be obvious.
What might not be obvious, however, is that reuse can also be a great way of handling requirements that are scoped above the project level. This would include non-functional requirements, or risks that need to be considered as a company-wide mandate. This would even go so far as to allow your team to reuse requirements whose purpose is strictly regulatory or compliance-centric. This functionality can be extended to software and hardware teams alike, and can even help teams product teams devoted to a physical component or deliverable.
In this article I’ll show you the three ways in which you can reuse requirements from one project to another, and in a later article we will discuss how you can build up requirements repositories can act a master copy of a given set of requirements.
The Three Ways of Reusing Requirements.
When discussing the reusing of requirements there are three major items to consider.
- How do I copy requirements to a new project?
- How do I clone requirements in the same project?
- How do I do both of those operations with a list of requirements?
In Azure DevOps there is only limited functionality for the first two options.
But when you add Modern Requirements4DevOps into your Azure DevOps environment, requirements reuse meets its full potential.
Watch the video to see how.
Time to Read: 10 minutes
Three Basic Ways of Reusing Requirements
In this video we cover the three basic ways of using reusing requirements using the native Azure DevOps modules, and the Modern Requirements4DevOps Reuse tool.
How to Reuse Requirements Effectively.
After watching the above video it is obvious that the Modern Requirements4DevOps Reuse tool is effective for reusing requirements.
It offers full control over the requirements you are choosing to reuse, allows you to apply customization to those requirements, and allows you to link the requirements to the source work item. It also includes the essential benefit of being able to reuse requirements across different servers, collections, and projects.
This means no matter where you want to send requirements, you can do so using the Modern Requirements4DevOps Reuse tool.
But there are some ways that you can use the Reuse tool more effectively.
The first notable mention is by pairing the reuse tool with the Modern Requirements4DevOps Baseline tool.
What is a Baseline?
Many teams use Baselines of requirements and don’t even realize they do.
A Baseline is a snapshot of Work Items at a given point in time.
For many teams they simply use Microsoft Word documents as Baselines as they have at some point created documentation.
When talking about capturing requirements at a given time, there are many reasons why the Modern Requirements4DevOps feature is better than the traditional Microsoft Word approach. With Modern Requirements4DevOps Baselines, you are able to capture any single, or set of, requirements as they were on any date of your choosing.
This means if you want to capture your requirements as they are two weeks ago, you can easily create a Baseline for those requirements on that date. This lends itself directly to the benefits of the Reuse tool added by Modern Requirements4DevOps.
By combining the Reuse tool with our Baseline, you can not only choose the set of requirements you want to reuse but also the version of those requirements as well. This allows you to take the best and most applicable version of your requirements forward to your next project.
The next notable mention is to us the prefix / postfix / and other operations effectively when reusing requirements.
When reusing requirements the Modern Requirements4DevOps Reuse tool allows you to customize how the requirements being reused will appear in their destination project.
The screen which allows you to do this can be seen below:
Using the above feature will allow you to easily add a prefix or postfix to the requirements once they reach your chosen destination project.
As seen above, you can also choose to send these requirements to a specific area path (like hardware or software for instance), or even into a given iteration so you can decide when these requirements get handled.
The most commonly used feature in the field options however, is the ability to add a tag.
Often when you are sending requirements from one project to another you want to be be able to easily identify and trace those requirements in your destination project. Adding a Tag will allow you to do this.
For example, if you were sending requirements from Project A to Project B, you could add a tag such as “imported from Project A”.
This would tag the work items you created in Project B to be easily located and dealt with.
What is the link with Source Work Item Option?
This option allows you to establish a link between the work item you are reusing and the work item you create in your destination project.
What link does it create?
It links your new destination work item to your original work item via the “Related” link.
In the below image you can see a Bug I have sent from one project to another, using both the prefix “TEST – ” and the “Link to source work item” options set.
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from.
While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
Want to experience reuse's full potential?
Try Modern Requirements4DevOps for free today.
We offer you the ability to try our Requirements Management solution in your own Azure DevOps environment, or in an environment we supply that includes sample data.