##Business Requirements For <Project Name/Purpose>
Document Created: <Date>
Author: <Author>
Distribution: <Distribution List>
Document Revision History
| Revised By | Date | Comment |
|---|---|---|
| Initials or name | Date modified | Reason for revision |
| Initials or name | Date modified | Reason for revision |
| Initials or name | Date modified | Reason for revision |
| Initials or name | Date modified | Reason for revision |
##1. Introduction ###1.1. Document Purpose
The purpose of this document is to describe the business requirements of an application or software dependent process, completely, accurately and unambiguously in a jargon-free and technology agnostic manner. ###1.2. Intended Audience
The intended audience are business owners of the proposed system and staff engaged in the delivery of the system, either as developers or as users. This document should be readable by non-technical stakeholders. They must be able to verify that their business requirements have been documented here to their complete satisfaction and understanding.
###1.3. Project Background List here any information about the circumstances that gave rise to the project if they are helpful in explaining the project purpose.
###1.4. Purpose of the Business Requirements This section describes why the Business Requirements are being documented – as a framework of understanding and a means of extracting information for the purpose of evaluating risks, timelines, required resource etc.
###1.5. Business Goals/Objectives to be achieved This section describes the major goals/objectives to be achieved with the implementation of a system that satisfies the stated requirements.
###1.6. Stakeholders
Stakeholders are the individuals or groups who have a vested interest in this project and whose interests need to be considered throughout the project. This section lists the Stakeholders of the Application / Project for which these Business requirements are documented.
###1.7. Dependencies on existing systems
This section describes the dependencies between the Application for which these Business Requirements are written and the other existing applications/systems in the total business ecosystem.
###1.8. References List any references (preferably hyperlink or specify location(s)) to previous documents, meeting minutes, correspondence etc. that are related to these Business Requirements and relevant for its intended audience.
###1.9. Assumptions Describe any assumptions that were made prior to or during the Business Requirements gathering and documentation. ##2. Scope of the projects
Describe (preferably list) the business functionality that is in/out of scope for Implementation. Highlight functionality that has been de-scoped in the requirements gathering process, or ruled in at a late stage.
###2.1. In Scope Deliverables
###2.2. Out of Scope Deliverables
##3. Functional Requirements
This section describes the Functional requirements part of the Business Requirements. In classic Use Case methodology (UML), the Functional Requirements comprises Actor Profile Specification, Essential Use Case diagram and Essential Use Case specification in narrative.
###3.1. Actor Profiles Specification Describe all the Actors and their profiles within the context of the Business Requirements being documented. An Actor is a person, organization or an external system/sub-system/program that has interactions with the Application. Actors, by definition, are external to the system with which they are having interactions. Actors have goals that are achieved by Use Cases. Typically, Actors have behaviour and are represented by the roles they play in the Use Cases. An Actor stimulates the system by providing input and/or receiving something of measurable value from the system.
###3.2. Essential Use Case Diagram This section depicts the Business Requirements in the form of a Use Case diagram.
Examples and explanations can be found here: http://www.uml-diagrams.org/use-case-diagrams-examples.html
###3.3. Essential Use Case Specifications This section describes each Essential Use Case in narrative text form. A Use Case typically has one basic, or standard course of action (flow) and one or more alternate courses of actions. Use Case: <Number>
Use Case Name Unique name for this Use Case
Description Describe the Use Case
Actors An Actor specifies a role played by a user or any other system that interacts with the subject.
Business Rules List the business rules of Section 3.6 that this Use Case references. Mention only the Business rule Id here. Provide hyperlinks to the business rules of section 3.6.
Basic Flows Describe the basic, desired process flow Alternate Flows Describe any alternate flows that might occur from time to time Non-Functional Requirements List requirements that are not of the system but of the process as a whole. For example if an offline notification is needed.
Pre-Conditions What has to be in place for the process to begin
Post-Conditions The situation that should exist after the process has successfully completed
###3.4. Function Hierarchy Diagram This section depicts the Business Requirements in the form of Function Hierarchy Diagram (FHD). In the Oracle Designer approach, the Functional Requirements are decomposed into a number of Business Functions. If you are not using this methodology you do not need to include this section or the Function Definition Report below.
###3.5. Function Definition Report This section describes each Business Function in narrative text form. ###3.6. Business Rules List, number and describe the business rules applicable to the proposed system. Where the business rules are derived from multiple departmental groups you may enhance the coding of the rule Id to indicate source e.g. BRF#### for a rule from Finance as opposed to BRM#### for a rule from Marketing.
| Business Rule Id | Rule Name | Description | Source |
|---|---|---|---|
| BR#### | <Rule> | <Reason> | <Dept/person> |
Alternative Source examples:
- Policy manuals
- Strategic decision
- Contractual obligation
- Subject matter expert
- External Sources (govt regulation for example)
##4. Data Requirements
This section describes the Data requirements part of the Business Requirements. You may find it helpful to reference the information [here] (http://www.uml-diagrams.org/class-diagrams-examples.html) and [here] (http://creately.com/diagram-community/popular/t/erd), as well as other sources, before completing this section of the document.
###4.1. Data Architecture
This section describes the Data Architectural requirements part of the Business Requirements. You would normally complete the Domain Class Diagram if you are using UML (Use Cases) or the Entity Relationship Diagram if you are following the Oracle Designer approach, but rarely both.
####4.1.1. Domain Class Diagram This section depicts the Data Architecture in the form of Domain Class Diagram. In the Use Case approach, the conceptual data architecture (structural aspects) for the Business Requirements is modeled using Domain Class Diagram. The Domain Class Diagram is used to model the conceptual classes, its attributes (fields) and operations (methods) and also the interrelationships (association, composition, aggregation and generalization) between the classes. Domain model is a representation of real world conceptual classes, not of software components.
####4.1.2. Entity Relationship Diagram This section depicts the Data Architecture in the form of Entity Relationship Diagram (ERD). In the Oracle Designer approach, the conceptual data architecture (structural aspects) for the Business Requirements is modeled using Entity Relationship Diagram (ERD).
###4.2. Data Volumes This section describes the expected approximate Data volumes (initial volume and annual growth %) for each conceptual Class or Entity. You may need the support of a DBA for this.
###4.3. Data Conversion This section describes at a high-level any data conversion requirements, namely the system, data source and destination. For example: “User data will be pulled from the Active Directory System and converted to enhance the Peoplesoft HR user record.”
###4.4. Data Retention and Archiving This section states the time frame for online Data retention before archiving and also the archiving requirements (in particular try to cover how archived data will be recovered if needed and what the time frame for recovery will be).
###4.5. Security/Privacy Implications This section describes the sensitivity levels of each class of data. The following criteria are used in determining the sensitivity level of each conceptual class/entity.
• Non-sensitive information that would not reasonably be expected to cause injury (harm) if released to the public;
• Protected A: information that, if compromised, could reasonably be expected to cause injury (harm), e.g. loss of privacy;
• Protected B: information that, if compromised, could reasonably be expected to cause serious injury (harm), e.g. the conduct of a court proceeding would be adversely affected;
• Protected C: information that, if compromised, could reasonably be expected to cause extremely grave injury (harm), e.g. loss of life.
###4.6. Data Definition Reports This section describes the Data Architecture / definition in a report format.
####4.6.1. Domain Class Definition Report This section is applicable only to Use Case approach. This section describes Data Architecture / definition (Domain Class model) in narrative text form.
Class Name
Class Description
Initial Data Volume (approx.)
Annual Data growth rate (in approx. %) Attributes (fields) of the class Name in name/description pairs as shown below:
Name : <Attribute name> Description : <Attribute description>
####4.6.2. Entity Definition Report This section describes Data Architecture / definition (Entity Relationship model) in narrative.
Entity Name
Entity Description
Initial Data Volume (approx.)
Annual Data growth rate (in approx. %)
Attributes (fields) of the Entity in name/description pairs as shown below:
Name : <Attribute name> Description : <Attribute description>
##5. Non-Functional requirements This section describes the non-functional requirements part of the Business Requirements. A non-functional requirement is typically a special requirement that is not easily or naturally specified in the text of the Use Case’s or function’s event flow. Examples of non-functional requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements.
###5.1. Security Requirements This section describes the Security requirements part of the Business Requirements.
####5.1.1. Authentication This section describes the Authentication requirements part of the Business Requirements.
####5.1.2. Authorization and Access Controls This section describes the Authorization and Access Control requirements part of the Business Requirements at a high-level. Authorization is the process of determining if the person/group, once identified through the “Authentication process”, is permitted to have access to certain services.
###5.2. Availability Requirements This section describes the system availability requirements.
###5.3. Usability Requirements This section describes the system usability requirements. A usability requirement specifies how easy the system must be to use. Usability is a non-functional requirement, because in its essence it doesn't specify parts of the system functionality, but specifies only how that functionality is to be perceived by the user, for instance how easy it must be to learn and operate the system.
###5.4. System Help Requirements This section describes what kind of System Help features need to be built into the system.
###5.5. Performance Requirements This section describes system performance expectation levels (response times).
###5.6. Scalability Requirements This section describes how the system is expected to scale to new higher or lower levels. Both user and application scalability requirements are described here. Data scalability is not described here as it is already described in the “data volumes” section earlier.
####5.6.1. User Scalability How the system should scale as more and more users are added.
####5.6.2. Application Scalability How the system should scale to meet performance demands.
##6. Interface Requirements This section describes User and System Interface requirements for the proposed system.
###6.1. User Interface Requirements It may be helpful to reference screen and report designs in this section.
###6.2. System Interface Requirements Use this section to list all required APIs into and out of the system, note those that exist and can be leveraged separately from those that need to be built for the Application to meet the business requirements.
##7. Business/Technical Glossary List the business and technical terms used that might not be understood by all stakeholders and describe them in jargon-free narrative.