How Deep Does the Reuse Rabbit Hole Go?
Introduction
Requirements reuse is a topic that has been discussed and documented for a long time. In 2010, Yuri Chernak describes the state of reuse, as well as the challenges for broad adoption. Requirements reuse holds the promise of “faster, better, cheaper.”
The company I work for recently published a study that quantifies the importance of reuse to product-development professionals: 95% said reuse is important to delivering on time.
It all boils down to efficiency. Yet, despite all the enthusiasm, reuse is rarely implemented in a way that provides the promised value. Several key factors are associated with this:
- The definition of reuse needs to get beyond “copy and paste.”
- Successful reuse requires an organizationwide adoption model.
- Technology isn’t always aligned with desired capabilities.
Let’s go through each in turn.
Defining Reuse
According to BABOK, reuse falls under the “Requirements Management & Communication” section. In general, the BABOK is fairly light on this topic, referring to reuse as a “repository,” and advising businesses to identify a person “to manage the repository.” There’s mention of “impact analysis,” and that requirements should be identified as “candidates” based on an organization’s long-term needs.
These are all important concepts, some of which will be addressed in more detail here, but I think a more practical definition is in order. Here’s my attempt at defining reuse:
Reuse is an agreed upon policy, where by, separate or related teams, projects, or departments, are able to utilize previous work done in such a way that new work can be accelerated. In addition, on going changes to the reused information should be shared, such that the different entities can accept, reject or merge the work.
The idea here is that while many people view reuse in terms of copy and paste, or linking, it is more around utilizing work done, and keeping that work synchronized over time and across teams.
Example: Team A has just completed building a product. The product could be hardware, software or even a combination. Now Team B is about to embark on a new product that is very similar to Team A’s product. In this scenario, Team B is able to utilize not only pre-existing requirements but also any downstream artifacts such as Use Cases, Non-Functional requirements, regulatory laws, stories, test artifacts and of course the coverage or traceability between them. By reusing this information, Team B has a significant leg up and has saved a lot of work and time and time, (at least 25%, according to the survey).
If understanding the definition of reuse is the important first step, the second step is to share this definition organizationwide.
<< CAPTION: reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size>>
Successful reuse is an organizationwide adoption
Based on my definition, reuse becomes increasingly necessary and provides exponential benefits as products and teams increase in size; however, as this size increases, reuse also becomes increasingly complex to manage. Therefore, the problem that organizations face is not if reuse should be implemented, but rather how. Like different methodologies, the implementation of reuse is going to vary based on the type of product, the team size, and the organization’s ability to adapt and adopt.
For this reason, it is important to carefully analyze areas where teams would benefit from reuse and then work backwards to determine the implementation strategy that would have helped. It is also important to find incremental wins while keeping an eye on the big picture so you can expand your reuse strategy over time. For example, you may start by simply reusing the requirements from one product to another, working to keep them synchronized. Later you could continue looking at creating a central repository of common requirements. Finally, you could start looking beyond just the requirements and begin pulling in traced artifacts. This last item is important; reuse is not just a Business Analyst problem, it impacts the entire team.
As you can see though, this kind of reuse strategy is very difficult to do manually with just documents. To do it right will require more sophistication and better technology.
Technology isn’t always aligned with desired capabilities
Our desires tend to exist in a realm just ahead of what’s possible. Sometimes technology evolves to meet those desires, even producing unexpected outcomes. Some examples might be Mark Twain’s prediction of the Internet in 1898 through a sci-fi story, or on a more related note, the 2001 Agile manifesto, which called for better collaboration several years before the tools and technologies necessary to facilitate true collaboration were even available; hence, the early push toward entire teams being confined to a single room around a single table. It wasn’t until 2004, when the social networks emerged, that we began to see an evolution in business software and human behavior that favored the kind of collaboration necessary to push Agile into the enterprise. This area continues to rapidly evolve.
The same is true with reuse. The topic has been around for years but until recently, it was very difficult to manage complex reuse without adding an exponential amount of administrative work to keep track of everything. Too much reliance on the trust of too few, rather than on tools or technology.
Some of the solutions today offer some form of reuse, all of which are designed to enable teams to better reuse work that has been done. This might be just around requirements but I believe it goes deeper than that.
How deep does the rabbit hole go?
This brings me to the final question: how deep does the rabbit hole go? Well, considering that we could start with the most basic of copy and paste, this does feel like the beginning. As we go deeper we see that requirements are being shared but remain the same, existing in different places. Deeper still, we see the requirements are being separated but stay synchronized through a change-control process. Digging further down, the lines become blurred as we question what a requirement really is: the text, the meta-data…what then should be synchronized… all aspects of the requirement?, or just certain ones? What about any attachments associated with the requirement, or relationships to upstream or downstream? Does the traceability remain or do the test cases also get reused?
Reuse is a powerful strategy. When done right, reuse provides huge rewards. To reap those rewards as a user, manager or executive taking the plunge, you’ll need to be smart and communicative to avoid losing your head.
Don’t forget to leave your comments below.