Short Requirements Document Introduction

Requirements Document
Table of Contents
Document Version Control............................................................................................................3
Section 1 Introduction.....................................................................................................................4
1.1 Background...........................................................................................................................4
1.2 Purpose..................................................................................................................................4
1.3 Scope.....................................................................................................................................4
1.4 Acceptance Criteria Factors..................................................................................................4
Section 2 Initiative Overview.........................................................................................................5
2.1 Problem Statement................................................................................................................5
2.2 Approach...............................................................................................................................5
2.3 Stakeholders..........................................................................................................................5
Section 3 Business Scenarios..........................................................................................................6
Section 4 Use Case Model..............................................................................................................8
4.1 Actors....................................................................................................................................8
4.2 Use Case Diagram................................................................................................................8
4.3 Use Case Outline..................................................................................................................8
4.3.1 Actors.............................................................................................................................8
4.3.2 Preconditions..................................................................................................................8
4.3.3 Triggers..........................................................................................................................8
4.3.4 Basic Flow.....................................................................................................................8
4.3.5 Post Conditions..............................................................................................................8
Section 5 Business Requirements...................................................................................................9
5.1 Functional Requirements......................................................................................................9
Section 6 Business Information Model.........................................................................................10
6.1 Subject Areas......................................................................................................................10
6.2 Data Dictionary...................................................................................................................10
Appendix A. Acronyms and Abbreviations..................................................................................11
Appendix B. Glossary...................................................................................................................12
Appendix C. Key Decisions Log..................................................................................................13
C.1. Key Decision: [Key Decision Name]................................................................................13

Version 1.2 -1- 9/17/2009

Short Requirements Document Introduction

Executive Summary.....................................................................................................................14

Version 1.2 -2- 9/17/2009

Short Requirements Document Introduction

Document Version Control

Ve
Date Description
r

1.0 12/21/10 Initial Requirements Document

Approvals

Name Title Date

Executive Summary
[Optional
This section is intended to capture a one-page high-level overview of the document.]

Version 1.2 -3- 9/17/2009

Short Requirements Document Introduction

Section 1 Introduction

1.1 Background

1.2 Purpose

1.3 Scope

1.4 Acceptance Criteria Factors

Version 1.2 -4- 9/17/2009

Short Requirements Document Introduction

Section 2 Initiative Overview

2.1 Problem Statement

2.2 Approach

2.3 Stakeholders

Version 1.2 -5- 9/17/2009

Short Requirements Document Introduction

Section 3 Business Scenarios

Typically, this section is intended to capture the key business scenarios, as-is business processes,
to-be business processes and the resulting business process changes.
1) Breadth (scope – high level business processes - Level 0 & 1)
• Level 0 – Definition of Enterprise Business Process Areas (i.e., lines of business)
• Level 1 – Definition of Business Processes
2) Depth (sub-processes – Level 2, Level 3, and Levels 4-6, if needed)
• Level 2 – Definition of Sub-Processes
• Level 3 – Definition of Activities / Actions
• Level 4 – Definition of Tasks / Work Steps
• Level 5-6 – Further detailed process definition as required
For process definition at level 4 and further, detail is expected to be documented through
detailed (system) use cases, which are captured in the Detailed Requirements Document.
Process Flows are an effective means of communicating how work is performed in a time-based,
cross-functional representation of the “business logic”.
The purpose for defining the business processes and scenarios is to:
• Identify the business operations that will occur within the scope of the effort
• Provide a basis for identifying problem areas within the existing processes
• Define how business operations should occur to achieve desired capabilities and value
capture outlined by the client
• Illustrate desired interaction and outcomes when performing future business processes
• Link roles to the business situations for understanding and acceptance of future business
processes and business process enablers
• Communicate and obtain buy-in to the future process design (whether it is business
processes, IT processes, or management system processes, etc.)
• Support documentation of requirements related to the future organization and business
processes
• Provide a common communication vehicle for the users, management, consultants, and
technology implementation teams of the project
• Enable issues to be resolved early and risks to be mitigated
• Provide awareness of assumptions that have been made
• Provide the blueprint that can be a base for testing, training and procedures
development

Version 1.2 -6- 9/17/2009

Short Requirements Document Introduction

Version 1.2 -7- 9/17/2009

Short Requirements Document Introduction

Section 4 Use Case Model

Refer to the Exemplar High Level Requirements Document for an example of how to complete
this section.
Defining process definition at level 4 and further is often done using detailed (system) use cases,
which are captured in the Detailed Requirements Document. Use Cases are identified by
analyzing the business process scenarios and business requirements, so as to define the behavior
of the entire system from the actors’ perspectives. The Use Case Model in the High Level
Requirements Document should include a list of actors, and use case diagram, an outline for
each use case defined in the use case diagram. Each use case outline should consist primarily of
a description of the use case, actors and high-level basic flow steps. Each use case will be
further detailed with additional information, such as alternate flows and exception flows, in the
Detailed Requirements Document.
Use cases describe the interaction between a primary actor (the initiator of the use case) and the
system itself, represented as a sequence of simple stepsThe main purpose of use case modeling is
to establish the boundary of the proposed software system and fully state its functional
capabilities to be delivered to the users.]

4.1 Actors

4.2 Use Case Diagram

Table 4-1: Use Case Inventory

Use Case
Use Case Actor Description
Number

4.3 Use Case Outline

4.3.1 Actors

4.3.2 Preconditions

4.3.3 Triggers

4.3.4 Basic Flow

4.3.5 Post Conditions

Version 1.2 -8- 9/17/2009

Short Requirements Document Introduction

Section 5 Business Requirements

[The business requirements section captures functional and supplemental requirements as well
as business constraints. The functional requirements identify the high level capabilities of the
system, decomposed from the business processes and business wants and needs.]

Table 5-2: Business Requirements

Priority
Business Req (E)ssential
Source Requirement Definition
ID (C)onditional
(O)ptional

5.1 Functional Requirements

Things that are normally of interest to the business include data (screens and reports), usability
screen or report design or fitness for use, processes, integrations to other business units, etc. In
addition to being unambiguous, testable/verifiable, concise and complete, business requirement
typically consist of the following:
• Statements that specify the features or capabilities that a user must have to support the
business objectives and requirements
• Business Functional and Non-Functional Requirements specify the “What’s”:
o What is expected to be done? To what level?
o What inputs should be processed to produce what outputs (but not the How's)
o What operations are required
o What capacity, quantity, throughput, speed of response
• States whether user or operational needs are automated or manual
• Technology/Application independent
System requirements (functional and supplemental) are documented after the business
requirements (in the Detailed Requirements Document), and define requirements from the
perspective of what the system shall do. Table 5-3 represents an example of a table which may
be used to capture business functional requirements.]

Table 5-3: Business Functional Requirements

Business Priority
Functional Source Requirement Definition (E)ssential
(C)onditional
Req ID (O)ptional

Version 1.2 -9- 9/17/2009

Short Requirements Document Introduction

Section 6 Business Information Model

[This section is required. This section of the document provides a Business Information Model
for the initiative. Refer to the Exemplar High Level Requirements Document for an example of
how to complete this section. The Business Information Model includes the information/data
elements used by the business that have been captured as part of the requirements definition
process. Any existing Business Information Model may also be used to capture information
model attributes specific to the project. The Business Information Model depicts, in both
graphical and textual form, the structure and content of the key categories, or "subject areas" of
persistent data that needs to be managed by the initiative. The Business Information Model is
typically at a conceptual level and is limited to depicting the key entities and their relationships.
This model forms the basis for the logical data model defined in future stages of the project.

The Business Information Model captured here has many similarities to a "logical data model".
Both are interested in identifying the information/data that the business manages and both may
use a similar graphical notation accompanied with text to represent this. The Enterprise
Information Model, however, will be at a significantly higher level of abstraction and is more
concerned with gaining an understanding of the scope and scale of the information that is
managed by the initiative. Rather than defining the detailed specifics of any one-subject area,
the Business Information Model is more focused on knowing that a class of information exists
and that it is important.]

6.1 Subject Areas

[This section is intended to capture any diagram and supporting text defining the Business
Information Model.]

6.2 Data Dictionary

[This section is intended to provide a useful definition of and any entities captured in the defined
subject areas.]

Version 1.2 - 10 - 9/17/2009

Short Requirements Document Introduction

Appendix A. Acronyms and Abbreviations

Definition of acronyms and abbreviations used in this and related Federal Student Aid
documents.
[All acronyms and abbreviations used in this document are to be defined in the table
below]

Acronym Definition

Version 1.2 - 11 - 9/17/2009

Short Requirements Document Introduction

Appendix B. Glossary

[The glossary is optional for this document since the Business Vocabulary Section 2.8
may suffice.]

Term Definition

Version 1.2 - 12 - 9/17/2009

Short Requirements Document Introduction

Appendix C. Key Decisions Log

[This section is required. Refer to the Exemplar High Level Requirements Document for
completed Key Decisions examples.
Key Decisions are usually made in the course of detailing requirements. The purpose of
a key decision record is to help make the decision (by defining the issue, decision owner,
possible solutions and evaluation criteria) as well as provide a permanent record of the
key decision process and outcome. Key decisions are most commonly documented and
communicated when a decision made within the project has impacts across teams,
systems or efforts outside of the project, when the decision is likely to have a significant
impact on the scope, schedule, cost or quality of the project, or when the matter is
associated with a risk rating of medium or high. The table below may be used as a format
for capturing key decisions.]
C.1. Key Decision: [Key Decision Name]
Key Area Decision Detail
Issue Description

Decision

Business /
Decision Owner

Date

Key Decision
Author

Full Description of
Issue

Evaluation Criteria

Alternative
solutions and
evaluation results

6.3

Version 1.2 - 13 - 9/17/2009

Short Requirements Document Introduction

Executive Summary

[Optional
This section is intended to capture a one-page high-level overview of the document.]

Version 1.2 - 14 - 9/17/2009