Seilevel Requirements Template

[Project Title]
Requirements Document
Original Date: / 8/21/2012 / Document Version / 0.1
Last Revision Date: / 8/21/2012
Author Information
Author: / Jane Doe
Title: / Senior Business Analyst
E-mail: /
Phone: / 512-123-4567

Table of Contents

1Document Revision History

2Approvers & Reviewers

3Introduction

4Assumptions

5Constraints

6Project Stakeholders

7Project Overview

7.1Business Objectives Model

7.2Feature Tree

7.3High-Level L1 Process Flow

8High-Level Product Definition

8.1Process Flows

8.2Feature Tree

8.3Objective Chains

8.3.1Objective Chain 1

8.4Ecosystem Map

8.5Interface Descriptions

8.6Business Data Diagram

9Requirements

9.1Feature 1

9.1.1Feature 1 Models

9.1.2Feature 1 Dependencies

9.1.3Feature 1 Requirements

10Non-Functional Requirements

11UI Design

11.1UI Flows

11.2Screen 1

11.2.1Screen 1 Screen Shots

11.2.2Screen 1 DAR Models

Appendix A – Glossary

1Document Revision History

Capture information about every published version in the table below, including a brief description of the changes in each version.

Date / Version / Section/Page / Update Description / Contact Name
12/1/2011 / 0.1 / All / Initial Draft / Jane Doe

2Approvers & Reviewers

The table below represents a list of all people that are required to review and approve the requirements document.

Name / Role / Responsibility / Approval Date
Jane Doe / Approver / [Insert Description]

3Introduction

The purpose of this document is to provide a template that can be used for any requirements deliverables. Most organizations have separate deliverables for different types of requirements or project stages; the various modules within this document can be used to build those deliverables.

The table below indicates which sections likely should be included in various document types; “Y” means it should be included, “No” means don’t include, and “M” means you may include it if relevant:

Chapter / Marketing Requirements Document (MRD) / Business Requirements Document (BRD) / Software Requirements Specification (SRS)
1 – Revision History / Y / Y / Y
2 – Approvals / Y / Y / Y
3 – Introduction / Y / Y / Y
4 – Assumptions / Y / Y / Y
5 – Constraints / Y / Y / Y
6 – Stakeholders / Y / Y / Y
7 – Project Overview / Y / Y / M
8 – Product Definition / M / M / N
9 – Requirements / N / Y / Y
10 – Non-Functional Req / N / Y / Y
11 – UI Design / N / N / Y
Appendix A – Glossary / Y / Y / Y

This section should include text describing the purpose of the document.

4Assumptions

This section contains the assumptions for a project. An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge.

ID / Assumption / Assumption Owner / Impact if not True

5Constraints

This section contains constraints on the project. A constraint is a restriction that is imposed on the choices available to the developer for the design and construction of a product.

ID / Constraint / Constraint Owner

6Project Stakeholders

This section should contain org charts around various groups of stakeholders surrounding the project. Stakeholders include business stakeholders, product management, IT, and test. The org chart should include individuals involved in elicitation, review, development, and testing. It is also a good idea to identify those business stakeholders involved in UAT within these org charts.

Additional org charts and other models should be created to describe the various users of the product.

7Project Overview

The Project Overview section is intended to describe the goals and objectives of the entire project, as well as to introduce the different product concept. The section should identify the business problems, business objectives, success metrics, and product concepts associated with the project.

7.1Business Objectives Model

This section will contain the Business Objectives Models and/or Key Performance Indicator Model. The purpose of the Business Objectives Model is to illustrate the Business Problems and Business Objectives of a project in a manner that can be easily consumed to understand the purpose of the project.

7.2Feature Tree

A feature tree can be provided in the Project Concept discussion in order to provide additional information around the types of features that are associated with the project. These features are typically high-level at this stage.

7.3High-Level L1 Process Flow

This section should contain a high-level L1 process flow which describes the project at a very high level so that the consumer of the document has a little context around the project.

Sometimes, this L1 is written such that each of the steps will become a Product Concept. In other cases, each Product Concept is a variation of this L1 that represents a different user scenario.

8High-Level Product Definition

These sections service to continue on detail from the Project Overview sections, drilling down in detail per each feature discussed in the project overview. These inform the requirements in Section 9.

8.1Process Flows

This section should contain a Process Flow or User Story that describes the grouping of functionality.

8.2Feature Tree

This section contains a Feature Tree of the features (capabilities) associated with the process flow. There should be an indication of the features that are already developed versus new features. There should also be an indication of which step in the Scenario each feature is associated with.

8.3Objective Chains

This section will contain all of the Objective Chains for all Business Objectives associated with the features.

The intent of the Objective Chain is to identify the business value associated with each feature of the Product Concept as well as the Product Concept as a whole.

8.3.1Objective Chain 1

This section contains an Objective Chain.

8.4Ecosystem Map

This section contains an L1 Ecosystem Map for the Scenario based on the interfaces discovered.

8.5Interface Descriptions

This section contains a description of the interfaces as well as an indication of the feature they are associated with.

Feature Name / Interface Name / Interface Description / Interface Contact

8.6Business Data Diagram

This section contains an L1 BDD for the Scenario. This section is optional; a BDD may not be available or necessary at this stage in the process.

9Requirements

This section should contain additional context around the various features of a project, as well as the Business Requirements for a project. It is important to remember that a Feature is implementation agnostic. Implementation details should be captured in the Technical Design section.

9.1Feature 1

This section contains the entire context around a feature.

9.1.1Feature 1 Models

The detailed models associated with a feature should be located here. Those models could include L3 process flows.

9.1.2Feature 1 Dependencies

This section should list all of the dependencies a particular feature has on other features or other projects.

9.1.3Feature 1 Requirements

These requirements should be presented in a RMM. Acceptance Criteria and the Business Rules should be captured.

10Non-Functional Requirements

This section will contain all non-functional requirements. Usually, non-functional requirements are established for the project as a whole, and not an individual feature. If the non-functional requirements are defined on a feature bases, they can be moved to the previous section. Types of Non-Functional Requirements to consider:

Availability- Desired “up time” during which the system and data are available for use. [The system shall be available between the hours of 6AM and 10PM ship time, inclusive, every day of the week.]
Documentation- Descriptions of any expected supplemental information, including its purpose, desired contents, level of detail, and formatting. [The system shall provide context sensitive help that takes the user to a help topic specific to the screen in focus which describes how to use each control and data field on the screen.]
Emotional- Describe the user’s feelings about the experience with the system, including where and when the emotions should be felt, and how they vary over time. [The system shall elicit a fun feeling for the passenger when they view the physical outputs from the system.]
Flexibility - How much effort is needed to add or change capabilities within the product. [The system shall allow for the addition of new fields of interest with no more than 2 hours of effort.]
Hardware Interfaces - Characteristics of each interface between the software system and the hardware components supported by the system. [The system shall be able to upload digital photographs directly from a digital camera to attach to the passenger profile.]
Legal- System constraints that are required by law. [The system shall not display any information the passenger marked as confidential on the passenger profile.]
Logical Databases - Any information that is required to be placed into a database, including data relationships, field types, frequency of use, integrity constraints and accessing capabilities. [The system shall maintain a history of passenger suggestions.]
Memory Constraints- Constraints on the system based on memory usage. [The client shall run on a system with 500 KB of memory, utilizing no more than 30% of the available system memory resources at anytime.]
Operations- System behaviors necessary for the support and operations of the system. [The system shall notify the administrator users by email and pager if the database server becomes unavailable.]
Performance- The speed with which the system accomplishes specific actions under specified conditions. [The system shall regenerate and display one passenger’s updated suggestions within 5 seconds of receiving the update request.]
Portability- Ability to migrate from one platform to another or one machine to another. [The system shall be designed such that the client runs in Windows XP now and in Windows Vista without code changes when the cruise ship upgrades its systems.]
Reliability - Specified period of time and conditions for which the software must execute without a failure. [The system shall operate without critical failure for a consecutive 72 hour period with 20 users simultaneously performing their common tasks. (See test plan for definitions of “critical failure” and “common tasks.”)]
Reusability - How easily a component of the system can be used by another system. [The system’s components to update the passenger profile shall be usable in the next release of the Passenger Tracking system.]
Robustness - Expected behavior when there is invalid data, defects, or unexpected errors. [The system shall inform the user of the issue and allow the user to continue working offline if the primary database server becomes unavailable.]
Security - Behaviors necessary to protect the software from accidental or malicious access, use, modification, destruction, or disclosure. [The system shall store all passwords using 128 bit encryption.]
Site Adaptation - Behaviors necessary to support customization of the product specific to where it will be installed or used, including details of the customizations, globalization, and localization. [The system shall display all time stamps in the cruise ship’s local time.]
Software Interfaces - Characteristics of each interface between the software system and other software components of the system or other systems. [The system shall support using the Event Schedule system’s data to match passenger interests to available programs.]
Testability - Behaviors of the system necessary to support testing the system. [All user interface components must react to scripted input from the testing tool exactly as if the user input the scripted data or command.]
Usability - Defines the ease with which end user classes can perform specific tasks with the software. [The user interface shall allow users to regenerate the passenger suggestions from within two clicks after updating their profile information.]

11UI Design

Often, a separate design team is used to product the official screen shots or mockups for a product. Those design teams rely on business requirements in order to produce their deliverables. The UI requirements therefore often need to be presented in separate documentation, but can be captured here instead.

11.1UI Flows

The UI Flows are used to document how the screens flow from a user perspective.

11.2Screen 1

This section contains the screen shots and DAR models for a particular screen.

11.2.1Screen 1 Screen Shots

This section contains the shots for a particular screen.

11.2.2Screen 1 DAR Models

This section contains the DAR models for a particular screen. DAR models can often be presented better in a power point; in that case, link to the models from this location.

Appendix A– Glossary

The key business terms and their definitions that are used in this document are documented here.

Term / Definition
[Project Title] / Page 1 of 19