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 / NameProduct Owner
Manager, Systems
Subject Matter Experts
Stakeholders Involved in Consultation
Definition of Terms (If required)
Acronym/Term / DefinitionContents
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
- High
- Med
- Low
AUD1 / Describe audit trails and related control procedures
Business Continuity
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
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
- High
- Med
- Low
DRN1 / Describe the requirements for archiving and storage
Documentation / Training
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
DTR1 / E.g. a training tool may be required for the sales force.
Privacy
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
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
- High
- Med
- Low
VLM1 / E.g. expected volumes and requirements to manage impact on processing
Security
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
SEC1 / Describe any requirements as it relates to access, user roles and security.
Availability
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
AVL1 / E.g. expected to be available for clients to use 7 days a week
Hardware
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
HW1 / E.g. system must be able to operate on mobile sales force laptops
Software
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
SW1 / E.g. system requires MS Windows
Reliability
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
REL1 / E.g. expected Mean-Time-To-Failure
Scalability
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
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
- High
- Med
- Low
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
- High
- Med
- Low
INT1 / E.g. ability to support access from multiple sources
Infrastructure
ID / Requirement / Priority- 1=high
- 5=low
- High
- Med
- Low
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.