Business Requirements Document / Date: [Publish Date]
S:\4every1\Project Management\PMO\HR Project Templates\3.1 Planning and Requirements OHR_business_requirements.docx
Business Requirements
1.Introduction
1.1Executive Summary
This is a working document, a definition of the business requirements resulting from an analysis of a business process. It will guide the implementation of a solution that meets those requirements. As such, it outlines what the solution will do but not how it will do it. To give feedback on this document, please contact the author.
State how the information was obtained (one-on-one interviews, conversations with sponsors, use-case workshop, etc)
Now, state the level of detail (high, moderate or low), whether the functional requirements are in the form of use cases or simple statements, and whether the intent is to build or buy the solution.
Next, describe the structure of the project.
Finally, give an overview of the business objectives of the project.
1.2Purpose of This Document
This document will guide the design and/or bid specification for the eventual solution. It is presented here to facilitate understanding and to create a coherent vision of the goals that will be achieved. It will also serve as the template for controlling the quality of the solution through testing and assurance.
1.3Objectives
In a bulleted list, state the business objectives that will be met by this solution. These are business objectives, such as reducing costs, growing market share, retaining customers, etc. Note that requirements such as availability, interoperability and usability are described below as supplementary requirements.
1.4Summary of Scope
Activities that are in scope:
This could be a condensed version of identified use cases. List what types of workflow will be considered, whether internal or external, related to certain job functions, etc.
Activities that are not in scope:
This should reflect any activities that were raised by sponsors or by end-users that are nice-to-have but have been deemed to be out-of-scope. It is here as an aid to understanding. Items here may be candidates to be addressed in future projects.
1.5Constraints
1.6Assumptions
1.7Dependencies
1.8Risks
1.9Project Team
Name / Role / Email Address2.Context Diagrams
Context diagrams relate the use cases to each other, describing the business process. They serve two important purposes: they quickly communicate the overall intent of the system in a manner that can be understood by end-users, sponsors and implementers. They also help to identify areas that may not be well understood that require more investigation. Depending on the nature of the system, state diagrams or process flow diagrams may be the better choice. There may be several distinct sets of use cases which may warrant multiple workflow diagrams.
3.Requirements Glossary
This section serves as a cross-reference for items that may be repeated within use cases. The purpose is to reduce duplication and aid in the recognition of redundant requirements, making the whole more well-defined and concise.
3.1Actors
Actors are the users and automated systems that interact with the described system. Estimate how many of each type of actor there will be; this will aid in estimating capacity requirements and load testing. Be sure to include support roles such as Administrator.
Actor / Description / Count3.2Conditions
These are used within the pre- and post- conditions within use cases. By using the glossary, they can be made to agree, making it easier to link the use cases into a process flow.
Condition / Description3.3Episodes
Episodes are smaller than use cases, and can be used as the building blocks of use cases. They are optional for smaller projects, but become critical in the design of large systems. Having them here helps the analyst to find use cases that may be redundant, or ones that may need to be re-factored.
Episode / Description3.4Defined Terms
This section includes abbreviations, technical terms, jargon and other words that may not be familiar to a non-subject matter expert.
Term / Definition4.Functional Requirements
Other words for use case are ‘scenario’ and ‘user story’. The measures of requirements quality are well-definedness, minimality and coherence.
4.1Example Simple Use Case
Summary
The <specific actor or actors> will trigger processing by <performing a specific action>, or will be able to <specific ability>. The system will <response>. <Another actor> will be able to …
Requirements
4.1.1The system will present a form with <specific fields> and will return <specific response> when the <actor> submits the form
4.2Example more formal use case
Summary
The <specific actor or actors> will trigger processing by <performing a specific action>, or will be able to <specific ability>. The system will <response>. <Another actor> will be able to …
Pre-conditions/Triggers
(mustaddto glossary)
The user must already be signed in
Post-conditions/Outcomes
(mustaddto glossary)
The widget will be labeled and boxed
Actors
(mustaddto glossary)
Colonel Mustard
Miss Scarlet
Steps
(mayaddto glossary as ‘episodes’, if they are to be reused)
Step / User Action / System Response1 / The use case begins when a service order is placed in the Field Technician’s queue, whether manually by the Dispatcher or automatically by the System. / The system sends a message to the Field Technician’s device that a service order is ready to be executed.
2 / The Field Technician reviews the service order, and clicks an on-screen button to acknowledge receipt. The Field Technician may only acknowledge the top service order in his/her queue, and may only have one acknowledged service order at a time. / The system updates the status of the service order to reflect that the technician has accepted it and is en route.
The service order is ‘locked’ to that Field Technician until manually reassigned or closed.
Alternative Flows
Requirements
4.2.1The system will present a form with <specific fields> and will return <specific response> when the <actor> submits the form
5.Supplementary Requirements
5.1Availability
5.1.1Work hours
The system must be active during the entire work day, from 7am until 7pm, Monday through Friday.
5.2Security
5.2.1 Auditing
System must keep of log of changes to personnel records and failed accesses
5.2.2Limited Access
System must allow restricting access to sensitive information (access controls), including SS numbers
5.2.3Security Group Access (read, write, correct, special handling)
5.2.4Authentication
System must uniquely authenticate each user of the system, preferably using existing AD facility
5.2.5Input Filtering
System must carefully filter user input to avoid SQL injection, buffer overflow and similar exploits
5.3Legal & Regulatory
5.3.1Personal Data
System must adhere to standards for storing and displaying personal data, including medical, pay and SS records
5.4Usability
5.5Performance
5.6Support
5.7Reporting
5.8Communication
5.9Reliability
5.10System
5.11Hardware
5.12Software
5.13Coding Changes
5.14Archive or removal of stale data
6.Data Requirements
In a data-intensive application, you may use this section to document all of the various data types that the application will need to manage
7.Screen Mockups
In an application with an extensive user interface, you may use this section to provide what you imagine that interface should look like. Be sure to validate this with the end-users. A validated interface provides a valuable tool for the implementer, and provides an easy way to get everyone on same page regarding the application.
Requirements have been thoroughly reviewed and approved by the project Sponsor and Project Manager
Sponsor: ______Date: ______
Project Manager: ______Date: ______
Page 1 of 53 Planning and Requirements OHR_business_requirements12/23/2014