Application Requirements Engineering

Definition

Application requirements engineering is a requirements engineering subactivity during which the requirements for an application are engineered.

The following diagram captures important information about the application requirements engineering activity. It shows that application requirements engineering is one of the three subtypes of the requirements engineering activity that are performed by the requirements engineering team (stick figure). It also documents the component tasks that are parts of application requirements engineering and the associated requirements work products (rectangles) that these tasks produce, elicit, manage, reuse, etc. It also documents the important relationships among these process components. Inheritance relationships are documented with double-line arrows to signify the high coupling between subtypes and supertypes. The more common referential relationships are signified with single-line arrows. Aggregation relationships are special referential relationships identified by a plus sign in a circle, signifying the whole is the sum of its parts.

Goals

The typical goals of the application requirements engineering task are to:

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

• Produce a formally documented consensus amoung all project stakeholdlers (e.g., client, users, project champions, project management, developers) concerning the:
  • Vision of the next version [incremental iteration] of the application.
  • Requirements for the application.
  • Scope of the application.
  • Boundaries of the application.
• 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 application 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 application requirements engineering task is typically complete when the following conditions hold:

• The customer’s vision for the application has been documented.
• The customer and user requirements for the application 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 application 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:
  • Application 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 application 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 application 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.
• 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 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 application 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 application requirements engineering activity inherits the common guidelines of the activity process component.