Вы находитесь на странице: 1из 13

CHANGE REQUEST AND BUSINESS

REQUIREMENT DOCUMENT

Version V1.0.1

Date: 29-June-2016
System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Contents

Part 1: Executive Summary.............................................................................................................................................3


Part 2: Purpose................................................................................................................................................................3
Part 3: Requiremnt Scope...............................................................................................................................................4
Part 4: Solution scope.....................................................................................................................................................8
Part 5: Nonfunctional Requirements: Solution Characteristics......................................................................................9
Part 6: Implementation Requirements: Transition Requirements.................................................................................10
Part 7: Testing scenarios...............................................................................................................................................11
Part 8: Approvals and costing.......................................................................................................................................11
Part 9: Glossary.............................................................................................................................................................12
Part 10: Appendixes......................................................................................................................................................12

Business Requirements Document Page 2 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Part 1: Executive Summary

Prepared by:      

Date submitted:      

Business HOD:      

Application HOD:      

Business Analyst:      

Application Name:      

JIRA ID Number:      

Last Edit: _______________ by __________

Comments: Note: Appendices (models and diagrams) should be completed when there is
value added as determined by the project and review teams.

Part 2: Purpose

 To gain agreement with stakeholders.

 To provide a foundation to communicate to a technology service provider what the solution needs to do to
satisfy the customer’s and business’ needs.

 To provide input into the next phase for this project.

 To describe what not how the customer/business needs will be met by the solution

Business Requirements Document Page 3 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Part 3: Requirement Scope

Section 3.1: Different Types of Requirements


Functional requirements can be derived only following elicitation and documentation of business and
user requirements. The distinctions between these different requirements levels are important.

S.No Requirement Type Requirement Remarks/Explanations

encompass all the restrictions, licenses, and laws


applicable to a product or business. They may be
1 Regulatory Requirements internal (driven by the company itself) or external
(driven by a government or other regulatory body),
and are usually nonnegotiable.

place the business at the center of focus and tie the


project to documented strategic, tactical, and
operational goals. If developing products or services
2 Business Requirements as part of the overall direction of the company,
product or service features need to be covered at a
high level in this section, then in detail under User
Requirements.

Business Requirements Document Page 4 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

place the user at the center of focus and describe—


with flowcharts, use case diagrams, use case scenarios,
and other process models—the TO-BE user
experience with the new system. In some cases,
3 User Requirements
especially where business processes are being
modified, it may also be necessary to document the
AS-IS state of user experience with the current
system.

place the proposed system at the center of focus and


provide a prioritized list of capabilities the system
4 Functional Requirements
must demonstrate in order to satisfy business and
user requirements.

refer to system characteristics that must be fulfilled


related to things like the user interface, access
security, availability, robustness, system failure,
5 Nonfunctional Requirements integration, migration, and documentation. As such,
they do not deal with the actual functionality of the
system, but nevertheless represent key project success
factors.

Implementation (Transition) describe requirements needed for the transition to


6 the new system but will not be needed once the
Requirements solution is in place.

refer to system characteristics that must be fulfilled


related to things like the user interface, access
security, availability, robustness, system failure,
5 Nonfunctional Requirements integration, migration, and documentation. As such,
they do not deal with the actual functionality of the
system, but nevertheless represent key project success
factors.

Implementation (Transition) describe requirements needed for the transition to the


6 new system but will not be needed once the solution is
Requirements in place.

Business Requirements Document Page 5 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Section 3.2: Mandatory questions


Please answer the following questions for this change request:

1. Does this change impact new business?

A. Yes/No

2. Does this change impact renewal?

A. Yes/No

3. Does this impact claim processing in any way?

A. Yes/No

4. Does this change impact Agents or any functionality related to agency?

A. Yes/No

5. Is this change only for branches, or also for the customer portal?

A. Yes/No

6. Can we manually take care of this process? If yes, how?

A. Yes/No

7. Will cost center/Business will bear the cost of this change request?

A. Yes/No, [if Yes please mention department name along HOD]

Section 3.3: Intended Audience


In priority order, the main reviewers of this document are as follows:-

1. Impacted/Functionality using user :


2. No. & Type of users use the functionality:
3. Functionality impact on:
4. Stakeholders:

Business Requirements Document Page 6 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Section 3.4: Analysis Approach

A. Impact on other systems

*To be filled by RHICL business analyst


*This section should define any impact that this change request has on other systems in Religare’s
ecosystem.
The following questions need to be Mandatorily answered are as follows:-

SL.NO Application Impact Impact Description


Description
1 This change request has an impact Yes/No
on Eximius
2 This change request has an impact Yes/No
on Propero
3 This change request has an impact Yes/No
on Faveo
4 This change request has an impact Yes/No
on the customer portal
5 This change request has an impact Yes/No
on the CRM system
6 This change request has an impact Yes/No
on Cordys
7 This change request will need new Yes/No
we services or changes in existing
services
8 This change request impacts both Yes/No
new business and renewals
9 This change request impacts the Yes/No
current products or product setup

Business Requirements Document Page 7 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Part 4: Solution Scope

Restate, in summary form, the project vision and scope statements from prior project documentation
to reconfirm the understanding of project objectives, and allow for clarification of those statements
that may be required due to the passage of time. Should scope have changed, previous project
activities must be reopened because the reality represented by the official documentation and the
signatures they contain are no longer valid.Section 4.1: Summary of Regulatory, Business, and User
Requirements
All project initiatives consumer organizational resources and must be tied to regulatory, strategic,
tactical, and operational goals. If the business goals or their relative priorities change during the
project, your project’s goals and priorities will likewise change.

Section 4.2: Assumptions, Dependencies, and Constraints


In this part, document that which cannot be ascertained in advance.

Assumptions
Ex. Resources, time frame, and cost

Dependencies
Ex. Other projects such as the availability of project resources, applications and systems that interact
with this one, hardware, facilities, equipment, business processes, regulatory approvals, the availability
of project stakeholders and users, and conformance to approval and change management processes

Infrastructure Requirement/Expected changes:


Ex. Regulatory, technological, or business realities that legitimately constrain solution development

1- New Setup/App Release : Refer Annexure -1

2- Existing Setup/Enhancement : Refer Annexure - 2

Constraints
Ex. Regulatory, technological, or business realities that legitimately constrain solution development

Business Requirements Document Page 8 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Section 4.3: Business Rules:


*To be filled by RHICL business analyst.
*This section will capture all the business rules & logics related to the change request

BR # Business Rule

Part 5: Nonfunctional Requirements: Solution Characteristics


Document characteristics of the solution not directly related to the functionality of the proposed system. Clear,
quantitative definitions of these requirements feed the project’s quality plan.

Business Requirements Document Page 9 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Section 5.1: User Interface Requirements

Section 5.2: User Access/Security Requirements

Section 5.3: Business Continuity and Recovery Requirements

Section 5.4: Integration/Migration Requirements

Section 5.5: Administrative/Backup/Archive Requirements

Section 5.6: Documentation Requirements

Section 5.7: Training Requirements

Business Requirements Document Page 10 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Part 6: Implementation Requirements: Transition Requirements


Documents characteristics of the solution not directly related to the functionality of the proposed system but
needed to facilitate the implementation of the solution: these requirements are temporary, transition-specific
requirements and will not be needed once the solution is in place.

Section 6.1: Requirements for the Generation of Production Data

Section 6.2: Requirements for the Conversion and Migration of Production Data

Section 6.3: Other Implementation Requirements

Part 7: Testing Scenarios:


Here Requestor will confirm the expected Testing Scenario to be covered up:

S.No Test Item Expected Result

In ongoing above scenario, test cases expected to be covered as per Business analyst:

S.No Test Item Expected Result

Business Requirements Document Page 11 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Part 8: Approvals & Costing:

1- Expected Cost indulged in CR : _______ Dated __________

2- CR Business Approval HOD : _______ Dated __________

3- CR Application Approval HOD : _______ Dated __________

Part 9: Glossary
Identify any industry or line of business jargon, acronyms, common words used in special context, and special
terms that are used within the project and the business requirements document itself.

Part 10: Appendixes


Annexure 1:

Annexure-1-Serve
r Prerequisite Form_Version_V1.2.docx

Annexure 2:

Annexure-2-Infra
Prerequisite Form_Version_V1.0.docx

Business Requirements Document Page 12 of 11


System Name: __________________Date: ________ Requester: ___________ BA:_________ JIRA ID: _____

Dependent CR matrix
<If the CR cuts across applications, CR raised for other applications need to be made available here>

Test scenario matrix


<Clearly highlight how a business rule is to be tested using a test scenario and map it back>

Attachments and Screen shots if applicable


<This section will contain any attachments and screen shots to supplement the CR>

Mail Content
<This section will contain all the emails sent across for discussion on this CR. This should not be used as an
information repository but only for tracking purpose>

Business Requirements Document Page 13 of 11

Вам также может понравиться