FOR:

Headstrong
CONTENT:

Business Requirements Document Template

ENG-TEM-14 Version 1.1 07-Apr-2009

User of this document is responsible to use only the current version available on HQ. This document is for restricted in-house circulation. No part of this document shall be reproduced, stored retrieval system or transmitted in any form or by any means recording, photocopying, electronic and mechanical without prior permission of Headstrong.

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

Document History
Version Date
(dd-mmm-yyyy)

Author

Description of Change

Reviewed By

Approved By

Distribution List
Details

Reference Documents
Document Name

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 2 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

TABLE OF CONTENTS
1 INTRODUCTION.......................................................................................................................................5 1.1Purpose ...........................................................................................................................................5 1.2Audience..........................................................................................................................................5 1.3Scope ...............................................................................................................................................5 1.4Acronyms and Definition...............................................................................................................5 ...............................................................................................................................................................6 2 OVERVIEW...............................................................................................................................................6 2.1Business Description ....................................................................................................................6 2.2Stakeholder Requests....................................................................................................................6 2.2.1Establish Stakeholder Profile......................................................................................................6 2.2.2Establish User or Customer Profile.............................................................................................7 2.2.3Assess the Problem.....................................................................................................................7 2.2.4Understanding the User Environment.........................................................................................7 2.3Process Schematic.........................................................................................................................8 3 BUSINESS REQUIREMENTS.................................................................................................................10 3.1Functional Requirement <RID> ..................................................................................................10 3.1.1Description.................................................................................................................................10 3.1.2Rationale....................................................................................................................................10 3.1.3Source.......................................................................................................................................10 3.1.4Dependencies / Conflicts / Assumptions...................................................................................10 3.1.5Priority........................................................................................................................................10 3.1.6Verification.................................................................................................................................10 3.1.7High Level Use Cases...............................................................................................................10 3.2Functional Requirement <RID> ..................................................................................................11 3.2.1Description.................................................................................................................................11 3.2.2Rationale....................................................................................................................................11 3.2.3Source.......................................................................................................................................11 3.2.4Dependencies / Conflicts / Assumptions...................................................................................11 3.2.5Priority........................................................................................................................................11 3.2.6Verification.................................................................................................................................11 3.2.7High Level Use Cases...............................................................................................................11 3.3Other Implicit Functionality ........................................................................................................11 4 TECHNICAL REQUIREMENTS..............................................................................................................12 4.1Usability ........................................................................................................................................12 4.1.1Usability Requirement <RID>....................................................................................................12 4.2Reliability ......................................................................................................................................12 4.2.1Reliability Requirement <RID>..................................................................................................12 4.3Performance .................................................................................................................................12 4.3.1Performance Requirement <RID>.............................................................................................13 4.4Security / Privacy .........................................................................................................................13 4.4.1Security Requirement <RID>....................................................................................................13
<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 3 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

4.5Portability / Migration ..................................................................................................................13 4.5.1Portability / Migration Requirement <RID>................................................................................13 4.6Supportability ...............................................................................................................................13 4.6.1Supportability Requirement <RID>............................................................................................13 5 EXTERNAL INTERFACES.....................................................................................................................14 6 PROJECT VALUE STATEMENT............................................................................................................14 7 ASSUMPTIONS AND DEPENDENCIES.................................................................................................14 8 APPENDIX..............................................................................................................................................14 8.1Business Rules ............................................................................................................................14 TEMPLATE HISTORY..............................................................................................................................15

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 4 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

INTRODUCTION
1.1 Purpose The purpose of the Business Requirements Document is to define <client name>s requirements for the <project name>. Requirements are established through a combination of analysis and gathering information from stakeholders (e.g., customers, end users, SME, and testers), through interviews, observation, focus groups, and surveys. The stakeholder needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements. The Business Requirements Document is the basis for building the system. This document helps to translate the clients understanding of the system into terms that are understandable to the development team. Any changes from the definition of the <project name> as in this Business Requirements Document will require changes through the Change Request Procedure as defined in the Requirements Management Process. This document contains the result of requirements study efforts conducted for the <project name> and is outcome of discussions and informal interviews between <client name> and Headstrong project team. 1.2 Audience Specify the target audience of this document. The target audience of this document is the project teams and management of both Headstrong and <client name>. The audience should read the <client name> proposal dated dd/mm/yy prior to reading this document. 1.3 Scope This document covers the following sections: Section Name Overview Business Requirements Technical Requirements External Interfaces Project Value Statement Assumptions and Dependencies Definition of Terms and Acronyms Business Rules 1.4 Purpose Provides an overview of the objective and scope of the Business Requirements. Defines the... Defines the ... Defines the... Provides... Defines the ... Defines the ... Defines the...

Acronyms and Definition

<Specify in this section the definition of the terms and acronyms used throughout this document> <Note: Sort the items in this table in ascending order)
<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 5 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

<Term 1> <Term 2> <ACRONYM>

- <Definition> - <Definition> - <Definition>

OVERVIEW
This section provides an overview of the business domain. 2.1 Business Description Describe here the type of business, business rules, and the unique characteristics of this domain, e.g. health, telecommunications, banking, real estate, etc. Also include subdivisions of the business, like public, private, defense, etc., as each of those may require or affect the project scope and resource allocation through understanding of this model (e.g. security clearance for some type of financial projects). Try to explain the business environment associated with or related to it, and other types of business or sectors that are affected by it. 2.2 Stakeholder Requests Understanding stakeholder or user needs before beginning development is crucial to success of this process. 2.2.1 Establish Stakeholder Profile Describe each stakeholder in the system here by filling in the following table for each stakeholder. Remember stakeholder types can be as divergent as users, strategy departments and technical developers. A thorough profile should cover the following topics for each type of stakeholder: Stakeholder Name Representative Description Type Responsibilities Success Criteria Involvement Deliverables Comments / Issues [Who is the stakeholder representative to the project? (Optional if documented elsewhere.) What we want here is names.] [Brief description of the stakeholder type.] [Qualify the stakeholders expertise, technical background, and degree of sophisticationthat is, guru, business, expert, casual user, etc.] [List the stakeholders key responsibilities with regards to the system being developedthat is, their interest as a stakeholder.] [How does the stakeholder define success? How is the stakeholder rewarded?] [How the stakeholder is involved in the project? Relate where possible to RUP workersthat is, Requirements Reviewer etc.] [Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system under development.] [Problems that interfere with success and any other relevant information go here.]

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 6 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

2.2.2

Establish User or Customer Profile

Describe each unique user of the system here by filling in the following table for each customer type. A thorough profile should cover the following topics for each type of user: Customer Name Representative Description Type Responsibilities 2.2.3 [Who is the user representative to the project? (Optional if documented elsewhere.) This often refers to the Stakeholder that represents the set of users, for example, Stakeholder: Stakeholder1.] [A brief description of the customer type.] [Qualify the customers expertise, technical background, and degree of sophisticationthat is, guru, casual user, etc.] [List the users key responsibilities with regards to the system being developed that is, captures customers details, produces reports, coordinates work, etc.]

Assess the Problem

Provide a statement summarizing the problem being solved by this project. The following format may be used: The Problem Of Affects The Impact of Which is A Successful Solution Would be 2.2.4 [Describe the problem] [The stakeholders affected by the problem] [What is the impact of the problem] [List some key benefits of a successful solution]

Understanding the User Environment

Detail here information about the users environment, e.g. Platforms used, background knowledge of the users, computer knowledge of the users, etc Type of environment: Operating Systems Used: Applications used similar to this to or to be used on top of it: OS planned for future: Specific applications that need to be interfaced with the system: Documentation Requirements: Examples <Windows 95, Windows 98; Apple Mac> <e.g. E-mail storage systems (Lotus Notes, Microsoft Outlook)...etc>

Windows 2000 E-mail system with a voice application, legacy AS400 with Web Application...

PDF on line, Hard copy Manuals

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 7 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

2.3

Process Schematic

The process flow and information flow schematic should depict without ambiguity the individual processes that result in the completion of a particular function. This should also depict how the processes/information flow effect ancillary functional areas. It needs to be stated and described along with the process flow diagram below.

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 8 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 9 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

BUSINESS REQUIREMENTS
This section describes the functional requirements of the system. This section is typically organized by system feature. 3.1 Functional Requirement <RID> Important Note: Each requirement must be identified by a unique Requirement ID (RID). Please refer to the Requirements Traceability Matrix Template for the possible values of the RID. Describe each requirement in the following format: 3.1.1 Description Provide an overview of the feature. A well-written requirement is: Correct (accurately describes the real requirement) Unambiguous (all statements have exactly one interpretation) Complete (If any TBDs remain, document why the information is unknown, who is responsible for resolution, and the deadline for resolution) Verifiable (avoid descriptions like works well or user friendly; uses concrete terms, specifies measurable quantities) 3.1.2 Rationale 3.1.3 3.1.4 Source Dependencies / Conflicts / Assumptions

Why is this requirement to be included? Where does the requirement come from? Is it a document, person, implied? Is this requirement dependent on another for pre-existence or co-existence? Does this requirement conflict with any other requirements? Have you assumed anything? 3.1.5 3.1.6 3.1.7 Priority Verification High Level Use Cases High, Medium, Low Is any special verification or testing required for this functional requirement? Provide a high level concept of the Use Case (or equivalent technique). The Use Cases will be fleshed out in the System Requirements Document. The high-level use case will include a list of the following: Actors Actions Artifacts Acceptance Criteria (The x action needs to be completed in x seconds?)

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 10 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

3.2

Functional Requirement <RID> 3.2.1 Description

Describe each requirement in the following format: Provide an overview of the feature. A well-written requirement is: Correct (accurately describes the real requirement) Unambiguous (all statements have exactly one interpretation) Complete (If any TBDs remain, document why the information is unknown, who is responsible for resolution, and the deadline for resolution) Verifiable (avoid descriptions like works well or user friendly; uses concrete terms, specifies measurable quantities) 3.2.2 Rationale 3.2.3 3.2.4 Source Dependencies / Conflicts / Assumptions

Why is this requirement to be included? Where does the requirement come from? Is it a document, person, implied? Is this requirement dependent on another for pre-existence or co-existence? Does this requirement conflict with any other requirements? Have you assumed anything? 3.2.5 3.2.6 3.2.7 Priority Verification High Level Use Cases High, Medium, Low Is any special verification or testing required for this functional requirement? Provide a high level concept of the Use Case. The Use Cases will be fleshed out in the Functional Specification. The high-level use case will include a list of the following: 3.3 Actors Actions Artifacts Acceptance Criteria (The x action needs to be completed in x seconds?) Other Implicit Functionality

Provide a high level concept of all other Implicit Functionality in this section. This could be all such cases, which are not captured in the previous section such as provision of User Help etc.

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 11 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

TECHNICAL REQUIREMENTS
4.1 Usability This section should include all of those requirements that affect usability. For example: Specify requirement to conform to common usability standards, such as IBMs CUA standards Microsofts GUI standards etc. Specify the required training time for a normal users and a power user to become productive at particular operations Specify measurable task times for typical tasks or base the new systems usability requirements on other systems that the users know and like 4.1.1 4.2 Usability Requirement <RID> The requirement description goes here. Reliability Requirements for reliability of the system should be specified here. For example: Availabilityspecify the percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, etc. Mean Time Between Failures (MTBF) this is usually specified in hours, but it could also be specified in terms of days, months or years. Mean Time To Repair (MTTR)how long is the system allowed to be out of operation after it has failed? Accuracyspecifies precision (resolution) and accuracy (by some known standard) that is required in the systems output. Maximum Bugs or Defect Rateusually expressed in terms of bugs per thousand of lines of code (bugs/KLOC) or bugs per function-point (bugs/function point). Bugs or Defect Ratecategorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a critical bug; for example, complete loss of data or a complete inability to use certain parts of the systems functionality. 4.2.1 4.3 Reliability Requirement <RID> The requirement description goes here. Performance The systems performance characteristics should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name. For example: Response time for a transaction (average, maximum) Throughput, for example, transactions per second Capacity, for example, the number of customers or transactions the system can accommodate Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner) Resource utilization, such as memory, disk, communications, etc.

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 12 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

4.3.1 4.4

Performance Requirement <RID>

The requirement description goes here. Security / Privacy The systems security requirements should be outlined here. For example: What needs to be done to prevent hackers, virus distribution, credit card fraud, and distribution of questionable material? What about Firewalls What about physical security Is there a Virtual Private Network (VPN) Is any information company proprietary or client confidential? Is SSL required? What will be the location of hardware hosted and collocated with some ISP, application on shared server and its implication if other application crashes the system, hardware is located at client or some other site 4.4.1 4.5 Security Requirement <RID> The requirement description goes here. Portability / Migration Describe if there are any special requirements to port to other host machines or operating systems. For example: To take the system to higher version of operating system or different operating systems To take the system from single tier architecture to n tier architecture. This will be applicable when the client is going with a quick solution to demonstrate the system to potential customers with database, business logic, web servers all on one machine but further phases will be on distributed architecture. 4.5.1 4.6 Portability / Migration Requirement <RID> The requirement description goes here. Supportability This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities. 4.6.1 Supportability Requirement <RID> The requirement description goes here.

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 13 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

EXTERNAL INTERFACES
This section defines the interfaces that must be supported by the application. External Interfaces imply the system(s), data or application that is outside the current system boundary that require integration. For each of the interface, provide a brief description, type (online / batch) etc.

PROJECT VALUE STATEMENT

Provide an overall statement summarizing at the highest level, the unique value this project or application/product intends to fill in the marketplace. The following format may be used: For: Who: The <Product Name>: That: Unlike: Our Product: [Target customer] [Statement of the need or opportunity] Is a [product category] [Statement of key benefit; that is a compelling reason to buy] [Primary competitive alternative] [Statement of primary differentiation]

A project value statement communicates the intent of the application and the importance of the project to all concerned personnel.

ASSUMPTIONS AND DEPENDENCIES

List of all the assumption and dependencies should be detailed here. Any changes to these assumption and dependencies can have an impact on the system, which will be managed via the Change Request Procedure defined in the Requirements Management Process. Beside functional assumptions, these should also include any assumptions that are made on software, hardware, communication / network infrastructure.

APPENDIX
8.1 Business Rules Define general and specific business rules. Present information for a list of single or group of business rules. These rules are different for each sector or business (e.g. banking, health, government, etc.). Introduce any terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents.

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 14 of 15

Headstrong DAG

ENG-TEM-14 Business Requirements Document Document Version <x.y>

Template History
Version Release Date (dd-mmmyyyy) 01-Sep- 2008 07-Apr-2009 Author Description of Change Reviewed By Approved By

1.0 1.1

SE Task Force Aman Jain

'OnePAL' Unification. Formatting changes. TOC corrected

SEPG Review team SEPG Review team

SEPG SEPG

<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 15 of 15