Domain Requirements Engineering

Definition

Domain Requirements Engineering

the requirements engineering subactivity during which the reusable requirements for an application domain are engineered

Goals

The typical goals of Domain Requirements Engineering are to:

• Produce and maintain a complete set of high-quality requirements for an application domain:
  • 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 domain requirements engineering are to:

• Produce a formally documented consensus amoung all project stakeholdlers (e.g., client, users, project champions, project management, developers) concerning either the:
  • Requirements for the domain.
  • Scope of the domain.
  • Boundaries of the domain.
• 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 teams (e.g., reuse of requirements, reuse of conventions, and existence of examples).

Preconditions

The domain 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 domain requirements engineering task is typically complete when the following conditions hold:

• The reusable requirements for the application domain 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 domain 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:
  • 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 domain 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 domain 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.
• 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 domain requirements engineering task are typically performed during individual phases as documented in the following table:

Guidelines

• 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 domain requirements engineering activity inherits the common guidelines of the activity method component.