- An Investment Story
- Investing in Requirements
- Return on Investment
- Investment Risks
- What to Invest In?
- To Invest or Not to Invest
- Investing in Requirements
- Size of Requirements
- The Value of Requirements
- Reusing Requirements
- What Do I Do Right Now?
- What's the Least I Can Get Away With?
- Additional References for Requirements Value
This chapter is from the book
This chapter is from the book
This chapter is from the book
Reusing Requirements
You are considering investing in requirements with the objective of a payback on investment. A final consideration is whether the requirements have a value after they have been used on your current project. To put that another way, can you think of the requirements you gather as business assets? They deliver a further payback on your investment when you recycle them on subsequent projects.
You are probably not reusing only one or two requirements—no jus tification exists for doing so. However, if we look at the idea of clusters of requirements, then reuse becomes much more viable. Earlier in this chapter we mentioned the idea of clusters, or units of requirements (work context, product context, business use cases, product use cases, functional requirements, nonfunctional requirements, constraints) as an investment vehicle. Figure 2.6 identifies these units of potentially reusable requirements and the associations or relationships among them.
)
Figure 2.6 This class model shows units of requirements that are potentially reusable. The * indicates that many instances exist of the entity at that end of the associa tion. For example, a Product Scope may have many Product Use Cases, but the latter belong to a single Product Scope. The triangle shows that Functional Requirement, Nonfunctional Require ment, and Constraint are all types of requirements.
Requirements reuse depends first on the ability to identify reusable requirements, and second on having requirements reuse as part of your requirements process. Our experience shows many projects have significantly overlapping requirements. By abstracting and looking at the functionality, and for the moment ignoring its subject matter, we have been able to identify whole clusters of requirements in which simple subject-name changes have yielded significant portions of a functionally correct specification.
We have also learned many projects can save considerable time by intentionally looking at existing requirements documents. The analyst trawls through existing specifications looking for requirements that can be reused. It helps to ignore the names of the objects being manipulated, and concentrate instead on the abstract functionality.
Identifying Reusable Requirements
Even if you have not been consciously producing reusable requirements, you are sure to have many potentially reusable requirements already existing in your organization. The chart shown in Figure 2.7 suggests some of the places you might find them. Use it as a checklist to help take advantage of reuse opportunities.
Table 2.7. This chart summarizes potentially re usable requirements components along with suggestions for where to find them. Its intended use is as a checklist of reuse opportunities. The more progress you make toward formal izing reuse, the more consistent items in the Where to Look column will become. You should update the chart with places from your own environment.
|
Reusable Requirements Components |
||||||||
|
Where to Look |
Work Context |
Business Event Response |
Product Context |
Product Use Case |
Functional Requirement |
Nonfunctional Requirement |
Constraint |
Design Requirement |
|
Project Goal Descriptions |
x |
x |
x |
|||||
|
Work Context Model |
x |
x |
x |
|||||
|
Business Task Descriptions |
x |
x |
x |
x |
x |
|||
|
Business Process Models |
x |
x |
x |
|||||
|
Business Scenarios |
x |
x |
x |
x |
||||
|
Business Data Models |
x |
x |
||||||
|
Requirements Process Patterns |
x |
x |
x |
|||||
|
Requirements Data Patterns |
x |
x |
x |
|||||
|
Product Context Models |
x |
|||||||
|
Product Use Case Models |
x |
x |
||||||
|
Product Scenarios |
x |
x |
x |
x |
||||
|
Product Sequence Diagrams |
x |
x |
x |
x |
x |
x |
||
|
Product Class/Data Models |
x |
x |
||||||
|
Atomic Requirements Definitions |
x |
x |
x |
x |
||||
|
Technical Architecture Models |
x |
x |
||||||
|
Design Patterns |
x |
x |
For example, the checklist identifies a dozen potential sources of reusable functional requirements and six potential sources of constraints. There will be others within the documents and models produced by your organization. The chart can help you get started. Your organization should update the list when discoveries take place, for the benefit of future requirements projects. The more consistent your requirements deliverables, the more likely you can reuse them as requirements on another project.
Your Process for Reusing Requirements
The best advice we can give you is to start each of your projects with a stock-take and use potentially reusable components as a starting point.
This does not have to turn into a bureaucratic process. It simply means spending some time (maybe a few hours) looking around before starting detailed work. We suggest drawing a quick work context diagram of your project. Then within this scope look for potentially reusable requirements components using the chart in Figure 2.7 as a guide. The questions to ask are:
- Does the component contain any of the same data bounded by the interfaces on my project's work context diagram?
- Does the component refer to any of the adjacent systems mentioned on my project's context diagram?
- Does the component contain any business rules that contribute to my project's goals?
For each of the potentially reusable components you identify, consider whether it will save you time by giving it the essence test (see Figure 2.8). This test asks what percentage of the component exists because of essential business rules versus what percentage exists because of a particular solution to meeting the business rules.
)
Figure 2.8 The essence test evaluates the percentage of the content of a component related to the essential business within the domain. The higher percentage of essence, the more likely the component is reusable.
For example, one of us, Suzanne, undertook a project with an insurance company. The project team wanted to reuse the business data model. However when we applied the essence test we discovered that it was a business data model in name only. It had been partitioned according to a particular database implementation technology and contained many attributes such as keys and pointers that existed because of the implementation.
Because of that unique implementation, the model was very difficult to reuse: Business requirements data (claims, premiums, policies, bonuses, rates) were extremely fragmented and confused as a consequence of the number of implementation attributes. It was quicker to start from scratch—this annoyed the business experts because we had to ask them questions the other project group had already asked. If the business data model had truly been a specification of business requirements rather than a specific implementation, we could have reused the business knowledge it contained.
Components containing less than 60% of essence are probably going to be too implementation-specific for reuse. You would spend too much time removing the implementation details and reorganizing them so you could figure out their meaning in terms of the business requirements. For more on how to discover the essence of a system, please read Essential Systems Analysis by Steve McMenamin and John Palmer.[4] Also, please refer to Chapter 4—Learning What People Need, which contains more on essence.
The approach of considering requirements reuse at the start of a project leads you toward treating requirements as continuing business assets rather than things that only apply to one project.