Requirements Reuse

Definition

Requirements Reuse

the requirements engineering task during which all or part of existing reusable requirements work products are identified, evaluated for relevancy, and where appropriate reused (possibly with modification)

Classification

As illustrated in the preceding figure, Requirements Reuse is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Engineering Task
• Subclasses: None

Responsibilities

The typical responsibilities of Requirements Reuse are to:

• Improve the quality of the requirements by reusing requirements of known high quality.
• Increase requirements team productivity by eliminating most of the work of re-elicitating, reanalyzing, and respecifying them.
• Decrease time to market by eliminating redundant requirements engineering effort.
• Decrease development costs by eliminating redundant requirements engineering effort.

Preconditions

Requirements reuse can typically begin when the following preconditions hold:

• The requirements team is staffed and adequately trained in requirements reuse.
• Relevant reusable requirements exist in existing documents from previous endeavors:
  • Glossaries identify and provide meanings for reusable concepts from the application domain.
  • System requirements specifications contain reusable:
    • Functional requirements.
    • Data requirements.
    • Quality requirements.
    • Constraints.
  • They are stored in one or more reuse repositories that are available to the requirements team.
  • They are stored informally in reusable requirements specifications and patterns.

Completion Criteria

Requirements reuse is typically complete when the following postconditions hold:

• Potentially reusable requirements have been identified and reused.

Steps

Requirements reuse involves the following teams collaborating with the reuse organization to perform the following steps in an iterative, incremental, parallel, and time-boxed manner:

• Business Strategy Team during business engineering:
  • Identify reusable parts of relevant requirements documents:
    • Browse (e.g., by project, document, keywords) the reuse repositories to identify relevant strategy and vision documents (i.e., customer analyses, market analyses, user analyses, business vision statements, glossaries).
    • Identify potentially reusable parts of these documents.
    • Determine if the potentially reusable parts are actually reusable.
  • Modify potentially reusable parts to make them actually reusable.
  • Reuse these parts in the requirements documents.
• Technology Strategy Team during business engineering:
  • Identify reusable parts of requirements documents:
    • Browse (e.g., by project, document, keywords) the reuse repositories to identify relevant documents (i.e., technology analyses, glossaries).
    • Identify potentially reusable parts of these documents.
    • Determine if the potentially reusable parts are actually reusable.
  • Modify potentially reusable parts to make them actually reusable.
  • Reuse these parts in the technology analysis document.
• Requirements Team during application development:
  • Identify potentially reusable application requirements:
    • Browse (e.g., by project, document, keywords) the reuse repositories to identify relevant documents (e.g., application vision statement, requirements specifications, glossaries).
    • Use the operational goals (major functions) documented in the application vision statement (AVS) and the standard "function to use case" mapping to identify relevant reusable use cases in the repositories.
    • Use the quality goals in the AVS to identify reusable quality requirements.
  • Determine if the potentially reusable requirements are actually reusable.
  • Modify potentially reusable requirements to make them actually reusable.
  • Reuse the requirements in the requirements specifications.

Techniques

Requirements reuse can typically be performed using the following techniques:

• Reuse repositories.
• Search engines.
• Librarian-assisted searches.

Work Products

Depending on the type of endeavor (business engineering or application development), requirements reuse typically results in the reuse of all or part of the reusable parts of the following work products:

• During Business Engineering:
  • Customer Analysis, which documents the results of the analysis of the customer organization's current business.
  • Market Analysis, which documents the market in which the customer organization's applications must compete.
  • Technology Analysis, which documents the results of the analysis of technology trends that will impact the customer organization's applications.
  • User Analysis, which documents the results of the analysis of the customer organization's user organizations.
  • Business Vision Statement, which documents the customer organization's vision of itself.
  • Glossary, which is used to formally define the abbreviations, accronyms, and terms used a business.
• During Application, Component, and Reusable Requirements Development:
  • Application Vision Statement, which documents the customer organization’s vision of a single application.
  • Requirements Executive Summary, which is used to formally summarize the requirements for the customer.
  • System Requirements Specification, which is used to formally specify the functional requirements, data requirements, quality requirements, and constraints.
  • External API Specification, which is used to formally specify any external application programmer interfaces.
  • Glossary, which is used to formally define the abbreviations, accronyms, and terms used on an endeavor.
  • Domain Model Document, which uses an object model to formally document the relationships between application domain concepts defined in the glossary.

Guidelines

• Requirements can be reused either as is or reused with modification.
• Individual requirements are more likely to be reusable than entire sections of requirements specifications.