eng-tem-14 business requirements document

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.

FOR:

Headstrong

CONTENT:

Business Requirements Document TemplateENG-TEM-14

Version 1.1

07-Apr-2009

Headstrong DAG ENG-TEM-14Business 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

of 15



TABLE OF CONTENTS

1 INTRODUCTION............................................................................................................................... 5

1.1 Purpose................................................................................................................................. 5

1.2 Audience............................................................................................................................... 5

1.3 Scope.................................................................................................................................... 5

1.4 Acronyms and Definition.....................................................................................................5

2 OVERVIEW........................................................................................................................................ 6

2.1 Business Description...........................................................................................................6

2.2 Stakeholder Requests..........................................................................................................62.2.1 Establish Stakeholder Profile..............................................................................................62.2.2 Establish User or Customer Profile.....................................................................................72.2.3 Assess the Problem............................................................................................................72.2.4 Understanding the User Environment.................................................................................7

2.3 Process Schematic..............................................................................................................8

3 BUSINESS REQUIREMENTS.........................................................................................................10

3.1 Functional Requirement <RID>.........................................................................................103.1.1 Description........................................................................................................................ 103.1.2 Rationale.......................................................................................................................... 103.1.3 Source.............................................................................................................................. 103.1.4 Dependencies / Conflicts / Assumptions...........................................................................103.1.5 Priority.............................................................................................................................. 103.1.6 Verification........................................................................................................................ 103.1.7 High Level Use Cases......................................................................................................10

3.2 Functional Requirement <RID>.........................................................................................103.2.1 Description........................................................................................................................ 113.2.2 Rationale.......................................................................................................................... 113.2.3 Source.............................................................................................................................. 113.2.4 Dependencies / Conflicts / Assumptions...........................................................................113.2.5 Priority.............................................................................................................................. 113.2.6 Verification........................................................................................................................ 113.2.7 High Level Use Cases......................................................................................................11

3.3 Other Implicit Functionality...............................................................................................11

4 TECHNICAL REQUIREMENTS......................................................................................................12

4.1 Usability.............................................................................................................................. 124.1.1 Usability Requirement <RID>...........................................................................................12

4.2 Reliability............................................................................................................................ 124.2.1 Reliability Requirement <RID>.........................................................................................12

4.3 Performance....................................................................................................................... 124.3.1 Performance Requirement <RID>....................................................................................13

4.4 Security / Privacy...............................................................................................................134.4.1 Security Requirement <RID>............................................................................................13

4.5 Portability / Migration.........................................................................................................13


of 15



4.5.1 Portability / Migration Requirement <RID>.......................................................................13

4.6 Supportability..................................................................................................................... 134.6.1 Supportability Requirement <RID>...................................................................................13

5 EXTERNAL INTERFACES..............................................................................................................14

6 PROJECT VALUE STATEMENT....................................................................................................14

7 ASSUMPTIONS AND DEPENDENCIES.........................................................................................14

8 APPENDIX....................................................................................................................................... 14

8.1 Business Rules..................................................................................................................14

Template History........................................................................................................................................ 15


of 15



1 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 client’s 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 Purpose

OverviewProvides an overview of the objective and scope of the Business Requirements.

Business Requirements Defines the...Technical Requirements Defines the ...External Interfaces Defines the...Project Value Statement Provides...Assumptions and Dependencies

Defines the ...

Definition of Terms and Acronyms

Defines the ...

Business Rules Defines the...

1.4 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)


of 15



<Term 1> - <Definition>

<Term 2> - <Definition>

<ACRONYM> - <Definition>

2 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[Who is the stakeholder representative to the project? (Optional if documented elsewhere.) What we want here is names.]

Description [Brief description of the stakeholder type.]

Type[Qualify the stakeholders’ expertise, technical background, and degree of sophistication—that is, guru, business, expert, casual user, etc.]

Responsibilities[List the stakeholder’s key responsibilities with regards to the system being developed—that is, their interest as a stakeholder.]

Success Criteria[How does the stakeholder define success? How is the stakeholder rewarded?]

Involvement[How the stakeholder is involved in the project? Relate where possible to RUP workers—that is, Requirements Reviewer etc.]

Deliverables[Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system under development.]

Comments / Issues

[Problems that interfere with success and any other relevant information go here.]


of 15



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

[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.]

Description [A brief description of the customer type.]

Type[Qualify the customer’s expertise, technical background, and degree of sophistication—that is, guru, casual user, etc.]

Responsibilities[List the user’s key responsibilities with regards to the system being developed— that is, captures customer’s details, produces reports, coordinates work, etc.]

2.2.3 Assess the Problem

Provide a statement summarizing the problem being solved by this project. The following format may be used:

The Problem Of [Describe the problem]

Affects [The stakeholders affected by the problem]The Impact of Which is

[What is the impact of the problem]

A Successful Solution Would be

[List some key benefits of a successful solution]

2.2.4 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:

Examples

Operating Systems Used:

<Windows 95, Windows 98; Apple Mac>

Applications used similar to this to or to be used on top of it:

<e.g. E-mail storage systems (Lotus Notes, Microsoft Outlook)...etc>

OS planned for future:

Windows 2000

Specific applications that need to be interfaced with the system:

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

Documentation Requirements:

PDF on line, Hard copy Manuals


of 15



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.


of 15




of 15



3 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

Why is this requirement to be included?

3.1.3 Source

Where does the requirement come from? Is it a document, person, implied?

3.1.4 Dependencies / Conflicts / Assumptions

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 Priority

High, Medium, Low

3.1.6 Verification

Is any special verification or testing required for this functional requirement?

3.1.7 High Level Use Cases

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?)

3.2 Functional Requirement <RID>

Describe each requirement in the following format:


of 15



3.2.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.2.2 Rationale

Why is this requirement to be included?

3.2.3 Source

Where does the requirement come from? Is it a document, person, implied?

3.2.4 Dependencies / Conflicts / Assumptions

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 Priority

High, Medium, Low

3.2.6 Verification

Is any special verification or testing required for this functional requirement?

3.2.7 High Level Use Cases

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:

Actors

Actions

Artifacts

Acceptance Criteria (The x action needs to be completed in x seconds?)

3.3 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.


of 15



4 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 IBM’s CUA standards Microsoft’s 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 system’s usability requirements on other systems that the users know and like

4.1.1 Usability Requirement <RID>

The requirement description goes here.

4.2 Reliability

Requirements for reliability of the system should be specified here. For example:

Availability—specify 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?

Accuracy—specifies precision (resolution) and accuracy (by some known standard) that is required in the system’s output.

Maximum Bugs or Defect Rate—usually expressed in terms of bugs per thousand of lines of code (bugs/KLOC) or bugs per function-point (bugs/function point).

Bugs or Defect Rate—categorized 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 system’s functionality.

4.2.1 Reliability Requirement <RID>


4.3 Performance

The system’s 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.


of 15



4.3.1 Performance Requirement <RID>


4.4 Security / Privacy

The system’s 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 Security Requirement <RID>


4.5 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 Portability / Migration Requirement <RID>


4.6 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>



of 15



5 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.

6 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: [Target customer]Who: [Statement of the need or opportunity]The <Product Name>: Is a [product category]

That:[Statement of key benefit; that is a compelling reason to buy]

Unlike: [Primary competitive alternative]Our Product: [Statement of primary differentiation]

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

7 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.

8 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.


of 15



Template History

Version Release Date (dd-mmm-yyyy)

Author Description of Change

Reviewed By Approved By

1.0 01-Sep- 2008 SE Task

Force

'OnePAL' Unification. SEPG Review

team

SEPG

1.1 07-Apr-2009 Aman Jain Formatting changes.

TOC corrected

SEPG Review

team

SEPG


of 15

eng-tem-14 business requirements document

Documents

specifies measurable quantities

high level concept

requirements management process

business requirements document

implicit functionality

operating systems

testing required

7high level