Component Requirements Engineering

Definition

Component requirements engineering is a requirements engineering subactivity during which the requirements for a specific component are engineered.

Goals

The typical goals of component requirements engineering are to:

• Produce and maintain a complete set of high-quality requirements:
  • Functional Requirements
  • Data Requirements
  • Quality Requirements
  • External API Requirements
  • Constraints
• Produce requirements work products required as inputs by other project teams (e.g., the architecture and independent testing teams).
• Thereby help ensure that all project effort is based on the implementation of properly approved requirements.

Objectives

The typical objectives of component requirements engineering are to:

• Produce a formally documented consensus amoung all project stakeholdlers (e.g., client, users, project champions, project management, developers) concerning the:
  • Requirements for the component.
  • Scope of the component.
  • Boundaries of the component.
• Provide input (e.g., number of use cases and use case paths) to the endeavor’s cost and schedule estimation tasks.
• Provide a basis (e.g., use cases and use case paths) for the scheduling of the development cycle phases and builds.
• Maximize the quality of the requirements (e.g., correctness, completeness, consistency, testability, and understandability).
• Maximize the productivity of the requirements team (e.g., reuse of requirements, reuse of conventions, and existence of examples).

Preconditions

The component requirements engineering task typically may begin when the following preconditions hold:

• The initiation phase is started.
• The requirements team is initially staffed and adequately trained in requirements engineering.

Completion Criteria

The component requirements engineering task is typically complete when the following conditions hold:

• The customer’s vision for the component has been documented.
• The customer and user requirements for the component have been elicited, analyzed and specified.
• The associated deliverable work products in the requirements work product set have:
  • Passed evaluation by the appropriate inspection team.
  • Been accepted by the customer representative.
  • Been delivered to the customer organization.

Tasks

The component requirements engineering task typically involves the following teams performing the following requirements tasks in an iterative, incremental, parallel, and time-boxed manner:

• Requirements Team, which performs:
  • Component Visioning
  • Requirements Reuse
  • Requirements Identification
  • Requirements Analysis
  • Requirements Specification
  • Requirements Management
• Architecture Team, which performs:
  • Requirements Analysis
    (help prioritize the requirements from the standpoints of implementability and testability).
• Customer Representative, who performs:
  • Requirements Analysis
    (help prioritize the requirements from the standpoints of business and marketing needs).

Environments

The component requirements engineering task is typically performed using the following environment(s) and associated tools:

• Development Environment:
  • Whiteboards and cards for Requirements Reuse
  • Upper CASE Tools for Requirements Analysis
  • Documentation Tools for Requirements Specification
  • Requirements Tools for Requirements Management

Work Products

The component requirements engineering task typically results in the production of the following work products from the requirements work product set:

• Actor Cards, which are large index card used during the requirements identification task to informally document a single actor of the application.
• Use Case Cards, which are large index card used during the requirements identification task to informally capture the cohesive set of operational requirements associated with a single use case of the application.
• Requirements, which specify the mandatory behaviors, characteristics, interfaces, and constraints of the application.
• Component Vision Statement, which documents the customer organization’s vision of a single component.
• Requirements Executive Summary, which is used to formally summarize the requirements for the customer.
• System Requirements Specification, which is used to formally specify the operational requirements, quality requirements, and design constraints.
• External API Specification, which is used to formally specify any external application programmer interfaces.
• Glossary, which is used to formally define the abbreviations, acronyms, 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 project glossary.

Phases

The component requirements engineering task are typically performed during individual phases as documented in the following table:

Guidelines

• This is an extremely important activity because a large percentage of projects fail due to poor quality requirements. This activity should not be deleted, and care should be taken to avoid tailoring out necessary and cost-effective components of this activity.
• This activity is documented using the typical configuration for large projects. It is intended to be configured (i.e., instantiated, extended, and tailored) to meet the needs of specific projects.
• The preconditions of this activity should be the union of the preconditions of its earliest constituent tasks.
• The completion criteria for this activity should be the union of the postconditions of its constituent tasks.
• The component requirements engineering activity inherits the common guidelines of the activity process component.