Business Requirements Specification
<Project Name>
Business Requirements Specification
<Document Subtitle>
Document ID / <Doc ID>Version / <n.n>
Version Date / <DD/MM/YY>
Process / <Hyperlink to process>
Table of Contents
Table of Contents 2
Approval 3
Contact Details 3
1 Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Audience 4
1.4 Definitions 4
1.5 References 4
2 Executive Overview 4
3 Background Information 4
4 Current Process 4
5 New Process 4
6 Business Requirements 5
6.1 High Level business Requirements 5
6.2 Detailed business Requirements 6
7. Non-Functional Requirements 6
7.1 Usability 6
7.2 Reliability 7
7.3 Performance 8
7.4 Supportability 9
7.5 Compliance 10
7.6 Security 10
7.7 Other 11
8 Quality Attributes 12
9 External Interfaces 12
10 User Attributes 12
10.1 User Type 1 12
10.2 User Type 2 12
10.3 User Type 3 12
11 Constraints & Assumptions 12
12 Stakeholders 12
13 <Template Version and Completion Instructions> 13
13.1 Template Version History 13
13.2 Instructions 13
The word shall indicate a course of action that must be followed unless a deviation has been approved. The word should indicate that a certain course of action is preferred, or not necessarily required. The word may indicate a permitted, but not mandatory, course of action.
Tailoring is only possible within the guidelines provided in the Tailoring Guidelines for this process.
Approval
<Business Manager>
<Technology Manager> / john
<Technology Release Manager>
<Lead Developer/Designer>
Contact Details
* Email any comments about this document to the document owner.
1 Introduction
1.1 Purpose
The purpose of this document is to specify exactly what is required from the user or business point of view. It sets the boundaries / scope of the development work by clearly articulating the set of requirements that need to be met, whilst also stating any boundaries or exclusions.
These requirements form the basis of the development work, and define the contractual obligation of the developer to the client. Any changes to these requirements shall be managed via Scope Management.
These requirements form the basis of User Acceptance Testing.
1.2 Scope
This document applies to <insert scope>
1.3 Audience
<Insert narrative>
1.4 Definitions
In this document:
· <AML means <Anti Money Laundering
· <Liability means <what you have to pay
1.5 References
Document / Description /<insert reference> / <insert description of reference>
2 Executive Overview
3 Background Information
4 Current Process
5 New Process
20/03/2015 Page 6 of 16
6 Business Requirements
Business requirements describe the business need in terms of behaviours or operations. Business requirements do not describe a technical solution or system functions.
Requirements (both Business Requirements and Non-functional Requirements) are categorised using the following priorities:
Priority /Mandatory / (M) / Will not accept a solution that does not fulfil this business need.
Desired / (D) / It is highly preferred that the solution fulfils this business need.
Optional / (O) / It is considered an advantage that the solution fulfils this business need.
Requirements are traced back to scope items via the “Ref to Scope” column.
It is mandatory to complete either 6.1 and / or 6.2
6.1 High Level business Requirements
High level business requirements are generally defined as an input into the business case and support initial estimates.
Requirement ID / Ref to Scope / Business Requirements / Priority / Owner /FR_TRC_HL001 / Users should be able to track their packages using their tracking number / M / John (Tracking Department)
FR_TRC_HL002 / Users should be notified by sms or email if they have registered for alerts. / M / John
NFR_TRC_HL001 / System should be available 24/7 / M / Ken
6.2 Detailed business Requirements
Detailed business requirements are generally defined following approval of a business case and support detailed quotes. For less complex initiatives, where a business case is not required, only detailed requirements will be defined.
Requirement ID / Ref to Scope / High Level Requirements [1] / Business Requirements / Priority / Owner /FR_TRC_DR001 / FR_TRC_HL001 / An option to enter the tracking number should be available on the website / M / Phil
FR_TRC_DR002 / FR_TRC_HL001 / On entering the correct tracking number, the system should provide the details of the package and the correct status
FR_TRC_HL001 / On entering the wrong tracking number, the system should throw an error message “Incorrect Tracking number”
7. Non-Functional Requirements
Non-functional requirements capture the qualities that the solution must have.
Classifications of non-functional requirements that should be considered include; User Experience, Reliability, Performance, Supportability, Compliance, Security, Volume.
7.1 Usability
You may wish to consider the following:
· User location and languages – where will the users be located? Are there any specific requirements for each location? Which languages are required? If English then which version?
· User limitations – are any of your users colour blind, deaf, have poor eyesight?
· User documentation and training materials – what user documentation is required? Who will prepare this? Is a help function required for new or infrequent users? What training materials are required? Who will prepare this? How will they be made available to the user?
Requirement ID / Ref to Scope / High Level Requirements [2] / Requirements / Priority / Owner /7.2 Reliability
You may wish to consider the following:
· Availability – when does the solution need to be available, e.g. Monday to Friday 7:30am – 6:00pm? Are there different levels of availability required for different times? Are different users able to access the solution at different times? Is access required from different locations?
· peak usage – what are the times of peak usage e.g. daily 11am – 4pm, weekly Fridays, monthly first or last working day of month?
· cut off times – what Service Level Agreements are in place (or will be in place)? Are there specific times when certain business functions must be completed?
· data retention – what is the data retention period for back up data? Are there any legal and compliance requirements that are appropriate to when or how information can be disposed?
· archiving – what is the action required at the end of retention period? Is there a need for an archiving solution? How often should information be archived from the solution? When is information to be deleted from the archive?
Requirement ID / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /7.3 Performance
You may wish to consider the following:
· End-to-end processing – how long is the end-to-end process expected to take? What are the average and maximum acceptable run times for each process?
· Specific processing jobs – are there any specific requirements for run times of particular processing jobs? What are the average and maximum acceptable run times for each?
· Report run times – are there any specific requirements for report run times? How complex (in your opinion) are the reports? Are there any examples that can be used to help evaluate the complexity? Suggested levels are: complex; intermediate; simple.
· Data capacity / volume – how much information is expected to be captured by the solution? Consider volume of both static data and transactional data. What is the expected growth in information over the next 6 months; 1 year; 2 years; 5 years? Are there any limitations to the total amount of information to be stored?
·
Requirement ID / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /7.4 Supportability
You may wish to consider the following:
· Installation – are any specific requirements that may influence the way the solution is made available to the business teams?
· Localisation / Internationalisation – are there any specific local requirements for installation of the solution in particular countries?
· Impact of solution changes – what are the impacts if a function is modified? Is testing required by any other business units or solution teams? Consider both internal and external parties. Are there any other dependencies that need to be considered?
· Expected Life of Solution – what is the expected life of the solution? What year can the solution expect to be decommissioned? How often will the solution be reviewed to decide on its ongoing life?
· User capacity – how many users are there at go-live? What is the expected growth in users, e.g. over next 6 months; 1 year; 2 years; 5 years? Are there any limitations to the total number of users? Are there any limitations to the number of concurrent users?
Requirement ID / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /7.5 Compliance
You may wish to consider the following:
· Segregation of duties – are there any specific requirements for segregation of duties?
· Audit Logging – do you need to know who has applied changes to the business rules within the solution? What reporting is need and when? How long is the audit information retained?
· Control points – are there any specific requirements for compliance with SOX?
Requirement ID / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /7.6 Security
You may wish to consider the following:
· Physical access/logon – is user authentication required upon sign in? What authentication is required, e.g. ID & password or multi-stage authentication? Does authentication happen in the background or is visible to the user?
· Logical access/user access – do different groups of people have different access? What security groups or roles are required e.g. read only, read / write user, admin user? What functions can be performed by each group or role?
· User administration – Who is responsible for adding new users and deleting old users?
· User access reviews – are user reviews required? How often? Who will perform them?
· User Security Documentation – what user security documentation is required? Who is responsible for producing this?
Requirement ID / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /7.7 Other
List any other Non-Functional requirements that are not covered by the previous sections, e.g. implementation requirements.
Requirement ID / Non-Functional Classification / Ref to Scope / High Level Requirements / Requirements / Priority / Owner /20/03/2015 Page 6 of 16
8 Quality Attributes
9 External Interfaces
10 User Attributes
10.1 User Type 1
Paragraph
· List Bullet
· List Bullet
- List Bullet Indent
10.2 User Type 2
Paragraph
· List Bullet
· List Bullet
- List Bullet Indent
10.3 User Type 3
Paragraph
· List Bullet
· List Bullet
- List Bullet Indent
11 Constraints & Assumptions
12 Stakeholders
Name / Title /13 <Template Version and Completion Instructions>
The above title, this paragraph and all of the following must be deleted from the document prior to its publication.
13.1 Template Version History
Version / Release Date / Change Description / Author /1.0 / 18/10/2004 / Initial draft / R. Meddings
2.0 / 21/10/2008 / Updated all references from PS to PT and removed wording Process Bank as this is a local template / R. Meddings
3.0 / 24/03/2010 / Added additional functional requirements 6.1 & 6.2 and non functional requirement attributes 7.1 – 7.7 / M. Montgomery
4.0 / 20/04/2020 / Updated name and title of approvers / M. Montgomery
13.2 Instructions
All sections are mandatory except Audience.
Section / Comments /Front Cover / The Project Name, Document Title and Document Subtitle.
· Project Name is the name of the project, area, or other organisational unit for which the document is written.
· Document Title is used in the header and so should be kept short but meaningful.
· Document Subtitle is any further information needed to specifically identify the document. The subtitle may be left blank.
Document ID / The unique document identifier.
Version / The document version number.
Approval / Table recording approvals given to specific versions of the policy. Includes version, approval date, and approver name and title.
Contact Details / Standard wording consisting of an email link to Payments Technology for comments and a link to the Payments Technology Home page.
Version History / Table recording revisions of this document. Includes version, release date, change description, and author. The description shall include the names of reviewers or the name of the review.
Section 1
Introduction / Do not delete Section 1 – it is a standard requirement. It helps the reader who may not be aware of the context of the document to find out what it is about and whether it contains the information they need.
The space under the Introduction heading may be left blank, or used as an overview of the document.
Purpose / The purpose of the document.
· Keep it brief
· Explain why the document exists
· Relate it to the strategic objectives of OTSS-IT wherever possible.
Scope / This section should answer:
· What is the main reason for this document?
· What does it cover? (For example, is it for the whole project, or just one of its phases?)
Keep the stated purpose, scope and audience in mind as you write the rest of the document.
Audience / The roles for which this document is intended. This is optional.
Definitions / This heading is optional and may be removed if not required.
Include the definitions of terms used in this document that do not appear in the site. If a term is used in more than one document then it should be considered for inclusion in the central glossary to avoid repetition and to minimise the risk of having conflicting definitions in different documents.
References / List of Policy, Procedure and other documents referenced in this document.
· Do not include procedures from outside Payments Technology procedure variants.
· Other documentation may include information sources, training materials, frequently asked questions, communications and presentations.
Section 2
Executive Overview / High level description of the overall requirements for the change / project. You may list the requirements in shortened form to ensure an appropriate overview is gained by reading this section.
Background Information / Brief background information about the change / project. Why are we doing this? Is this a new development or an enhancement to an existing system? Provide references (eg Work Request #) if appropriate.
Functional Requirements / List in the table provided every user requirement. Note that users include IT users. Requirements shall be:
· specific
· measurable
· uniquely identified – preferably numbered, to ensure ease of traceability
· unambiguous
Requirements shall contain:
· a clear description of the requirement
· exception situations
· priority
· volume / frequency of use
· relevant business rules
· assumptions
Each requirement shall not contain any solution, unless the solution itself is a user requirement. For example, the use of Outlook is mandatory within the organisation, therefore when creating requirements for a change requiring email, Outlook should be listed as a requirement, even though it is also part of the solution.
Quality Attributes / Include non-functional requirements such as:
· performance
· availability
· technology policies / standards
· Security considerations.
External Interfaces / Are there external interfaces that need to be considered? For example, are there similar facilities with other organisations (eg outsourcing) that need to be considered. Note: These are external interfaces from the user’s point of view, not from a technology application point of view.
User Attributes / Define the user attributes – how many different types of users are there, what are these types, when are their peak usage periods, access requirements, etc.
Constraints / Describe the constraints and assumptions that are present. Common constraints and assumptions are related to:
· Timeframe
· Cost
· Regulatory
· Customers
A constraint is a known limitation on the solution (this corresponds to an issue). An assumption refers to a factor which may impact the solution, but its existence or the extent of its impact cannot be confirmed at time of writing (this corresponds to a risk).
20/03/2015 Page 6 of 16