Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
Executive Summary.....................................................................................................................14
Ve
Date Description
r
Approvals
Executive Summary
[Optional
This section is intended to capture a one-page high-level overview of the document.]
Section 1 Introduction
1.1 Background
1.2 Purpose
1.3 Scope
2.2 Approach
2.3 Stakeholders
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
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.3.2 Preconditions
4.3.3 Triggers
[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.]
[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.]
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
Appendix B. Glossary
[The glossary is optional for this document since the Business Vocabulary Section 2.8
may suffice.]
Term Definition
[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
Executive Summary
[Optional
This section is intended to capture a one-page high-level overview of the document.]