• Summary

<aside> 🗨️ Requirements reuse sounds like a grand idea, but it isn’t always practical or appropriate

</aside>

Reuse barriers

<aside> 💡 It will likely take more time and effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project

An organization that is serious about reuse needs to establish some infrastructure to make existing high-quality requirements knowledge accessible to future BAs and to foster a culture that values reuse

</aside>

<aside> 💡 Missing or poor requirements

• Not existing requirements. A common barrier is that the requirements developed on previous projects weren’t documented, so it’s impossible to reuse them
• Bad requirements. Even if you find a relevant requirement, it might be badly written, incomplete, or a poor fit for your present circumstances
• Obsolete requirements. Even if they’re documented, the original requirements for an old application might not have been kept current as the application evolved over time, rendering them obsolete </aside>

<aside> 💡 NIH (Not Invented Here) syndrome

• Some people are reluctant to reuse requirements from another organization or generic requirements found in a public collection. That may be true but often this indicates an inflexible attitude
• Requirements written elsewhere could be harder to understand: terminology could be different; the requirements might refer to documents that are unavailable; you might not be able to discern the context of the original requirements; and important background information could go unexplained
• It may be easier to write new requirements. A BA might correctly decide that it takes less work to write new requirements than to understand and fix up the existing ones </aside>

<aside> 💡 NAH (Not Applicable Here) syndrome

• Practitioners protest that a new process or approach does not apply to their project or organization
• “We’re different,” they claim. The members might feel that their project is unique, so no existing requirements could possibly apply. Sometimes that’s true, but often NAH indicates an inflexible attitude </aside>

<aside> 💡 Writing style

• Adopt standard notations. It’s best to adopt some standard notations for documenting requirements to facilitate reuse, such as using patterns
• Write at the common level of granularity. If requirements are written at a common level of granularity, it’s easier for future BAs to search for candidate requirements at the right level of detail
• Use consistent terminology. You might overlook a potentially reusable requirement simply because some of the terminology involved is not the same as what your stakeholders are used to
• Remember that requirements written in natural language are notoriously prone to ambiguities, missing information, and hidden assumptions. These issues reduce their reuse potential
• Design constraints reduce reuse potential. Design constraints embedded in requirements will offer little opportunity for reuse in a different environment </aside>

<aside> 💡 Inconsistent organization

It can be difficult to find requirements to reuse because authors organize their requirements in many different ways: by project, process flow, business unit, product feature, category, subsystem or component, and so forth

</aside>

<aside> 💡 Project type

• Requirements tied to concrete technologies may be hard to reuse. Requirements that are tightly coupled to specific implementation environments or platforms are less likely to generate reusable requirements or to benefit from an existing pool of requirements knowledge
• Requirements may become obsolete quickly in some domains. Rapidly evolving domains don’t yet have a pool of requirements information to reuse; requirements that are relevant today might be obsolete tomorrow </aside>

<aside> 💡 Ownership

• Another barrier has to do with ownership. If you’re developing a software product for a specific customer, its requirements are likely the proprietary intellectual property of the customer
• You might not have the legal right to reuse any of those requirements **in a different system you develop for your own company or for other customers </aside>

Reuse success factors

<aside> 💡 Repository

• You can’t reuse something if you can’t find it. An enabling tool for effective large-scale reuse, therefore, is a searchable repository in which to store requirements information
• This repository could take several forms:
  • A single network folder. It contains previous requirements documents
  • A collection of requirements stored in a requirements management tool. It can be searched across projects
  • A database. It stores sets of requirements culled from projects for their reuse potential and enhanced with keywords to help future BAs know their origin, judge their suitability, and learn about their limitations
• Consider giving someone the responsibility to manage the reusable requirements repository. This person would adapt existing requirements knowledge as necessary to represent and store the assets in a form suitable for efficient discovery, retrieval, and reuse </aside>

<aside> 💡 Quality

• No one wants to reuse junk. Potential reusers need confidence in the quality of the information
• If a requirement isn't perfect, make it better. And even if a requirement you are reusing isn’t perfect, you should try to make it better when you reuse it. This way you iteratively improve a requirement over time, increasing its reuse potential for future projects </aside>

<aside> 💡 Interactions

• Use traceability links for dependent requirements. Requirements often have logical links or dependencies on each other. Use traceability links in a tool to identify these dependencies so people know just what they’re getting into when they select a requirement for reuse
• Reused requirements must conform to existing business rules, constraints, standards, interfaces, and quality expectations </aside>

<aside> 💡 Terminology

• Establish common terminology and definitions across your projects. It will be helpful for reusability. Terminology variations won’t prevent you from reusing requirements, but you’ll have to deal with the inconsistencies and take steps to prevent misunderstandings. Glossaries and data dictionaries are good sources of reusable information
• Create links from key terms to their definitions in the shared glossary. There is no need to incorporate an entire glossary into every requirements specification </aside>

<aside> 💡 Organizational culture

• Management should encourage reuse from two perspectives: contributing high-quality components with real reuse potential, and effectively reusing existing artifacts
• Look for the reusable requirements before creating requirements. In a reuse culture, BAs look at the reusable requirements repository before creating their own requirements. They might start with a user story or other high-level requirement statement and see to what extent they can populate the details through reuse of existing information
• Good culture can increase the productivity of the organization. A culture that encourages BAs to borrow first and create second, and that makes a little extra investment in making requirements reusable, can increase the productivity of both analysts and development teams and lead to higher-quality products </aside>