Requirements Engineering

Definition

Requirements Engineering

the activity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other related requirements work products for an endeavor

Classification

As illustrated in the preceding figure, Requirements Engineering is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Activity
• Subclasses:
  • Business Requirements Engineering
  • Product Line Requirements Engineering
  • System Requirements Engineering
  • Application Requirements Engineering
  • Component Requirements Engineering
  • Center Requirements Engineering
  • Domain Requirements Engineering

Responsibilities

The typical responsibilities of Requirements Engineering are to:

• Develop a strategic vision of the scope of the effort:
  • Business Enterprise.
  • Product line of systems or applications
  • Individual:
    • System
    • Software application
  • Component:
    • Data Component
    • Hardware Component
    • Software Component
  • Center:
    • Contact Center
    • Data Center
    • Reuse Center
• Given the preceding scope of the effort, determine what:
  • It must do
  • It must know.
  • Qualities it must have.
  • Interfaces it must have to external systems.
  • Constraints it must conform to.
• Transform potentially vague and conflicting stakeholder needs and desires into a complete set of high-quality requirements:
  • Functional Requirements
  • Data Requirements
  • Quality Requirements
  • Interface Requirements
  • Constraints
• Produce requirements work products that are needed as inputs by other teams on the endeavor (e.g., the architecture and independent testing teams).
• Thereby help ensure that all endeavor effort is based on the implementation of properly approved requirements.
• Minimize the risk of endeavor failure due to poorly engineered requirements work products.
• Reduce endeavor costs.
• Improve the quality of all endeavor deliverable work products.
• Increase customer and user satisfaction.
• For the [re]engineered business enterprise, the next version [incremental iteration] of the application, the component to be engineered, or the center to be developed, produce a formally documented consensus among all endeavor stakeholders (e.g., customer representatives, users, endeavor champions, endeavor management, developers) concerning its:
  • Vision.
  • Requirements.
  • Scope.
  • Boundaries.
• 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 and other requirements work products (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

Requirements engineering may typically begin when the following preconditions hold:

• Business Engineering:
  • The business strategy phase is started.
  • The business strategy team is initially staffed and adequately trained in requirements engineering.
• System, Application, or Component Development:
  • The initiation phase is started.
  • The requirements team is initially staffed and adequately trained in requirements engineering.

Completion Criteria

Requirements engineering is typically complete when the following postconditions hold:

• The needs of the business or stakeholders of the system, application, or component have been analyzed.
• The associated vision has been documented.
• The associated requirements have been 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

Requirement Engineering Tasks

Requirements engineering on a specific endeavor typically consists of the appropriate subset of the following requirements engineering tasks (and subtasks), which are typically performed in an iterative, incremental, parallel, and time-boxed manner:

• Business Analysis:
  • Customer Analysis
  • Competitor Analysis
  • Market Analysis
  • Technology Analysis
  • User Analysis
  • Stakeholder Profiling
  • Stakeholder Goals Identification
  • Business Case Development
• Visioning:
  • Business Visioning
  • Application Visioning
  • Component Visioning
• Requirements Identification
• Requirements Reuse
• Requirements Analysis
• Requirements Prototyping
• Requirements Specification
• Requirements Management
• Requirements Validation

The following diagram illustrates the typical workflow of the requirements engineering tasks on an application development project if iteration is ignored:

The following diagram illustrates one way in which the requirements tasks, the producers (e.g., requirements team, stakeholders, and requirements tools) that perform them, and the associated repositories might be related on a project:

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

• Business Strategy Team, which performs:
  • Business Visioning
  • Customer Analysis
  • Competitor Analysis
  • Market Analysis
  • User Analysis
  • Stakeholder Profiling
  • Stakeholder Goals Identification
  • Business Case Development
  • Requirements Reuse
  • Requirements Identification
  • Requirements Prototyping
  • Requirements Analysis
  • Requirements Specification
  • Requirements Management
  • Requirements Validation
• Technology Strategy Team, which performs:
  • Technology Analysis
  • Requirements Reuse
  • Requirements Prototyping
  • Requirements Management
  • Requirements Validation
• Requirements Team, which performs:
  • Application Visioning
  • Component Visioning
  • Stakeholder Profiling
  • Stakeholder Goals Identification
  • Requirements Reuse
  • Requirements Identification
  • Requirements Prototyping
  • Requirements Analysis
  • Requirements Specification
  • Requirements Management
  • Requirements Validation
• Architecture Team, which collaborates with the requirements team to perform the part of:
  • Requirements Analysis, by involving prioritizing the requirements from the standpoints of implementability and technical feasability.
• Customer Management Team, which collaborates with the requirements team to perform the part of:
  • Requirements Analysis, by involving prioritizing the requirements from the standpoints of their business and marketing needs.
• Endeavor Management Team, which collaborates with the requirements team to perform the part of:
  • Requirements Analysis, by involving prioritizing the requirements from the standpoint of the development organization).

Related Tasks Allocated To Other Activities

Because the following tasks fit better under other activities, they are not techically part of the requirements engineering activity, although they nevertheless have a major impact on requirements engineering:

• Scope Management,
  which is a task of the management activity that manages major requirements changes that change the scope of the endeavor.
• Configuration Control,
  which is a task of the configuration management activity that manages changes to baselined requirements (and other) work products.
• Quality Control,
  which is a task of the quality engineering activity that controls the quality of requirements (and other) work products (e.g., via the requirements evaluation task).

Environments

Requirements Engineering is typically performed using the following environment(s) and associated tools:

• Development Environment:
  • White boards for Requirements Identification
  • Reuse repositories for Requirements Reuse
  • Business Process Reengineering Tools for Business Requirements Engineering
  • Upper CASE Tools for Requirements Analysis
  • Documentation Tools for Requirements Specification
  • Requirements Tools for Requirements Management

Work Products

Requirements Engineering typically results in the production of the following work products from the requirements work product set:

• Business Engineering:
  • Actor Cards, which are large index card used during the requirements elicitation task to informally document a single actor of the customer organization.
  • Use Case Cards, which are large index card used during the requirements elicitation task to informally capture the cohesive set of operational requirements associated with a single use case of the customer organization’s business enterprise.
  • Customer Stakeholder Profile, which documents the various kinds of stakeholders in the customer organization’s business enterprise.
  • Customer Analysis, which documents the results of the analysis of the customer organization’s current business enterprise.
  • Competitor Profile, which documents an individual competitor of the customer organization.
  • Market Analysis, which documents the market in which the customer organization’s applications must compete.
  • Technology Analysis, which documents the results of the analysis of technology trends that will impact the customer organization’s applications.
  • Stakeholder Goals List, which documents the stakeholder goals (desires, needs, and expectations).
  • User Profile, which documents an individual type of user or user organization.
  • User-Task Matrix, which is a matrix that documents the tasks that users perform.
  • User Analysis, which documents the results of the analysis of the user organizations of the customer organization’s business enterprise.
  • Business Case, which documents the business case for a potential business enterprise, application, component, or center.
  • Business Vision Statement, which documents the customer organization’s vision of its business enterprise.
  • Glossary, which is used to formally define the abbreviations, accronyms, and terms that are used within the business enterprise.
• Application or Component Development:
  • Actor Cards, which are large index card used during the requirements elicitation 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 Prototype, which is a prototype used to help elicit requirements.
  • Requirements, which specify the mandatory behaviors, characteristics, interfaces, and constraints of something.
  • Application Vision Statement, which documents the customer organization’s vision of a single application.
  • Component Vision Statement, which documents the customer organization’s vision of a single reusable 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 functional 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

Requirements engineering tasks are typically performed during individual phases as documented in the following table:

Guidelines

• The scope of the requirements could be a:
  • Business Enterprise.
  • Product line of applications (system or software).
  • Single application (system or software).
  • Reusable Component:
    • Data Component.
    • Hardware Component.
    • Software Component.
  • Center:
    • Contact Center.
    • Data Center.
• Having a solid requirements engineering process is extremely important because:
  • Approximately 37% of defects originate during requirements engineering.
  • Requirements defects that are not discovered until after delivery cost approximately 200 times as much to fix than if they were found during requirements engineering.
  • Requirements defects account for some 70% of rework costs.
  • Requirements defects consume from 25% to 40% of the total project budget.
  • Of those projects that fail (i.e., significantly over budget, significantly late, significantly lowered functionality, cancelled, application never placed into production), a large percentage do so because of poorly performed requirements engineering and the resulting poor quality of the requirements.
• This activity should not be deleted, and care should be taken to avoid tailoring out necessary and cost-effective components of this activity.
• Requirements engineering is important regardless of the type of endeavor:
  • Building custom applications or components.
  • Building applications by integrating components.
  • Buying commercial-off-the-shelf (COTS) applications or components.
  • Making major enhancements to existing applications or components.
• The following diagram illustrates the relationships between requirements engineering and its associated work products and the other activities. As you can see, requirements engineering and its work products have a major influence on almost all other activities.

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