Documente Academic
Documente Profesional
Documente Cultură
Headstrong
CONTENT:
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
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
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
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
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...
<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
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
2.2.2
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.]
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]
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...
<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 7 of 15
Headstrong DAG
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
<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 9 of 15
Headstrong DAG
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
3.2
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
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
4.3.1 4.4
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
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.
A project value statement communicates the intent of the application and the importance of the project to all concerned personnel.
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
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
SEPG SEPG
<YYYY> Headstrong-Restricted Circulation <Project Name/Department Name> Template Version 1.1 Page 15 of 15