Maintainability Requirement

Definition

Maintainability Requirement

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

Objectives

The typical objectives of a maintainability requirement are to:

• Ensure that minor defects in an application or component are easy to correct.
• Ensure that minor enhancements to an application or component are relatively easy to implement.
• Minimize maintenance costs.
• Minimize maintenance organization staffing needs (e.g., to free up maintenance programmers for new development).

Types

The following are different types of maintainability requirements:

• Correctability Requirements (a.k.a., corrective maintenance),
  which is restricted to fixing defects.
• Extensibility Requirements (a.k.a., adaptive maintenance),
  which is restricted to minor enhancements.

Guidelines

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

• The scope of a maintainability requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
  • A document
• Clearly differentiate between maintainability:
  • Goals (which are typically inconsistent, untestable, ambiguous, etc.):
    • “The architecture, design, implementation, and documentation of the application shall minimize the maintenance costs.”
  • Requirements (which must be consistent, testable, unambiuous, etc.):
    • “The average person-time required to fix a category 3 defect (including regression testing and documentation update) shall not exceed two person days.”
    • “The average person-time required to fix a category 2 defect (including regression testing and documentation update) shall not exceed one person week.”
    • “The average person-time required to make a minor enhancement (including testing and documentation update) shall not exceed one person week.”
• Because maintainability requirements only refer to modifications that are made between releases of major new versions of the application or component (i.e., development that involves changes to the architecture and significant portions of the design and implementation), they are typically restricted to the correction of minor defects and the production of minor enhancements.
• Maintainability should include:
  • Correcting defects in or updating the associated documentation.
  • Regression or new testing.
• Whenever possible, maintainability requirements should be specified:
  • Quantitatively.
  • In terms of mean and maximum:
    • Times to locate, repair, and test minor defects or make minor enhancements.
    • Down (turnaround) times.
    • Times between maintenance actions (frequency of preventative maintenance).
    • Maintenance person-hours per specific maintenance task.
    • Maintenance hours per operating hour.
    • Maintenance cost per operating hour.
    • Maintainability requirements may be specified in terms of average person-time or cost to correct
  • In terms of the conditions under which the application or component is being maintained (e.g., the size and structure of the maintenance organization in terms of staff size, roles and skills levels, and support equipment).
• Because maintainability requirements can be difficult to quantify, they may (if necessary) be occasionally specified more as desired goals than as actual validatable requirements. Nevertheless, they should not be unnecessarily specified in terms of architectural, design, and implementation constraints and the use of industry best practices that tend to produce maintainable applications and components when followed such as:
  • Layered architectures.
  • Modular software.
  • Information hiding of implementation.
  • Well-defined interfaces.
  • Object-orientation and component-based development.
  • Complete and current documentation.
  • Adherence to project conventions.