0% found this document useful (0 votes)
8 views

Business Requirement Specification (BRS) : Objective

Uploaded by

Sagar Wakde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Business Requirement Specification (BRS) : Objective

Uploaded by

Sagar Wakde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Business Requirement Specification (BRS)

Project Name: Payment Link - To Fetch Beneficiary Details

Initiating Group: Merchant Ecosystem: Payments Team

1. General Information

Objective:
Enable merchants to disburse funds even when they lack key recipient details such as
account number, IFSC code, etc. This reduces operational errors and enhances user
experience.

2. Detailed Information

2.1 Business Requirement

Brief:
The solution enables merchants to send a payment link to recipients to fetch essential
details like account number and IFSC code, allowing for accurate fund disbursement.
Proposed System Changes:
● Merchants request activation of the payment link service via APIGW and provide
necessary recipient and merchant details.
● The bank sends the payment link to the recipient.
● The recipient enters their details through the ICICI Eazypay page for validation and
processing.

User Journey:

1. Merchant submits a request to activate the service and shares a unique code.
2. Merchant provides recipient details and opts for validation before payment.
3. The payment link is sent to the recipient’s email or phone number.
4. The recipient enters their details, including a code, and confirms accuracy.
5. The bank verifies the provided code. If it matches, the payment is processed.
6. If the validation fails or the name does not match, the payment is rejected.

UI Requirements:

● OTP Page
● Field: OTP Code (numeric input)
● Button: Proceed (enabled after OTP entry)
● Error Handling: Invalid OTP message
● Information Page
● Fields: Full Name, Account Number, IFSC Code, VPA, Security Code
● Acknowledgment Checkbox (mandatory for submission)

Functional Requirements:

● OTP validation with timeouts and retry limits.


● Validation of recipient information against the provided data.
● Consent validation options for the merchant.

3. Reports

● Report Name: Payment Link Usage Report


● Frequency: Daily
● Selection Criteria: Merchant ID, Payment Link Status, Date Range
● Report Fields: Merchant ID, Link ID, Recipient Name, Status
(Pending/Completed/Failed), Timestamp

4. Benefits

1. Reduces manual errors in fund disbursements.


2. Enhances security with OTP and data validation.
3. Improves user experience by streamlining the payment process.

5. Priority

● Priority: Medium

6. Change and Comment Tracking Table

Change Comment

Section/Reference Requirement/Feature Observation Suggested Status ID

Validate
Integration with compatibility
existing systems with existing
General should be systems and
Objective Pending C001
Information validated for ensure
seamless API readiness of
compatibility. API for

payment link
functionality.

Unclear if
Specify if the
merchant vs.
Detailed code validation
Code Validation recipient code Open C002
Information is case-
validation is case-
sensitive.
sensitive.

Define fallback

No fallback steps steps to

for OTP timeout reinitiate the


Detailed
Fallback Process or multiple payment link Pending C003
Information
incorrect entries process in case

mentioned. of failure or

timeout.

Add

multilingual
Error messages for
error messages
User Interface (OTP OTP Validation and OTP invalidation In
(e.g., Hindi and C004
Page) Error Handling lack multilingual Progress
English) for
support.
clarity in error

situations.

Implement

Account number dynamic

input field lacks account

User Interface (Info Account Number dynamic length number length


Open C005
Page) Validation adjustment based validation

on bank based on the

standards. respective

bank's format.
Implement

OTP retries are logging for OTP

Functional not logged, which validation


OTP Retry Limit Open C006
Requirements can hinder failures to track

troubleshooting. patterns of

misuse.

Notify the

Merchant’s merchant in

consent for case of failed

recipient name
Functional
Validation Consent validation isn’t validation or Pending C007
Requirements
clearly defined in mismatched

terms of failure data, providing

scenarios. options to

override.

Include

Report does not additional

include details on metrics such as

Reports Payment Link Report OTP retries, retry count and Open C008

validation failures, validation

or other metrics. failures in the

report.

Quantify

benefits in

terms of

No specific cost or reduced failure

Benefits Quantified Impact time savings rates, Open C009

quantified. transaction

success rates,

and processing

efficiency.
Column Explanation

1. Section/Reference: The specific section or part of the document being referred to.
2. Requirement/Feature: The requirement being tracked or observed.
3. Observation: Issues, gaps, or suggestions noted during review.
4. Change Suggested: Proposed solutions or changes to address the observations.
5. Status: Current status of the suggestion or change (e.g., Pending, Open, In Progress,
Resolved).
6. Comment ID: Unique identifier to track each comment and suggestion.

You might also like