0% found this document useful (0 votes)
94 views

BA Requirements Template Complete

This requirements template provides documentation for the requirements of a new hospital fundraising platform. It includes an introduction that outlines the goals of creating a centralized connected fundraising website for donors, provides the current state process maps, and defines the scope. The solution requirements section maps out the future state processes and includes use cases. Non-functional requirements and additional details are also documented. Stakeholders involved in authoring and approving the requirements are identified.

Uploaded by

Amina Omar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
94 views

BA Requirements Template Complete

This requirements template provides documentation for the requirements of a new hospital fundraising platform. It includes an introduction that outlines the goals of creating a centralized connected fundraising website for donors, provides the current state process maps, and defines the scope. The solution requirements section maps out the future state processes and includes use cases. Non-functional requirements and additional details are also documented. Stakeholders involved in authoring and approving the requirements are identified.

Uploaded by

Amina Omar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Requirements Template

Business Analysis
Requirements Template

Requirements Template

vX.0 December 2021 0|Page


Requirements Template

Table of Contents
Overview......................................................................................................................................................2
Using the Requirements Template..............................................................................................................3
Requirements Template Author(s)/Reviewer(s)..........................................................................................3
Requirements Template Distribution List....................................................................................................4
Requirements Template Approver(s) List....................................................................................................4
Requirements Template Reference Artifacts(s)...........................................................................................5
1 Introduction.........................................................................................................................................5
1.1 Goal(s)..............................................................................................................................................5
1.2 Objective(s)......................................................................................................................................5
1.3 Problem/Opportunity Statement(s).................................................................................................6
1.4 As-Is/Current State Process Map(s).................................................................................................6
1.4.1 As-Is/Current State Process Map(s) – Level 2...........................................................................7
2 Requirements Scope............................................................................................................................8
2.1 High-Level Requirement(s)/In Scope...............................................................................................9
2.2 Out-of-Scope....................................................................................................................................9
2.3 Scope Model(s)..............................................................................................................................10
3 Solution Requirements......................................................................................................................12
3.1 To-be/Future State Process Map(s)...............................................................................................12
3.1.1 To-be/Future State Process Map(s) – Level 2.........................................................................12
3.1.2 To-be/Future State Process Map(s) – Level 3.........................................................................12
3.2 Use Case(s).....................................................................................................................................15
3.2.1 Actor Summary......................................................................................................................15
3.2.2 Use Case Specification(s)........................................................................................................15
4 Non-Functional Requirements...........................................................................................................16
5 Additional Details & Notes.................................................................................................................17

vX.0 December 2021 1|Page


Requirements Template

Overview
The Business Analysis for the Hospital Fundraising Platform by Gift Targets. The goal of
the Requirements Template is to provide business analysts and other members of the
project team working on the fundraising platform, the needed requirements to complete
any necessary documents, models, diagrams relevant to the creation of this project.
This document will serve as a reference and repository for any Business Analysis
artifacts produced.

Using the Requirements Template


The Requirements Template provides readers with a comprehensive understanding of
the needs, scope and specifications leading to a solution. When using the
Requirements Template:
● Uniquely identify each artifact documented
● Complete the Requirements Trace Matrix to ensure comprehensive
requirements coverage

vX.0 December 2021 2|Page


Requirements Template

Requirements Template Author(s)/Reviewer(s)


The Business Analyst(s), or alternative role(s) authoring or reviewing the Requirements
Template. Reviewers are the individuals who evaluate the content for quality, completeness
and accuracy. List the names, roles performed on the project, when they were engaged and
the date they sent in their final acknowledgement of completed review
Name Role (Author/Reviewer) Start/Review Date
Sarah Ayano Author October 25, 2022
Alexander White Author October 25, 2022
Elakkiya Logendran Author October 25, 2022
Amina Omar Author October 25, 2022
Eryn Sagadraca Author October 25, 2022

Requirements Template Distribution List


Those who will receive a copy of the completed, signed off Requirements Template. Provide
the full name, role and contact information.
Name Role E-Mail
Sarah Ayano Business Analyst Sarah.Ayano@george
brown.ca

Alexander White Business Analyst Alexander.White@geor


gebrown.ca

Elakkiya Logendran Business Analyst Elakkiya.Logendran@g


eorgebrown.ca

Amina Omar Business Analyst Amina.Omar@georgebrow


n.ca

Eryn Sagadraca Business Analyst Eryn.Sagadraca@georgeb


rown.ca
Soorej Business Analyst [email protected]

vX.0 December 2021 3|Page


Requirements Template

Requirements Template Approver(s) List


Those Business and/or Technology leads who will receive a copy of the completed
Requirements Template, and who must accept what has been documented in the
Requirements Template.
Name Title Date Signature
Tyler Krimmel Owner December 17th,
2022

Requirements Template Reference Artifacts(s)


This information in this section provides context for the project, based on the input
information used to support the vision and needs of this initiative.
File/Artifact Name Source/Location
Business Requirements BlackBoard
High Level Requirements BlackBoard
Business Process Map BlackBoard
Future State BlackBoard

1 Introduction
This section of the Requirements Template provides readers of this document with the
Business Requirements of the Initiative. This will include; Goals, Objectives,
Problem/Opportunities, and Current State Process Maps. For each table, add rows as
required.
1.1 Goal(s)
Qualifiable statements defining what the organization is seeking to establish and/or
maintain.
Unique ID Goal Statement
GO001 To create a centralized and connected fundraising website for donors.

GO002 Provide for the technical and mechanical requirements of hospitals associated with the
business.

GO003 Connecting donors to a collaborative fundraising website.

1.2 Objective(s)
Statements of the quantitative measures of success to be realized.

vX.0 December 2021 4|Page


Requirements Template

Unique ID Objective Statement Traced to:


OB001 Lower website fees by 3% or more GO002
OB002 Aggregating donors and donations for the hospital through the website GO001
and efficiently utilize the money.

1.3 Problem/Opportunity Statement(s)


The Problem/Opportunity Statements (POs) provide factual, quantifiable, and concise
descriptions of a problem or opportunity. The statement(s) do not recommend or provide a
solution. Identify who the impacted actor/organization is, what the issue is, and where and
when the issue is occurring.
Unique ID Problem/Opportunity Statement Traced to:
PO001 Currently, donation website fees (8-10%) are too high for the hospital OB001,
to sustain. The existing method for donation processing and OB002,
equipment procurement has resulted in the need to create a
specialized platform for collaboration between donors to secure
funding, start the procurement process earlier, prevent equipment
ordering delays (2-3 months or longer), and ensure hospital
operational supplies are fully stocked.

vX.0 December 2021 5|Page


Requirements Template

1.4 As-Is/Current State Process Map(s)


Capture the current state processes following the process taxonomy defined (L2/L3). For
each process mapped, provide a summary description. Replicate these tables as needed
for each map.
1.4.1 As-Is/Current State Process Map(s) – Level 2
Process Name: Donation process
Unique ID: CSPM-001 Level: L2

Description: L2 diagram outlines the stakeholders, processes, inputs and


outputs of the donation process

vX.0 December 2021 6|Page


Requirements Template

Process Metrics: 1. Process begins when the user accesses the platform
GoFundMe
2. User browses through the fundraising initiatives of
hospitals provided on GoFundMe
3. User decided on initiative to donate to
4. User enters Name, Credit Card and billing information
to be able to send money to selected fundraiser
5. Bank approves donation
6. Money deposited in bank account
DOWNTIME
Analysis:

vX.0 December 2021 7|Page


Requirements Template

2 Requirements Scope
Scope/Stakeholder Requirements address the business need(s). These statements and
models form the boundary of the ‘Requirements Scope’, which is a subset of the overall
project scope. This section will include: High-Level Requirements Statements, Out-of-
Scope, and scope models (e.g. Business Context Diagram). For each table, add rows as
required.
2.1 High-Level Requirement(s)/In Scope
Statements of the needs of a particular stakeholder or class of stakeholders that enable the
Business Requirements. The initiative must meet these needs. For each Requirement
Statement, ensure to define the Priority (High, Medium, Low) as well as trace to P/O
statements.
Unique ID: High-Level Requirement Statement(s) Priority Traced to:
HLR001 Donors must receive the link to the donation High GO001,
platform. GO002,
GO003
HLR002 Donors must have the option to donate funds High GO001,
collaboratively with other prospective donors GO002,
and choose which initiative to donate to via the GO003
fundraising platform.
HLR003 Donors must be able to receive a donation High GO001,
receipt after their donation. GO002,
GO003
HLR004 The platform must be able to send a donation High GO001,
receipt to donors after their donation is complete. GO002,
GO003
HLR005 The platform must display the finalized catalogue High GO001,
for donors to choose a desired medical equipment GO002,
to fund. GO003

2.2 Out-of-Scope
This Section is meant to document results of the discussions and decisions that were made
to exclude requirement(s) from the scope of the initiative. Be sure to define the rational for
exclusion.
Unique ID: Out-of-Scope Statement(s) Rational
OS001 Dark money Bank institutions to verify
currency
OS002 More than $10,000 or cash donation Harder to keep track of
donations if money is

vX.0 December 2021 8|Page


Requirements Template

collected from different


avenues
OS003 Donation using cheques Extra work to deposit
cheque; may be a delay
depending on bank
institution

2.3 Scope Model(s)


Technique(s) that provides a view of the business needs, external of the solution. Describe
each of the entities and information flows depicted in the diagram to avoid ambiguity.

vX.0 December 2021 9|Page


Requirements Template

Scope Model: Vendor Onboarding Robot


Unique ID: BCD001 Traced to: CSPM-001

Entity Descriptions: Donors- to donate funds collaboratively with


other prospecting donors so that we can fulfill a donation
initiative in getting targeted medical equipment.
Fundraising Platform- a bridge between
donors and recipients so hospitals can retrieve desired
medical equipment at a better cost than online
fundraising platforms, and donors are notified of their
impact on donating towards an initiative.
Hospitals- Initiating the fundraising initiative
Vendors- Sellers of medical equipment
Information - Collaborative Donations
Descriptions: - Donation Notification
- Donation Receipt
- Catalogue Showcase
- Feedback Reports
- Donation Link
- Fundraising Request
- Service Fee Payment
- Catalogue Supply

vX.0 December 2021 10 | P a g e


Requirements Template

- Financial Management
- Completion of Fundraising Goal Notification
- Real-time Fundraiser Tracker

3 Solution Requirements
This section describes the capabilities and qualities of a solution that meets the stakeholder
requirements. They provide appropriate level of detail to allow for development and
implementation of the solution. This section will include: Future State/To-be Process Maps
(L2/L3), Process Specifications (Use Cases), Business Rules & Calculations, Data
Requirements, UI/Screen Specifications & Notifications, Reporting Requirements, and Non-
Functional Requirements.
3.1 To-be/Future State Process Map(s)
Document the future state processes following the process taxonomy defined (L2/L3). For
each process mapped, provide a summary description. For L2 Future State Maps, be sure
to summarize each key activity/function defined. Replicate these tables as needed for each
map.
3.1.1 To-be/Future State Process Map(s) – Level 2
Process Name: SIPOC Model of the Future state of Donating Funds
Unique ID: FSPM-001 Level: L2

Description: The SIPOC model demonstrates the high-level requirements


for the future state of Donating funds. This model is about the
requirements and the artifacts needed to complete the donating
funds process.
Traced to: BCD001

vX.0 December 2021 11 | P a g e


Requirements Template

3.1.2 To-be/Future State Process Map(s) – Level 3


Process Name: Register
Unique ID: FSPM-001.S1 Level: L301
Donor

Description: The Future state BPMN model of the registration between the two
actors, the donor and the Gift Target platform. The donor either
logins in with an existing account or creates an account in order
to access the donating platform.
Traced to: BCD001

Process Name: Search

vX.0 December 2021 12 | P a g e


Requirements Template

Unique ID: FSPM-002.S1 Level: L302


Donor

Description: The donor’s search process is demonstrated on the future state


BPMN model.
Traced to: BCD001

Process Name: Donation


Unique ID: FSPM-003.S1 Level: L303

vX.0 December 2021 13 | P a g e


Requirements Template

Donor
Gift Targets
Bank

Description: The future state BPMN model demonstrates the interaction


between three actors, which are the donor, the gift Target
platform and the Bank. The donating process is shown in the
diagram above.
Traced to: BCD001

3.2 Use Case(s)


The Use Case Specification provides elaborated details of a L3 Business Process Map.
Within the context of a Process Map, it demonstrates the expected interaction with the
system(s). In the context of an RPA initiative, the Robot will be identified as an actor, so
that interaction, scenario flows, logic, and information used by the Robot are clearly defined.
3.2.1 Actor Summary
Define the actors (people, systems) in scope of the use case specifications provided. A Use
Case Diagram can be used to visually represent actors.
Unique ID: Actor Description Role (Primary/ Traced to
Secondary) L3:
ACT001 Donor Primary L301, L302,
L303
ACT002 Gift Target (GT) platform Secondary L301, L303
ACT003 Bank L303

vX.0 December 2021 14 | P a g e


Requirements Template

3.2.2 Use Case Specification(s)


The Use Case Specification provides details on steps, data, rules, interface, and reporting
for each Use Case identified in the Use Case Diagram.
Unique ID: Use Case Specification UC Specification File Traced to
Name & Description (attachment) L3:
UC001 User Registration BA_Use L301
Case_Registeration
UC002 User Search GT Platform BA_Use Case_ Search L302
UC003 User Donation Process BA_Use Case_ Donation L303
Process

4 Non-Functional Requirements
Non-Functional Requirements describe a system operation, or quality. These qualities may
include describing a systems performance, capacity, security, availability, redundancy and
recovery, and continuity. Listed below are a primary subset of key NFRs for RPA
consideration. Complete this only as needed, as NFR conditions may have already been
included as part of the HLR statements.

Unique NFR Category NFR Requirement Traced


ID: to:
NFR001 Language System shall use English as a primary language to L30
communicate with the users and optional second
language will be French.
NFR002 Availability (Days of System shall be available for fundraising L30
Usage) depending on the time period of the initiative.
Will be available for donations and to browse
catalogue 24hrs/7 days a week except for
scheduled maintenance windows.
NFR003 Performance The system shall respond within 3 seconds of user L30
request input or navigate to another catalogue.
NFR004 Response Time The system shall respond within 3 seconds of user L30
request.
NFR005 # of concurrent events System able to process 3 or more events that can L30
occur at the same time. An example is the user
browsing catalogue and being able to search in the
fields given.
NFR006 # of system users Shall accommodate up to 1000 users. L30

NFR007 User Location System shall support users located in Ontario. L30

vX.0 December 2021 15 | P a g e


Requirements Template

NFR008 Privacy System shall mask credit card numbers except for L30
the last 4 digits when the user is inputting existing
payment information and shall encrypt payment
information retained.
NFR009 Security System shall implement a firewall to protect from L30
unauthorized access and all users will have access
to GT’s Terms of Conditions prior to donating.
NFR0010 Data Retention System shall maintain data records for 24 L30
months from the moment of donation.
NFR0011 Accessibility System shall follow accessibility guidelines as L30
suggested by the Gift Targets organization.

vX.0 December 2021 16 | P a g e


Requirements Template

5 Additional Details & Notes


Please provide any additional details to support this Requirements Specification.

vX.0 December 2021 17 | P a g e


Requirements Template

vX.0 December 2021 0|Page

You might also like