Reusability Requirement

Definition

Reusability Requirement

any developer-oriented quality requirement that specifies a minimum required amount of the quality factor reusability

Objectives

The typical objectives of an reusability requirement are to:

• Increase current reuse by specifying the percentage of the application’s components and documentation that shall be reused from existing reusable work products.
• Increase future reuse by specifying the percentage of the application’s components and documentation that shall be potentially reusable for purposes other than originally intended (e.g., as part of future applications), whereby reusable includes identification, classification, modification, testing, certification, and actual incorporation or use in other situations.

Examples

The following are typical examples of reusability requirements:

• “A minimum of 40% of the architecture of the application shall be reused from one of the standard reference architectures stored in the reuse repository.”
• “A minimum of 30% of the design of the application shall be reused from reusable designs stored in the reuse repository.”
• “A minimum of 30% of the software of the application shall be reused from reusable software that is either stored in the reuse repository or purchased commercially off the shelf (i.e., COTS software).”
• “The application shall use one of the reusable test harnesses stored in the reuse repository.”
• “A minimum of 40% of the application’s documentation shall be potentially reusable on future endeavors.”
• “A minimum of 30% of the application’s software shall be potentially reusable on future endeavors.”

Guidelines

The following guidelines have been found to be useful when producing reusability requirements:

• The scope of a reusablity requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
  • A document
• Reuse Types.
  Reusability requirements can specify:
  • Reuse as is (e.g., reuse of a component or subcomponent without modification).
  • Reuse with minor modifications (e.g., reuse of a component after modifications to its design or implementation).
  • Reuse with major modifications (e.g., reuse of a component after modifications to its architecture).
• Work Product Reuse.
  Reuse of any work product including (but not limited to):
  • Management Reuse
    Reuse of management documents.
  • Process Reuse
    Reuse of process descriptions and associated conventions including standards, procedures, templates, and checklists.
  • Metrics Reuse
    Reuse of metrics, metrics models, and metrics plans.
  • Training Reuse
    Reuse of training materials.
  • Requirements Reuse
    Reuse of requirements, requirement models, and requirements documents and specifications.
  • Architecture Reuse
    Reuse of architectures, architectural mechanisms, and architectural documents.
  • Design Reuse
    Reuse of designs, design models, and design documents.
  • Implementation Reuse
    Reuse of data, hardware, and software components and subcomponents.
  • Test Reuse
    Reuse of test data, test cases, test scripts, test harnesses, and test plans.
• Reuse Scale.
  Reuse can occur at any scale such as:
  • Reuse of entire “boilerplate” sections of documents down to individual sentences such as textual requirements.
  • Reuse of entire software components through reuse of individual classes or operations.
• Reuse Validation.
  In order to validate requirements specifying potential reusability on future applications, the document or component must meet acceptability criteria (e.g., in terms of quality, documentation, and associated tests) published by the reuse organization. Of course, one does not know if the potentially reusable as documentation and components are in fact reusable until they have actually been reused several times during future endeavors.