Business Requirements Engineering

Definition

Business requirements engineering is an requirements engineering subactivity consisting of the cohesive collection of all tasks that are primarily performed to produce the requirements and other requirements work products for the customer organization’s business enterprise.

Thus, business 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 Visioning
• Business Analysis
• :
  • Stakeholder Profiling
  • Customer Analysis
  • Competitor Analysis
  • Market Analysis
  • Technology Analysis
  • User Analysis
  • Business Case Development
• Requirements Identification
• Requirements Analysis
• Requirements Prototyping
• Requirements Specification
• Requirements Reuse
• Requirements Management

Goals

The typical goals of the business requirements engineering subactivity are to:

• Develop the business case for the future [version of the] business enterprise to be [re]engineered.
• Develop a strategic vision of the future [version of the] business enterprise to be [re]engineered.
• 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
  • External API 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.

Objectives

To achieve the above goals, the typical objectives of the business requirements engineering subactivity are to:

• Produce a formally documented consensus among all endeavor stakeholders (e.g., customer representatives, users, endeavor champions, endeavor management, and developers) concerning the [re]engineered business enterprise’s:
  • 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).

Examples

Typical examples of the business requirements engineering subactivity include the requirements engineering of a:

• Corporation.
• Profit and Loss (P&L) Center of a corporation.
• Business Unit.

Preconditions

The business requirements engineering subactivity typically may begin when the following preconditions hold:

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

Completion Criteria

The business requirements engineering subactivity is typically complete when the following conditions hold:

• The needs of the business have been analyzed.
• The associated business vision has been documented.
• The associated business requirements have been specified.
• The associated deliverable work products in the requirements work product set have:
  • Passed evaluation (e.g., passed inspection by the strategy inspection team).
  • Been accepted by the customer representative.
  • Been delivered to the customer organization.

Tasks

Business Requirement Engineering Tasks

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

• Business Strategy Team, which performs:
  • Stakeholder Profiling
  • Customer Analysis
  • Competitor Analysis
  • Market Analysis
  • User Analysis
  • Business Case Development
  • Business Visioning
  • Requirements Reuse
  • Requirements Identification
  • Requirements Prototyping
  • Requirements Analysis
  • Requirements Specification
  • Requirements Management
• Technology Strategy Team, which performs:
  • Technology Analysis
  • Requirements Reuse
  • Requirements Prototyping
  • Requirements Management
• Customer Management Team, which collaborates with the requirements team to perform the part of the:
  • Requirements Analysis task 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 the:
  • Requirements Analysis task 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 business requirements engineering subactivity, 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

The business requirements engineering subactivity 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 Visioning
  • Upper CASE Tools for Requirements Analysis
  • Documentation Tools for Requirements Specification
  • Requirements Tools for Requirements Management

Work Products

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

• Business Vision Statement, which documents the customer organization’s vision of its business enterprise.
• Actor Card, which a large index card used during the requirements identification task to informally document a single actor of the customer organization.
• Use Case Card, which a 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 customer organizationorganization’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.
• 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 customer organization’s user organizations.
• 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 used a business.

Phases

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

Guidelines

• 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.