Project Synopsis

Identify the project purpose, scope, out of scope, expected project outcomes. These should be taken from the project definition or project charter.

1) Business requirements (high-level)

2) Functional requirements (detailed)

Business requirements are high level requirements that management and a board of directors would typically understand, as follows:

Requirement 1: "We need to establish an online customer portal."

Requirement 2: "The portal should list our products."

Functional requirements on the other hand are very detailed and outline exactly what needs to be delivered and would typically be read by business analysts, developers, project manager and testers:

Requirement 3: "The system shall be able to register a product using the following fields: Name (20 characters long), Details (2000 characters long), Price (currency), Category (pick list)."

Requirement 4: "The system shall support that up to 5 pictures can be listed per product."

So it means that a business requirement (“The portal should list our products”) will be broken in to one or more detailed functional requirements as shown above. In addition you would have a section with user stories that details the different uses of the system step-by-step e.g.

------

Use case 1: Login

1. Go to website

2. Click on login

3. Enter username and password

4. You are redirected to the start page.

------

In turn requirements should be linked to the user stories.

REQUIREMENTS FOR PROJECT NAME

DRAFT

Version xxx
Version Date – xxxxx,xx 20xx

Version Control

Version / Date / Author / Summary (include section or page number)

Consultation with Key Stakeholders

Project Team Role / Name
Product Owner
Manager, Systems
Subject Matter Experts
Stakeholders Involved in Consultation

Definition of Terms (If required)

Acronym/Term / Definition

Contents

Version Control

1Consultation with Key Stakeholders

2Definition of Terms (If required)

3Contents

4Introduction

4.1Document Purpose

4.2Objectives

4.3Intended Audience

4.4Scope of Work (This Document)

4.5Known Organizational Impacts

4.6Assumptions and Dependencies

5Business Requirements

5.1Summary

5.2Workflow Diagrams

6Functional Requirements

6.1User Role

7Business rules (not system WF rules)

8Non – Functional Requirements

8.1Audit

8.2Business Continuity

8.3Data Retention

8.4Documentation / Training

8.5Privacy

8.6Volume Impact

8.7Security

8.8Availability

8.9Hardware

8.10Software

8.11Reliability

8.12Scalability

8.13Performance

8.14Interface

8.15Infrastructure

9Appendices

10Approvals

Introduction

Document Purpose

The purpose of this document is to develop, at a detailed level, the business and system functional requirements.

Objectives

Intended Audience

This document is intended to be used by the development team. Since it defines the work to be completed by I+TS, it will be created in collaboration with the project team and key stakeholders. The document will be approved by the project sponsor, product owner and the I+TS manager responsible for delivering the product.

Scope of Work (This Document)

In scope

List of business elements out of scope

Out of scope

List of business elements in scope

Known Organizational Impacts

Assumptions and Dependencies

Business Requirements

Summary

Describe the high level end to end process

Roles

System Impact

User Stories

Workflow Diagrams

Functional Requirements

Describe the functional requirements by role for each step of the process and include sub-process diagrams and wireframes as required. Include business rules to be enforced, functions, search functionality, reporting and other functions.

Role 1 ..xx

Non – Functional Requirements

Non-functional requirements are any requirements outside the actual function or process being performed. Add

sections below as applicable based on the project.

Audit

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
AUD1 / Describe audit trails and related control procedures

Business Continuity

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
BCM1 / Describe Business Continuity and Disaster Recovery related requirements resulting from the Business Impact Analysis (contact Business Continuity representative for more details)

Data Retention

Please consult the Enterprise Records Retention Schedule in determining all data retention requirements; see here.

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
DRN1 / Describe the requirements for archiving and storage

Documentation / Training

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
DTR1 / E.g. a training tool may be required for the sales force.

Privacy

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
PRV1 / E.g. if we are passing client information to an outside vendor, the data will need to be encrypted

Volume Impact

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
VLM1 / E.g. expected volumes and requirements to manage impact on processing

Security

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
SEC1 / Describe any requirements as it relates to access, user roles and security.

Availability

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
AVL1 / E.g. expected to be available for clients to use 7 days a week

Hardware

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
HW1 / E.g. system must be able to operate on mobile sales force laptops

Software

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
SW1 / E.g. system requires MS Windows

Reliability

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
REL1 / E.g. expected Mean-Time-To-Failure

Scalability

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
SCL1 / E.g. if we will be starting with a small pilot, but plan to launch nationally, the volumes associated with a national launch should be considered during the design of the process

Performance

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
PRF1 / E.g. if a client calls us with a request, we must have fulfilled within 24 hours.

Interface

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
INT1 / E.g. ability to support access from multiple sources

Infrastructure

ID / Requirement / Priority
  • 1=high
  • 5=low
/ Stability
  • High
  • Med
  • Low
/ Origin / Benefit
INF1 / E.g. pre-established computing platforms or services already available or required

Appendices

Approvals

Specifications

I/we, the undersigned, have reviewed and approved the business specifications described above as representing our/my needs completely and fairly.

Approved by: / Signature: / Date:
Project Sponsor:
Product Owner:
I+TS Manager:

OR

These specifications do not meet our/my needs. Please provide reasons for rejection below.

Quality Assurance Testing

I/we, the undersigned, have tested the product and accept the results as accurately meeting the requirements defined in the approved business specifications. !/we approve the movement of the product to the EASI production environment.

Approved by: / Signature: / Date:

OR

We have tested the product and DO NOT accept the results as accurately meeting the requirements defined in the approved business specifications. Please provide reasons for rejection below.