EPLC_Business Requirements Document.doc
DOC document 535 KB Posted
- Solicitation number
- FDA-SOL-11-1085941
About this file
EPLC Business Requirements Document
View the file
Other files
Show 40 more
Latest 50 of 56 listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Business Requirements Document
Food and Drug Administration
<Project Name & Release Version #> Enterprise Performance LifeCycle
BUSINESS REQUIREMENTS DOCUMENT
Document Version Number: <#.#> Document Version Date: <mm/dd/yyyy> Notes to the Author
[This document is a template of a Business Requirements document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.
Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.
Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.
Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.
When using this template, the following steps are recommended:
Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.
After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.
These actions must be done separately for any fields contained with the document’s Header and Footer.
Modify boilerplate text as appropriate for the specific project.
To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.
To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.
Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.
VERSION HISTORY
[Provide information on how the development and distribution of the Interface Control Document will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]
Version Number Implemented
By Revision
Date Approved
By Approval
Date Description of and
Reason for Change
| <Author name> |
| <mm/dd/yyyy> |
| <Project Manager name> |
| <mm/dd/yyyy> |
| <Description of change> |
Table of Contents
51.0 Introduction
51.1 Purpose
51.2 Intended Audience
52.0 Executive Summary
52.1 Project Overview and Background
52.2 Business Goals/Objectives to be achieved
52.3 Benefits/Rationale
62.4 Stakeholders
62.5 Project Dependencies
63.0 Assumptions and Constraints
74.0 Requirements Scope
74.1 In Scope
74.2 Out of Scope
85.0 Functional Requirements
85.1 Actor Profiles Specification
85.2 Essential Use Case Diagram
85.3 Essential Use Case Specifications
85.4 Use Case Narrative
106.0 Data Requirements
106.1 Data Architecture
106.2 Data Volumes
106.3 Data Conversion
106.4 Data Retention and Archiving
106.5 Privacy Implications
107.0 Non-Functional requirements
117.1 Security Requirements
117.2 Authentication
117.3 Authorization and Access Controls
127.4 Availability Requirements
137.5 Usability Requirements
137.6 System Help Requirements
137.7 Performance Requirements
147.8 Scalability Requirements
147.9 User Scalability
147.10 Application Scalability
148.0 Interface Requirements
148.1 User Interface Requirements
148.2 System Interface Requirements
159.0 Appendix A
159.1 Business Process Flows
159.2 As Is Diagrams
159.3 To Be Diagrams
1610.0 Appendix B
1610.1 Business Rules Catalog
1610.2 Use Case Narrative Instructions
1.0 Introduction
1.1 Purpose
The purpose of this document is to describe business requirements for <System Name> accurately and unambiguously in Technology-independent manner. All attempts have been made in using mostly business terminology and business language while describing the requirements in this document. Very minimal and commonly understood Technical terminology is used. Use case / Designer approach are used in modeling the business requirements in this document. [Delete the approach that is not applicable.]
1.2 Intended Audience
[Identify the intended audience for this document. ] The main intended audience for this document is the business owners of the <System Name>. Other audiences are <Audience 1>, <Audience 2>,….,<Audience n>, [This document should be readable by business owners of the proposed system. They must be able to verify that their business requirements have been documented here completely, accurately and unambiguously. Data Architects, Application Architects and Technical Architects would also find the information in this document useful when they need to design a solution that will address these business requirements.
Since the requirements are documented here in Technology-independent manner, the end-users of the system should be able to comprehend the requirements fairly easily from this document. ]
2.0 Executive Summary
2.1 Project Overview and Background
[The information can be taken from the Project Charter. This subsection provides details leading up to the project that explain why the project is being considered. This section describes if these Business Requirements are as a result of any previous meetings, correspondence, legislation etc. Discuss the following where appropriate: marketplace drivers, business drivers, and technology drivers.) Mention here briefly if these business requirements are as a result of any previous meetings, correspondence, legislations etc.
2.2 Business Goals/Objectives to be achieved
[This section describes the major goals/objectives to be achieved with the implementation of the Business Requirements.]
2.3 Benefits/Rationale
[This section describes the major benefits to be achieved with the implementation of the Business Requirements.]
2.4 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.]
The following comprises the internal and external stakeholders whose requirements are represented by this document.
Stakeholders
1.
2.
3.
2.5 Project Dependencies
[This section describes the dependencies between the Application for which these Business Requirements are written and the other existing applications/systems.]
3.0 Assumptions and Constraints
[List any assumptions and constraints the requirements are based on]
| # |
| Assumptions |
| # |
| Constraints |
4.0 Requirements Scope
[This section shows what business functionality is in scope and out of scope for Implementation. In Use case approach, the out of scope Use cases are indicated in a separate boundary box. ] Example:
Include an overall high-level Use case diagram indicating which use cases are out of scope for Implementation. Draw separate boundary boxes around “in scope” use cases and “out of scope” use cases. See the example below :
If Function Hierarchy Diagram (FHD) modeling is done using Oracle Designer for these Business Requirements instead of Use case modeling, then include an overall high-level Function Hierarchy diagram indicating which Functions are out of scope for Implementation. Please draw the “out of scope” Function boxes in grey color as shown in the example below :
4.1 In Scope
[List the use cases/business functions that are in scope. Mention the name and a brief 2-3 lines short description for each use case/business function that is in scope.]
4.2 Out of Scope
[List the use cases/business functions that are out of scope. Mention the name and a brief 2-3 lines short description for each use case/business function that is out of scope. ]
5.0 Functional Requirements
[This section describes the Functional requirements part of the Business Requirements. In Use case approach, the Functional Requirements comprises of Actor Profile Specification, Essential Use case diagram and Essential Use case specification in narrative text form. ]
5.1 Actor Profiles Specification
[All the Actors and their profiles within the context of the Business Requirements should be 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 behavior 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. ]
5.2 Essential Use Case Diagram
5.3 Essential Use Case Specifications
[This section is applicable only to Use case approach. This section depicts the Business Requirements in the form of Essential Use case diagram. In the Use case approach, the Functional Requirements are decomposed into a number of Essential Use cases. Essential use cases are of primary importance early in a project’s requirements/analysis phase. Their purpose is to document the business process that the Application must support without bias to technology and implementation.
This section is applicable only to Use case approach. This section describes each Essential Use case in narrative text form. A use case typically has one basic course of action and one or more alternate courses of actions. The basic course of action is the main start-to-finish path that the use case will follow, where as the alternate courses represent the infrequently used paths and exceptions, error conditions etc. The complete business logic of a use case such as basic course of action, alternate course of action, pre-condition, post-condition etc is not depicted in the Use case diagram. Rather they are documented in narrative style in use case specifications. ]
5.4 Use Case Narrative
[Each Use Case should be documented using this template. ]
Use Case ID:
Use Case Name:
Created By:
Last Updated By:
Date Created:
Date Last Updated:
Actors:
Description:
Preconditions:
Postconditions:
Normal Course:
Alternative Courses:
Exceptions:
Includes:
Priority:
Frequency of Use:
Business Rules
Special Requirements:
Assumptions:
Notes and Issues:
Use Case Graphic
Example of a completed use case:
| Use Case ID: |
| 1 |
| Use Case Name: |
| View Interactive Campus Map |
| Created By: |
| XXX |
| Last Updated By: |
| Date Created: |
| XX/XX/XXXX |
| Date Last Updated: |
| Actors: |
| User |
| Description: |
| Submit Online Loan Application – as a web browser accessed application. The user accesses the appropriate URL and interacts with the functionality made available. |
| Pre conditions: |
| Web browser opened, and accessed the URL. |
| Post conditions: |
| User navigates to the Loan application Form URL by selecting the Loan Application Form” button. |
| Normal Course: |
| 1. Open browser |
2. Navigate to the URL < URL >
3. Navigate to the Loan Application form.
| Alternative Courses: |
| None |
| Exceptions: |
| None |
Includes:
| Priority: |
| High |
| Frequency of Use: |
| Once per visit. |
| Business Rules |
| TBD… |
| Special Requirements: |
| · 24/7 access |
Assumptions:
Notes and Issues:
Use Case Graphic
6.0 Data Requirements
[This section describes the Data requirements part of the Business Requirements.]
6.1 Data Architecture
[This section describes the Data Architectural requirements part of the Business Requirements.]
6.2 Data Volumes
[This section describes the expected approximate Data volumes.
6.3 Data Conversion
[This section describes the high-level Data Conversion Requirements. ]
6.4 Data Retention and Archiving
[This section describes the Data retention (time frames for online Data retention before archiving) and also the archiving requirements. ]
6.5 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 in line with the Government Core Policy Manual).
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.]
7.0 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.
7.1 Security Requirements
[This section describes the Security requirements part of the Business Requirements.]
7.2 Authentication
[This section describes the Authentication requirements part of the Business Requirements. Authentication is the process of verifying the genuineness of claims that a person/group makes to establish identity/eligibility for access to services. In order to ascertain the Authentication requirements of the Application, it is required to analyze the type of transactions that different Use cases/Business Functions trigger within the Application. The following criteria is used in determining transaction types of each use case/function (in line with the Government Core Policy Manual) :] Level 0 : Anonymous transaction – triggers transactions that do not require or allow a person to be identified, or transactions which require protection of a person's identity. For example, access to online information about government programs or services or protecting a person's identity. Combining the transaction data with other data must not allow identification of a particular individual.
Level 1 : Pseudonymous transaction – triggers transactions that do not require a person to be identified but do require a means for further contact to deliver a product or service. For example, a note from someperson@internet.ca can not be readily translated into an individual’s name, but it may be sufficient to request information, to provide some services, or on-going follow up.
Level 2 : Identified transaction – triggers transactions that require that a person be specifically identified. The nature of the transaction may require confirmation of a person's identity (e.g., name, address, birth date, etc.) and/or data linking the person to a transaction (e.g., invoice number, personal health number, etc.).
Level 3 : Verified transaction – triggers transactions that require: the person to be specifically identified; verification of the integrity of the data exchanged and the exchange itself; and, the creation of sufficient evidence to indicate that the person agreed to be bound by the transaction. For example, a note signed with a digital certificate, audit trails and security logs may provide sufficient evidence that a specific person intended to conduct a transaction.
For more information on Government FOI/Privacy policies and guidelines, please refer to the Core Policy Manual at the following link on the MSD web site :
7.3 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. The Authorization and Access Control requirements are best described through a matrix.
Actor / Business Unit Name
| Conceptual Class / Business Entity Name |
| Type of Access Control needed on the Conceptual Class / Business Entity : |
C ( Create
R ( Read
U ( Update
D ( Delete
Please specify the Authorization and Access Control requirements between the various Actors/Business Units and the Domain Classes/Business Entities in the table below. Add more rows as necessary.
7.4 Availability Requirements
[This section describes the system availability requirements.] Please specify the availability requirements for each Use Case or Business Function in the table below. Add more rows as necessary. If all use cases / business functions (the system as a whole) have the same uniform availability requirements, then describe this in the space below and delete the table below.
| Use Case / Business Function Name |
| Availability Requirements |
- Regular work hours
- 24x7
- Any other (please describe)
7.5 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.]
7.6 System Help Requirements
[This section describes what kind of System Help features are needed to be built into the system. ] Please specify the Online/Offline Help requirements for each Use Case or Business Function in the table below. Add more rows as necessary. If all use cases / business functions (the system as a whole) have the same uniform Help requirements, then describe this in the space below and delete the table below.
| Use Case / Business Function Name |
| Help Requirements |
- Field level (online)
- Screen level (online)
- Help Printing Options
- Operations Manual (Offline)
- Any other (please describe)
7.7 Performance Requirements
[This section describes system performance expectation levels (response times).] Please specify the expected system response time (in seconds or minutes) for each Use Case or Business Function or a significant critical transaction within a use case/business function in the table below. Add more rows as necessary. If all use cases / business functions (the system as a whole) have the same uniform response time requirements, then describe this in the space below and delete the table below.
| Use Case Name / Business Function Name / Transaction description |
| Performance Requirements (response time) |
(in seconds or minutes)
7.8 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.]
7.9 User Scalability
7.10 Application Scalability
8.0 Interface Requirements
[This section describes User and System Interface requirements for the proposed system.]
8.1 User Interface Requirements
8.2 System Interface Requirements
9.0 Appendix A
9.1 Business Process Flows
<Describe the current existing process workflow using flow diagrams (i.e. Visio Flowcharts) and/or a detailed narrative.>
9.2 As Is Diagrams
<Insert As Is Diagrams here (if applicable)>
9.3 To Be Diagrams
<Insert To Be Diagrams here (if applicable)>
10.0 Appendix B
10.1 Business Rules Catalog
<Instructions: Use the following template for each business rule. >
| Business Rule Name: |
| <The name should give you a good idea about the topic of the business rule.> |
| Identifier |
| <Defines unique identifier.> EXAMPLE: BR1 |
| Description |
| <Defines the rule in detail.> EXAMPLE: “All employee labor is tracked, reported and billed in 15 minute increments.” |
| Example |
| <(Optional) An example of the rule> |
| Source |
| <Source of the rule. E.g. stakeholder> |
| Related Rules |
| <List of related rules, to support traceability> |
10.2 Use Case Narrative Instructions
<Instructions for completing the Use Case Narrative are included here. Remove these instructions from the completed Business Requirements Document>.
| Use Case Field Name |
| Definition |
Use Case ID
Give each use case a unique numeric identifier, in hierarchical form: X.Y. Related use cases can be grouped in the hierarchy. Functional requirements can be traced back to a labeled Use Case.
| Use Case Name |
| State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some examples: |
View part number information.
Manually mark hypertext source and establish link to target.
Place an order for a CD with the updated software version
| Created By |
| Include the name of the person who initially documented this Use Case. |
| Date Created |
| Enter the date on which the use case was initially documented |
| Date Last Updated |
| Enter the date on which the use case was most recently updated |
| Last Updated By |
| Include the name of the person who performed the most recent update to the use case description. |
| Actor |
| Enter the person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor(s) that will be performing this Use Case. |
| Description |
| Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the Use Case. |
| Preconditions |
| List any activities that must take place, or any conditions that must be true, before the Use Case can be started. Number each precondition. Examples: |
User’s identity has been authenticated.
User’s computer has sufficient free memory available to launch task
| Post conditions |
| Describe the state of the system at the conclusion of the use case execution. Number each post condition. Examples: |
Document contains only valid SGML tags.
Price of item in database has been updated with new value
| Normal Course |
| Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I <accomplish the task stated in the use case name>?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system. |
| Alternative Courses |
| Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example: X.Y.AC.1 |
| Exceptions |
| Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason. Number each exception using the Use Case ID as a prefix, followed by “EX” to indicate “Exception”. Example: X.Y.EX.1 |
| Includes |
| List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality. |
| Priority |
| Indicate the relative priority of implementing the functionality required to allow this use case to be executed. The priority scheme used must be the same as that used in the software requirements specification. |
| Frequency of Use |
| Estimate the number of times this Use Case will be performed by the actors per some appropriate unit of time. |
| Business Rules |
| List any business rules that influence this Use Case. |
| Special Requirements |
| Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes. |
| Assumptions |
| List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description. |
| Notes and Issues |
| List any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is. |
Version 1.0, 7/15/2011 Business Requirements Document
_1301895272.vsd text
Client
POC
FCA
Administrator
Legend
Accounting Services
Set Status
Check Cost Sheet
Finalize PM Fees
Resolve Cash Balance
Inactivate in PeopleSoft
Capitalize
Inputs
Outputs
EXAMPLE: Business Process Flow Diagram – Project Accounting Closeout
Tools/Process
Risk/Issues
Close Phase
Project Manager
Unifier Administrator
Project Accountant
= Reject
Record Asset(s)
- Status Change Request
Confirm Adjustments
Verify Inactive
Inactivate in P/S
Final Notice
- Status Change Request
- Unifier
Wait 30 Days
Initiate Closeout
Accept Action Item
=>$0
Reconcile
Yes
Enter Adjustments
Skip / Enter Adjustments
Corrective Action
Client Accountant
Reconcile Project
- Action Item
Send Action Item
Change Status
- Action Item Acknowledgment
- Unifier Report
- Starts 60 day cycle time each time
Enter Asset ID
Controls
- Unifier Open PA Closeout Action Item Report
- N/A
- Unifier Open PA Closeout Action Item Report
- Accept/Reject
Reports (3)
- Balance must be = or > $0
- Project Cost Sheet
- Comments fields
- Unifier/Reports
- P/S Umail
- PA makes changes and updates Unifier
- Pay Apps
- Invoice(s)
- Accounting Adjustments
- P/S/Unifier Journal entries
- P/S Excel S/S
- Cost Sheet
- Duel adjustments – P/S and Unifier
- Cost Sheet
- Balance must be = or > $0
- Unifier Cost and Funding Sheets
- List risks to successful completion
- P/S Asset ID
- P/S Asset ID in Unifier
- P/S
- Accounting Services Deprec List
- BPEL Request to inactivate CF1 value
- PeopleSoft
- No more financial trans actions in P/S
- PeopleSoft Reporting
= Possible Cycle Time Improvements
File details come from the government source that posted it. Updated .