Requirements of Project
Status: Draft
Version: 0.1
Prepared by:
Date Created:
05 Oktober 2015
Date Last Revised:
BSA IT Department
Internal Use Only
Page 1 of 9
DOCUMENT REVISION HISTORY
GLOSSARY OF TERMS
DOCUMENT INFORMATION
PROJECT INFORMATION - OPTIONAL
PROJECT SCOPE - OPTIONAL
SYSTEMS & INTERFACES
AS IS ENVIRONMENT
CURRENT PROCESS FLOW
TO-BE ENVIRONMENT DETAILS
TO-BE ENVIRONMENT FLOW
GAP ANALYSIS
OTHER CONCERNS/ELEMENTS
USER SUMMARY - OPTIONAL
BUSINESS REQUIREMENTS APPROVALS
SYSTEM OVERVIEW
REQUIREMENTS CATALOG & DASHBOARD
OTHER ATTACHMENTS
REQUIREMENTS DESCRIPTORS
FUNCTIONAL SPECIFICATION APPROVALS
BSA IT Department
Internal Use Only
Page 2 of 9
Document Revision History
Version #
Date
Requestor
Revised By
Change Description
0.1
05/10/2015
draft
Glossary of Terms
Term/Acronym
Definition
Document Information
Purpose:
Requirements define the business solution. This document is used to gain agreement with stakeholders and to
provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy
the customers and business needs.
Audience:
All project team members
Project Sponsor, Business Owner, and IT/Technical Owner
All other key stakeholders
Criteria for Use:
Medium and Large projects
Timing:
Requirements are to completed during Planning
Completed before the Project Management Plan
Naming Convention:
The requirements should be saved with the following naming convention:
Requirements_ProjectName_AuthorInitials_MM_DD_YY (e.g. Requirements_ERP System_HP_01_10_15).
BSA IT Department
Internal Use Only
Page 3 of 9
Optional Sections:
Optional sections are noted in the headers. These are sections that do not need to be filled out, but if the
desire is to fill them out then the information can come directly from the Project Charter artifact.
Project Information - OPTIONAL
Project Manager
Project Sponsor
Overall responsible person
IT Owner
Escalation point in IT
Business Owner
Escalation point in
business
Project
Description
Short description of the project (i.e. What is project about? Why is the project being
done? What are the high level goals of the project?)
Project Scope - OPTIONAL
Business Purpose, Objectives and Goals:
Problem/Opportunity Statement:
Provide a statement summarizing the problem to be solved or opportunity being addressed by this
project.
The problem of
affects
The impact of which is
A successful solution would
Systems & Interfaces
#
System
BSA IT Department
Interface
Internal Use Only
Impact
Page 4 of 9
As Is Environment
Provide a detailed description of the As-Is Environment
Current Process Flow
Show the current process flow below. Drop in a visio flowbelow.
System
Line of Busiess
Current Process Flow
Detail the process step-by-step below.
Process
Step
1
2
3
Req. #
Description
Inpu
t
Supplier
Output
Receiver (Customer)
To-Be Environment Details
Provide a detailed description of the To-Be Environment
BSA IT Department
Internal Use Only
Page 5 of 9
To-Be Environment Flow
Show the to-be environment process flow below. Drop in a visio flowbelow.
System
Line of Busiess
Current Process Flow
Detail the process step-by-step below.
Proces
s Step
1
2
3
Descriptio
n
Req. #
Inpu
t
Supplie
r
Outpu
t
Receiver (Customer)
Gap Analysis
Identify Process Gaps Between the As Is Environment and the To Be Environment.
Gap
ID
1
2
3
Gap
Name
BSA IT Department
Gap Type
Closure
Type
Internal Use Only
Comments
BASEL
Rule #
Page 6 of 9
Other Concerns/Elements
Identify all other observations or factors that were not captured in any sections above.
Description of Change(s)
Author(s) / Contributor(s)
Date
User Summary - OPTIONAL
Identify all end-user types, how they will be impacted by the new or modified product, service or system, and
which stakeholder represents their interest. This includes all internal and external customers and businesses
impacts
End User Types
Impact Description
Stakeholder
Business Requirements Approvals
Documented approvals are required from designated approvers.
Role/Name
Approval Date
Project Sponsor:
Business Owner:
Technology Owner, if applicable:
SYSTEM OVERVIEW
Brief description of the System:
Example: The <Application Name> is a vendor packaged system used for investment securities processing
and accounting that houses Bank of the Wests investment portfolio. Data from <Application Name> is
BSA IT Department
Internal Use Only
Page 7 of 9
extracted into Excel spreadsheets where its further supplemented with external data (e.g. Bloomberg) by
Treasury Ops to satisfy capital, exposure and regulatory reporting.
Type of Data in <Application
Name>
Customer/Counterparty Bank
User ID/Password/Security
System Reporting/Printing
Definitions
Moving to
<Application
Name> (in/out)
In
Out
Purpose/Usage
Adrindo II
N/A
N/A
Out
Requirements Catalog & Dashboard
The Business Team members (Business Owner and Business Analyst) document high level business
requirements (in columns A to D). These requirements are further decomposed to more detailed level functional
specification (in columns E to J). It accurately describes the essential technical requirements of the system to
be created or modified.
Each requirement and functional specification have unique IDs. A requirement priority is set for each functional
specification. The priority provides a direction to Development and Test teams in building and validating the
requirements as part of their activities.
The Test Team (Test Manager/Test Lead and Tester) is responsible for analyzing and reviewing if a requirement
is testable or not (in column H).
The team reviews the testable requirements for any ambiguities and documents ambiguity description. (for
columns K to N)
The Business Team then reviews these ambiguities and either rejects or accepts the ambiguities and provides
a suitable resolution. These ambiguities are tracked to closure using the status column by the test team. The
following values can be selected:
1. Open
2. Pending
3. Closed
4. Rejected
The test team tracks the ambiguities and documents date opened, the resolution provided and closure of
ambiguity.
Other Attachments
Attachment #
BSA IT Department
Attachment Description
Internal Use Only
Page 8 of 9
Requirements Descriptors
Priority
P1-High
P2-Medium
P3-Low
Description
Priority 1: First priority items those should be taken into consideration first.
Priority 2: Second priority items that should be taken care of once the P1s have
been completed.
Priority 3: Third priority items that are the lowest in priority and should be taken
care once the P1s and P2s are completed.
Status
Open
Pending
Closed
Rejected
Any new issue identified, that needs to be addressed
Any issue identified, that has been assigned to the respective owner and awaiting
clarifications
Issues that have been addressed to the satisfaction of the team
Issues that are rejected by the Business Analyst
Functional Specification Approvals
Name
Project Role
Approval Date
Business Owner
Technology Owner
BSA IT Department
Internal Use Only
Page 9 of 9