Requirements Executive Summary

Definition

A requirements executive summary is the requirements work product produced during application development that formally summarizes the requirements of a single application for the customer organization’s management. Thus, it is typically produced when the purpose of an endeavor is to deliver either a new application or a new version of an existing application.

Objectives

The typical objectives of the requirements executive summary are to:

• Make the application’s system-level requirements easily understandable to the non-technical members of the executive management teams of the customer and developer organizations.
• Formally summarize these requirements including the:
  • Operational Requirements.
  • Informational Requirements.
  • Quality Requirements.
  • Architecture, design, and implementation constraints.
• Be an initial basis for:
  • Establishing the scope, size, and complexity of the application and related project(s).
  • Estimating cost, schedule, and progress.
  • Future extensions and enhancements.

Benefits

The typical benefits of a requirements executive summary include:

• Help establish a consensus among the application’s stakeholders concerning its system-level requirements.
• The results of requirements engineering are easy to comprehend and evaluate by executive management.
• The requirements executive summary also provides an easy introduction to the requirements for other stakeholders (e.g., to enable the architecture team, the independent test team, and others to plan and prepare to perform their tasks).
• It eliminates the need for executive management to wade through the numerous detailed formalized requirements that have to be specified in the system requirements specification to support the system and launch testing activities.

Contents

The typical contents of a requirements executive summary include:

• System Overview:
  • System Definition
  • Business Goal
  • Business Objectives
  • System Context
  • Summary of System Capabilities
• Operational Requirements:
  • Externals Types:
    • Externals:
      • Essential Use Cases
• Informational Requirements:
  • Data and Content Requirements
• Quality Requirements:
  • Developer-Oriented Quality Requirements
  • User-Oriented Quality Requirements
• Constraints:
  • Business Rules
  • Data Constraints
  • Hardware Constraints
  • Software Constraints
  • Industry Standards
  • Legal and Regulatory Constraints
• Envisioned Future Enhancements
• Appendices:
  • Major Issues
  • Major Items to be Determined
  • Assumptions

Stakeholders

The typical stakeholders of a requirements executive summary are:

• Producer:
  • Requirements Team
• Evaluators:
  • Requirements Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative(s)
• Maintainers:
  • Requirements Team (prior to delivery)
  • Maintenance Team (after delivery)
• Users:
  • Customer Organization, which uses it to understand the scope of the application to be delivered.
  • Architecture Team, which uses it to begin production of the system architectures.
  • User Experience Team, which uses it to begin production of the human interface prototype(s).
  • Independent Test Team, which uses it to begin preparation for system and launch testing.
  • Metrics Team, which uses the requirements in it to initially estimate the size and scope of the endeavor.
  • Endeavor Management Team, which uses it to begin managing endeavor scope and scheduling the endeavor activities.
  • Subcontractor Organizations, which use it to drive their initial work.

Phases

A requirements executive summary is typically produced during the following phases:

• Business Strategy: Not Applicable
• Business Optimization: Not Applicable
• Initiation: Started. During this phase, only the high risk and architecturally significant requirements are summarized.
• Construction: Completed
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

A requirements executive summary typically can be started if the following preconditions hold:

• The initiation phase has started.
• The requirements analysis task has started.
• The requirements team has been adequately staffed and trained in the requirements specification task.
• The following personnel are available to provide input to the requirements elicitation, reuse, and analysis tasks:
  • Application domain experts from industry and the development.
  • Customer Representatives.
  • Maintenance Team member.
  • Marketing Representatives.
  • Reuse Librarian.
  • User Support Agent.
  • Users.
• Initial versions of the following input diagrams, models, and documents are available.

Inputs

The typical inputs to a requirements executive summary include:

• Work Products:
  • Actor Cards
  • Application Vision Statement
  • Contract
  • Domain Model Document
  • Glossary
  • Human Interface Prototype
  • Statement Of Work
  • System Requirements Specification
  • Use Case Cards
• Stakeholders:
  • Customer organization domain experts
  • Developer organization domain experts
  • Users

Guidelines

• Do not create this summary document as a replacement for the more complete system requirements specification.
• This is a living document that is developed incrementally and iteratively in parallel with other requirements and architecting work products (e.g., system requirements specification, domain model document, and system architecture document).
• This summary can be created:
  • Prior to the system requirements specification and used to drive the development of the system requirements specification.
  • After the system requirements specification by summarizing the content of the existing system requirements specification.
  • Simultaneously with the system requirements specification, either manually or automatically by a requirements management tool from an associated repository of requirements.
• Ensure that this document remains consistent with the system requirements specification (e.g., by using a requirements management tool and automatically producing both documents from the associated requirements database).
• The contents of this document are very complete and thus intended for use for large, complex, business-critical or safety-critical applications. Inappropriate contents (e.g., any quality requirement types that do not apply) should be tailored out during the process construction task. However, do not tailor anything out unless proper due diligence has been performed to ensure that the material to be tailored out is truly not appropriate.
• Different parts of this document may be due at different times (i.e., by different milestones).
• Most parts of this document should be mandatory, but some parts may be optional.
• Not all requirements are summarized in this document; specifically, required APIs to external applications are specified in external API specification and use case path requirements are specified in the system requirements specification.
• Do not concentrate solely on the use cases of the operational requirements. The architecture is often influenced more by the quality requirements (e.g., internationalization, operational availability, performance, personalization, robustness, security, reliability, and robustness) than by any functional requirements.
• Note that data requirements refer to required input and output data of the application. It does not refer to required deliverable documentation, which is the meaning sometimes used by certain government agencies, such as United States Department of Defense Data Item Descriptions (DIDs), which contain content and format standards for required deliverable documentation.
• Note that there is no need for a separate:
  • “Software requirements specification,” because most system requirements must be met by a combination of collaborating data, hardware, and software components.
  • “Supplementary Requirements Specification,” because the informational and quality requirements as well as any architecture, design, or implementation constraints are just as important as the operational requirements.
• Reuse use cases by using a combination of:
  • The major functions listed in the application vision statement.
  • A standard mapping from functions to use cases.
  • Reusable requirements based on functional areas (e.g., Content Management).

Conventions

A requirements executive summary is typically constrained by the following conventions:

• Content and Format Standard
• Template
• XML DTD
• Inspection Checklist

Examples

• Electronic Auction and Sales (EAS) System Requirements Executive Summary