1 Create BRD for Loan Origination Process You are BA for an organization XYZ who have products for BPM (Business Process Management) and Document Management System to enable business process improvement for customer - AER Bank. AER Bank wants to automate their loan origination process. Create BRD for this project using the discussed BRD Template. Basic flow with stakeholder's role at each step S. No Stakeholder Work items Description Branch Officer Customer Customer visits branch and ask onboarding for loan and fills application for required product amount, tenure 2 Branch manager Proposal maker Credit Checks and application check 3 Credit recommender Underwriting See customer financial details and ability to pay loan based on credit score, salary and asset liabilities Credit approver Approval, Pricing Approves loan amount interest rate Loan processing Sanction Sanction loan and sanction officer letter, ask customer to sign document Loan processing Documentation ask customer to sign document officer digitally and upload all required documents as per the required loan Disbursement Officer Disbursement Final Loan disbursed to customer's account or in form of cheque Optional Field Investigation, As per type of loan or Valuation, Legal etc. requirement of bank Instructions: 1. You are expected to read about loan origination process on internet to write better BRD document. 2. Completion of each section is necessary to get full marks. 3. At least 9 user stories in "As a USER, I want............... so that ......" Format is required 4. User stories should be SMART 5. Writing user stories along with acceptance criterion and priority is mandatory 6. In case of any doubts, mail your queries to the trainer. Project Name Business Requirements Document BRD Version: Date: SX2 Table of Contents 4 Introduction 1.1 References 1.2 Business Requirements Index Gap Analysis 2.1 As-Is Process To-Be Process Strategy or project approach to be followed Product Overview 3.1 Solution Scope 3.2 Assumptions and Dependencies Requirements (Detailed) I Non-Functional Requirements 2.2 2.3 5. SX. Project Name Business Requirements Document BRD Version: Date: Business Requirements Document 1. Introduction The purpose of this document is to collect, analyze, and define high-level needs and features of the AP Exception Handling project. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the AP Exception Handling project fulfills these needs are detailed in the use-case and software requirements specifications. 1.1 References Type Name Source Input Non-artifact resource Non-artifact Tesource 1.2 Business Requirements Index Short Description ID BR001 BR002 Focus BR003 BROOS BR006 BR007 BR009 2.1 2. Gap Analysis As-ls Process Detail about as-is process and current shortcoming or what is reason to have this project. As-is process flow To-Be Process To be process and complete UML dingram or process flow or process modeling diagram. This is very important 2.2 2.3 Strategy or project approach to be followed 43 Product Overview 3.1 Solution Scope Scope of Project Editing Voice Project Name Business Requirements Document BRD Version: Date: Ideally, this will be represented as a set of high-level bullet points that correspond to high level requirements. Each bullet Requirement here will or should have a corresponding set of detailed Requirements elsewhere within or outside the document. As the name implies, Out of Scope sub-section explains what NOT will be delivered by this project, and (usually) why. This is important to manage expectations of your stakeholders (assumptions about scope are, as you will be aware, a major source of heartburn during implementation sign-off). On Agile projects, high level requirements usually correspond to Epics and the big User stories that make up these epics. For most non-project stakeholders, the Overview and Scope sections provide sufficient information about the project, so it is important to be both concise and precise at the same time. 3.2 Assumptions and Dependencies Type Description Assumption Dependency Deliverables Risks & D) Focus Requirements (Detailed) ID Requirement BROOI Write User Story, details and acceptance criterion BR002 Document the requirements that your Business Sponsor or Product Owner need to be delivered by this project/initiative. Requirements can be classified under several headers - the internet provides a variety of responses for the search string 'types of requirements. What we need is a standard format that you can use to document all requirements. A cookie cutter format for documenting requirements would be Index - can start from 1, 2, 3... for high level requirements and go on to 5.1, 5.2, 5.1.1, 5.1.2 and so on for lower level requirements. You can apply such numbering conventions to Agile user stories Title Description - brief description of the high-level requirement. Detailed Description - sell-explanatory. User stories in the form of 'As a customer, can... so that...'fit here. Owner - usually the Business Sponsor or the Product Owner. Can also be stakeholders like IT, Marketing, Legal, Compliance etc, depending on the requirement . 1 Create BRD for Loan Origination Process You are BA for an organization XYZ who have products for BPM (Business Process Management) and Document Management System to enable business process improvement for customer - AER Bank. AER Bank wants to automate their loan origination process. Create BRD for this project using the discussed BRD Template. Basic flow with stakeholder's role at each step S. No Stakeholder Work items Description Branch Officer Customer Customer visits branch and ask onboarding for loan and fills application for required product amount, tenure 2 Branch manager Proposal maker Credit Checks and application check 3 Credit recommender Underwriting See customer financial details and ability to pay loan based on credit score, salary and asset liabilities Credit approver Approval, Pricing Approves loan amount interest rate Loan processing Sanction Sanction loan and sanction officer letter, ask customer to sign document Loan processing Documentation ask customer to sign document officer digitally and upload all required documents as per the required loan Disbursement Officer Disbursement Final Loan disbursed to customer's account or in form of cheque Optional Field Investigation, As per type of loan or Valuation, Legal etc. requirement of bank Instructions: 1. You are expected to read about loan origination process on internet to write better BRD document. 2. Completion of each section is necessary to get full marks. 3. At least 9 user stories in "As a USER, I want............... so that ......" Format is required 4. User stories should be SMART 5. Writing user stories along with acceptance criterion and priority is mandatory 6. In case of any doubts, mail your queries to the trainer. Project Name Business Requirements Document BRD Version: Date: SX2 Table of Contents 4 Introduction 1.1 References 1.2 Business Requirements Index Gap Analysis 2.1 As-Is Process To-Be Process Strategy or project approach to be followed Product Overview 3.1 Solution Scope 3.2 Assumptions and Dependencies Requirements (Detailed) I Non-Functional Requirements 2.2 2.3 5. SX. Project Name Business Requirements Document BRD Version: Date: Business Requirements Document 1. Introduction The purpose of this document is to collect, analyze, and define high-level needs and features of the AP Exception Handling project. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the AP Exception Handling project fulfills these needs are detailed in the use-case and software requirements specifications. 1.1 References Type Name Source Input Non-artifact resource Non-artifact Tesource 1.2 Business Requirements Index Short Description ID BR001 BR002 Focus BR003 BROOS BR006 BR007 BR009 2.1 2. Gap Analysis As-ls Process Detail about as-is process and current shortcoming or what is reason to have this project. As-is process flow To-Be Process To be process and complete UML dingram or process flow or process modeling diagram. This is very important 2.2 2.3 Strategy or project approach to be followed 43 Product Overview 3.1 Solution Scope Scope of Project Editing Voice Project Name Business Requirements Document BRD Version: Date: Ideally, this will be represented as a set of high-level bullet points that correspond to high level requirements. Each bullet Requirement here will or should have a corresponding set of detailed Requirements elsewhere within or outside the document. As the name implies, Out of Scope sub-section explains what NOT will be delivered by this project, and (usually) why. This is important to manage expectations of your stakeholders (assumptions about scope are, as you will be aware, a major source of heartburn during implementation sign-off). On Agile projects, high level requirements usually correspond to Epics and the big User stories that make up these epics. For most non-project stakeholders, the Overview and Scope sections provide sufficient information about the project, so it is important to be both concise and precise at the same time. 3.2 Assumptions and Dependencies Type Description Assumption Dependency Deliverables Risks & D) Focus Requirements (Detailed) ID Requirement BROOI Write User Story, details and acceptance criterion BR002 Document the requirements that your Business Sponsor or Product Owner need to be delivered by this project/initiative. Requirements can be classified under several headers - the internet provides a variety of responses for the search string 'types of requirements. What we need is a standard format that you can use to document all requirements. A cookie cutter format for documenting requirements would be Index - can start from 1, 2, 3... for high level requirements and go on to 5.1, 5.2, 5.1.1, 5.1.2 and so on for lower level requirements. You can apply such numbering conventions to Agile user stories Title Description - brief description of the high-level requirement. Detailed Description - sell-explanatory. User stories in the form of 'As a customer, can... so that...'fit here. Owner - usually the Business Sponsor or the Product Owner. Can also be stakeholders like IT, Marketing, Legal, Compliance etc, depending on the requirement
