• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Business Requirements Document (BRD)
 

Business Requirements Document (BRD)

on

  • 18,487 views

 

Statistics

Views

Total Views
18,487
Views on SlideShare
18,486
Embed Views
1

Actions

Likes
5
Downloads
722
Comments
1

1 Embed 1

http://www.abapsap.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Business Requirements Document (BRD) Business Requirements Document (BRD) Document Transcript

    • University of Edinburgh _______________________________________________________________________________________________________ Stage: Business Analysis Business Requirements Document [PROJECT NAME] [PROGRAMME NAME] [PROJECT CODE] [ANNUAL PLAN NUMBER] Document Version: [x.x] Date: [dd/mm/yy] _______________________________________________________________________________________________________ Information Services - Template Revised June 2009
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ Contents 1 DOCUMENT MANAGEMENT........................................................................3 1.1 Contributors...........................................................................................................3 1.2 Version Control......................................................................................................3 2 OVERVIEW.....................................................................................................4 2.1 Project Description.................................................................................................4 2.2 Objectives................................................................................................................4 2.3 Business Dependencies and Constraints..............................................................4 2.4 Legislative Impact..................................................................................................4 3 CURRENT PROCESSES...............................................................................5 3.1 Business Process Description ...............................................................................5 3.2 Business Process Maps...........................................................................................5 3.3 Targeted Business Processes.................................................................................5 3.4 Current System Context Diagram........................................................................6 4 BUSINESS REQUIREMENTS.......................................................................7 4.1 Functional Requirements......................................................................................7 4.2 Non-Functional Requirements..............................................................................8 5 PROPOSED PROCESSES..........................................................................11 5.1 Business Process Description .............................................................................11 5.2 Business Process Maps.........................................................................................11 5.3 Proposed System Context Diagram ...................................................................11 6 DATA REQUIREMENTS.............................................................................12 7 USER ACCEPTANCE TESTING.................................................................13 7.1 Acceptance Test Strategy....................................................................................13 7.2 Test Scenarios and Acceptance Criteria............................................................13 8 TRAINING.....................................................................................................14 9 DOCUMENT SIGN OFF...............................................................................14 _______________________________________________________________________________________________________ Page 2 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 1 Document Management When completing this document, please mark any section that is not required as ‘N/A’. A brief description of why the section is not required should also be included. 1.1 Contributors Please provide details of all contributors to this document. Role Unit Name Business Analyst (Owner) Project Manager Project Sponsor Business Area Manager Systems Analyst Designer Other document contributors 1.2 Version Control Please document all changes made to this document since initial distribution. Date Version Author Section Amendment _______________________________________________________________________________________________________ Page 3 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 2 OVERVIEW Please provide an overview of the project in the sections below 2.1 Project Description Provide a summary of the project 2.2 Objectives As identified at TOR stage 2.3 Business Dependencies and Constraints Certain business dependencies exist that may affect the project team's ability to implement the project, e.g. concurrent projects, unknown technology. These dependencies are listed below so that they can be communicated and addressed. • [Add a dependency here.] • Please ensure that any potential risks are identified in the project Risk Register. 2.4 Legislative Impact Please highlight any legislative issues that could impact this project, including: • Data Protection • Freedom of Information • Records Management • SENDA Compliance • Disability Please ensure that any potential risks are identified in the project Risk Register. _______________________________________________________________________________________________________ Page 4 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 3 CURRENT PROCESSES This section provides details of the current processes – a process is defined as a serious of actions, operations, or functions that produces the required outputs. Current processes should be mapped, even where process is manual. 3.1 Business Process Description Please provide a description of the current business processes 3.2 Business Process Maps Use Triaster, or an alternative business process mapping tool, to map the activities and identify inputs and deliverables for the current business process. The current business process flow diagram describes the current process accurately, including any flaws, or short comings that exist in today's process that will be targeted for repair or improvement by the future process Individual business processes should be mapped separately. If required, provide an index of process maps. Add in links to: Html version of process maps – sample PDF printable version of process maps – sample 3.3 Targeted Business Processes Annotate targeted areas (areas which require change) in the process maps, and document these in full below. _______________________________________________________________________________________________________ Page 5 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 3.4 Current System Context Diagram The information in the current business system flows from and to other systems. The following diagrams represent the high level context for the information flow between the current system and external entities. Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif _______________________________________________________________________________________________________ Page 6 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 4 BUSINESS REQUIREMENTS 4.1 Functional Requirements Review the current process maps and targeted processes with the customer to identify the business requirements for the new development. Specifying technical solutions should be avoided unless these are an agreed constraint on the solution. Technical specifications will be detailed during the Design Stage. Record the agreed business requirements below: • Separate requirements into sections e.g. by functional area • Uniquely identify each requirement • Describe each requirement in sufficient detail to enable verification by the business user, definition of acceptance criteria and cross-referencing during the Design stage. • Specify the category for each requirement, using the following abbreviations: M = mandatory; HD = highly desirable; D = desirable For example: 1 Capture HR data for current HESA return ID Requirement Categor y 1.1 Facility to capture current version of Finance hierarchy M 1.2 Automatic facility to load Finance hierarchy into HR core system HD 1.3 Ability to validate HESA specific data in Core HR system M 1.4 Ability to report against extract tables M 2 Archive data from final HR HESA submission ID Requirement Categor y 2.1 Archive of each years submission must be captured and stored M 2.2 Ability to report against archive HD _______________________________________________________________________________________________________ Page 7 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 4.2 Non-Functional Requirements Identify and record requirements for aspects of the solution other than those explicitly concerning its functionality. Examples of non functional requirements will include those relating to security, scalability, performance, backup and recovery, extensibility, portability etc. Record the agreed non-functional requirements below: • Separate requirements into sections • Uniquely identify each requirement • Describe each requirement in sufficient detail to enable verification by the business user, definition of acceptance criteria and cross-referencing during the Design stage. • Specify the category for each requirement, using the following abbreviations: M = mandatory; HD = highly desirable; D = desirable For example: Security Ref Security Requirement Categor y 1.1 Authentication EASE Authentication to be used M 1.3 Authorisation Admin – read/write access to application’s M Levels administrative functionality and to all data Owner – read/write access to all data functionality but no admin permission User – view-only access to application data; no access to sensitive data (as defined above) Scalability Ref Scalability Requirement Categor y 2.1 Typical and M Maximum number of concurrent users 2.2 Expected annual M user growth 2.3 Expected initial and maximum data volumes 2.4 Expected annual data growth Performance Ref Performance Requirement Categor y 3.1 e.g Page render times 5 sec M 3.2 e.g Report run times 30 sec HD _______________________________________________________________________________________________________ Page 8 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ _______________________________________________________________________________________________________ Page 9 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ Availability/Business Continuity Ref Availability/Business Requirement Categor Continuity y 4.1 The solution should be designed 99.9% availability excluding HD to be highly available during planned maintenance during normal working ours 8am – 6pm 4.2 In the event of a failure the Recovery in less than 1 working HD system must be designed to be day from time of failure with no recoverable in less than 1 loss of completed transactional working day with minimal data data loss Back Up/Archive Please highlight any archive and back up requirements. For example: Ref Backup/Archive Requirement Categor y 5.1 Full database archive Annual snapshot on 31st July M 5.2 Backup Nightly backup for Disaster HD Recovery Data Migration Please provide details of data migration requirements (if any), including timescales. For example: Ref Data Migration Requirement Categor y 6.1 Financial Transactions To be posted in real time to HD Finance System 6.2 Staff Data To be refreshed at least daily M from HR System Conformance with Browsers, Operating Systems and Mobile Devices Please provide details of the environment(s) in which the system is required to operate. For UoE systems only windows, mac and linux operating systems are supported. Ref Browser PC Mac IPhon Mobile Xbox / e /PDA PS3 7.1 IE 7.x M M HD -- 7.2 IE 6.x -- -- -- -- 7.3 IE 5.5 -- -- -- -- 7.4 Earlier IE Versions -- -- -- -- 7.5 Firefox all versions M M HD -- 7.6 Opera 8 onwards HD HD D -- 7.7 Safari 2 onwards HD HD D -- 7.8 Google Chrome 1.x -- -- -- -- 7.9 Other Browsers -- -- -- -- The current preferred browsers for University IT systems is published at: http://www.ucs.ed.ac.uk/ucsinfo/browsercompat.html _______________________________________________________________________________________________________ Page 10 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 5 PROPOSED PROCESSES This section provides details of the future processes – a process is defined as a series of actions, operations, or functions that produces the required outputs. 5.1 Business Process Description Please provide a description of the proposed business processes 5.2 Business Process Maps Taking into account the business requirements defined above, use Triaster, or an alternative business process mapping tool, to map activities and identify inputs and deliverables for the future business process. Individual business processes should be mapped separately. If required, provide an index of process maps. Add in links to: Html version of process maps PDF printable version of process maps 5.3 Proposed System Context Diagram The information in the current business system will flow from and to other systems. The following diagrams represent the high level context for the information flow between the proposed system and external entities. Sample diagram: http://hsc.csu.edu.au/ipt/project_work/3287/contextdiagram.gif _______________________________________________________________________________________________________ Page 11 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 6 DATA REQUIREMENTS Please include details of the data to be captured by the new software. This should be listed in the table below. If this is a substantial amount of information, please provide a high level summary in this section, and attach the details as an appendix. For example: Data Group Data required Source Customer Name Application form Date of birth Application form Gender Application form Nationality Application form Contract of Campus identifier HR system Employment Contract identifier HR System Terms of employment Core HR _______________________________________________________________________________________________________ Page 12 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 7 USER ACCEPTANCE TESTING Please highlight the UAT strategy identified for this project 7.1 Acceptance Test Strategy Provide an overview of the acceptance test strategy. Please ensure the following are included in your considerations: • Scheduling and duration • Test setup requirements (e.g. test environment, co-dependencies, business cycles) • Sources of test data • Test scripts • Required test participants and any training requirements • Technical and business support required during testing • Communication requirements Link to updated User Acceptance Test Plan 7.2 Test Scenarios and Acceptance Criteria Referring back to section 4, identify test scenarios and acceptance criteria for each functional and non functional requirement. Please note that this section will be used as sign off criteria for the User Acceptance Test Plan. Examples: 1 Capture HR data for current HESA return Re Requirement Test Scenario and Acceptance Criteria f 1.1 Facility to capture current Check current finance hierarchy appears in Core HR version of Finance’s hierarchy system 1.2 Automatic facility to load Current finance hierarchy appears without manual finance hierarchy into HR core intervention in Core HR system system 1.3 Ability to validate HESA Run validation report specific data in Core HR system 1.4 Ability to report against extract Generate report from tables tables 2 Archive data from final HR HESA submission Ref Requirement Test Scenario and Acceptance Criteria 2.1 Archive of each years Evidence, e.g. demonstration, that required data is submission must be captured correctly archived and stored 2.2 Ability to report against Generate report from archive archived data _______________________________________________________________________________________________________ Page 13 of 14
    • Business Analysis: Business Requirements Document [Project Name] [Version: x.x] _____________________________________________________________________________________________ 8 TRAINING Please provide details on training requirements, including… • Which groups will require training • Who will provide training • Required Format of training materials 9 Document Sign Off Please add other sign off roles where required: Project Manager Name Project Sponsor Name Business Analyst Name Systems Analyst Designer Name _______________________________________________________________________________________________________ Page 14 of 14