Reusing Requirements
In short Requirements, not just code, can be reused. Treating good requirements as a managed, versioned asset saves elicitation time, makes related products consistent and improves estimates, but only if someone keeps the material in reusable shape.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 18.
On this page
Key ideas#
What reuse buys you#
Wiegers and Beatty list faster and cheaper requirements work; consistency within an application and across related products (for example, the same text formatting across a product family shortens training); fewer defects and less rework; quicker reviews, because the text has been checked before; and better estimates, because you know what the requirement cost last time. Yet reuse is less common than you might expect. A survey the authors cite (Chernak) found that only about half of organizations reuse requirements, and the poor quality of existing requirements was the main obstacle.
Three dimensions#
- Extent: from a single statement, to a statement with attributes, to one with its context (tests, constraints, business rules), to a set of related requirements, to a set with design, up to a full package of requirements, design, code and tests, such as an error-handling or logging component.
- Degree of modification: used as is; only attributes change (priority, rationale); the wording changes; related items such as tests change too.
- Mechanism:
| Mechanism | Strength | Risk | Use when |
|---|---|---|---|
| Copy and paste | Simplest | Copies drift apart after edits | One-off reuse you will maintain separately |
| Reference to a shared source | One edit updates every user | An edit hits every user, intended or not | Stable, enterprise-wide content |
| Versioned item in a requirements tool | Each project can stay on a frozen version or upgrade | Needs a tool and discipline | Product families, shared components |
The authors favor the versioned approach: project B can keep version 1 of a requirement while project A moves on to version 2.
What is worth reusing#
- Within one product: user requirements, functional requirements, business rules.
- Across a product family: business objectives, context diagrams, ecosystem maps, stakeholder profiles, user archetypes, acceptance tests, glossary.
- Across the enterprise: business rules, security requirements, glossary.
- Across a business domain: process models, data models, regulatory requirements.
- For an operating environment or platform: constraints and interfaces.
Sets reuse better than isolated items. No team should have to reinvent password change and recovery requirements. Symmetric operations (undo and redo; create, read, update, delete) belong together.
For a product family, sort functionality into common (reuse the whole chain, from requirements to tests), optional (only in some products) and variant (slightly different in each). If products run on different platforms, reuse the requirements but not the design or code.
In a replacement project you reuse the old system’s requirements even if nobody wrote them down, by reverse-engineering its behavior. Lift them above implementation detail so you do not inherit the old platform’s accidental limits, and resist copying so much that you lose the point of replacing the system.
Barriers#
- Missing or poor requirements, the most common barrier.
- “Not invented here” (NIH): reluctance to use another team’s material, sometimes rational if it is poorly documented.
- “Not applicable here” (NAH): “we’re different”, often resistance in disguise.
- Different writing styles and levels of detail, which make a match hard to recognize.
- Embedded design constraints that tie a requirement to one platform.
- Inconsistent organization across projects (by process, by subsystem, by department).
- Ownership: requirements written for a client may legally belong to that client.
What makes reuse work#
A searchable repository, anything from a shared folder to a database tagged by source, applicability and constraints, and a named owner who keeps the content current and in a common format. Without an owner, the repository decays into a dump of stale documents.
How to apply it#
- Start with one recurring area: user accounts, notifications or audit logging.
- Rewrite those requirements in neutral form, without project names or screen details.
- Add attributes: source, where it applies, constraints, related tests and business rules.
- Store them in one place with versioning, and name an owner.
- On each new project, search the repository before eliciting from scratch, and record which version you took.
- Check contracts before reusing anything written for a client.
Example#
The Workshop, a fictional bike-repair chain, hires an outside development team that built a customer portal for another client last year. That portal’s account requirements (registration, password change, password recovery, lockout after repeated failed logins) look reusable for the booking app. The team first confirms the earlier contract allows reuse, strips out the other client’s terms and screen references, and stores the set as a versioned package. The front desk’s walk-in booking flow, by contrast, is specific to The Workshop and is written fresh.
Pitfalls#
- Copy-pasting everything → copies diverge; prefer references or versions.
- Reusing requirements tied to an old interface → restate the business need first.
- A repository nobody maintains → assign an owner before you start collecting.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 18.