What Is Reusing Requirements?

Although they might have many of their own special features, the products you build are not completely unique. Someone, somewhere, has already built a product containing some requirements that are germane to your current work. When you take advantage of work that has already been done, your efficiency as a requirements gatherer increases significantly. Early in your requirements projects look for reusable requirements that have already been written, and incorporate these "free" requirements into your own project. See Figure 13.1.

Figure 13.1.

Reusing requirements entails making use of requirements written for other projects. They can come from a number of sources: a reuse library of specifications, other requirements specifications that are similar or in the same domain, or informally from other people's experience.

But these requirements are not exactly free: You have to do something for them. Successful reuse starts with having an organizational culture that consciously encourages reuse rather than reinvention. If you have this attitude, then you are in a position to include requirements reuse in your requirements process.

Successful reuse starts with having an organizational culture that consciously encourages reuse rather than reinvention.

Naturally, to determine whether you have any relevant reusable requirements, you need to know something about the work that you are investigating. When you run a project blastoff meeting, pay particular attention to the first seven sections of the requirements specification:

1. The Purpose of the Project: Are there other projects in the organization that are compatible or that cover substantially the same domains or work areas?

   

   Refer to Chapter 3 for more on how to run a project blastoff meeting.

   
   

2. The Client, the Customer, and Other Stakeholders: Can you reuse an existing list of stakeholders, a stakeholder map, or a stakeholder analysis spreadsheet?

3. Users of the Product: Do other products involve the same users and thus have similar usability requirements? Also refer here to stakeholder maps and spreadsheets.

4. Mandated Constraints: Have your constraints already been specified for another project?

5. Naming Conventions and Definitions: You can almost certainly make use of parts of someone else's glossary, rather than having to invent all of your own glossary.

6. Relevant Facts and Assumptions: Pay attention to relevant facts from recent projects. Do other projects' assumptions apply to your project?

7. The Scope of the Work: Your project has a very good chance of being an adjacent system to other projects that are under way in your organization. Make use of the interfaces that have been established by other work context models.

When you are looking for potentially reusable requirements, don't be too quick to say your project is different from everything that has gone before it. Yes, the subject matter is different, but if you look past the names, how much of the underlying functionality is substantially the same? How many requirements specifications have already been written that contain material that you can use unaltered, or at least adapted, in your own specification? See Figure 13.2.

Figure 13.2.

At project blastoff time the subject matter of the context, together with its adjacent systems and boundary data flows, should indicate the potential for reusing requirements from previous projects.

For more on stakeholder maps and stakeholder analysis, see appendix D, Project Sociology Analysis Templates.

We have found that significant amounts of specifications can be assembled from existing components rather than having to be invented from the ground up.

The blastoff deliverables provide a focus for identifying reusable knowledge that might not otherwise be found.

The stakeholders who participate in the blastoff meeting are wonderful sources of reusable components. Ask them about other documents that contain knowledge relevant to the work of the project. Consider whether someone else has already investigated subject matter domains that overlap with your project. Closely examine the blastoff deliverables. They provide a focus for identifying reusable knowledge that might not otherwise be found.

When you are trawling for requirements, continue to look for reusable requirements by asking the people you interview about them: "Have you answered these questions, or questions like them, before? Do you know of documents that might already contain the answers to these questions?" This fairly informal approach means that you encounter potentially reusable requirements in many different forms. Some are precisely stated and hence directly reusable; others merely provide clues or pointers to sources of knowledge. One of the benefits of using a disciplined process for writing requirements specifications is that you naturally produce requirements that are more easily reusable by future projects.

One of the benefits of using a disciplined process for writing requirements specifications is that you naturally produce requirements that are more easily reusable by future projects.