Business Requirement Specification (BRS) : Objective
Business Requirement Specification (BRS) : Objective
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
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:
3. Reports
4. Benefits
5. Priority
● Priority: Medium
Change Comment
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
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
standards. respective
bank's format.
Implement
troubleshooting. patterns of
misuse.
Notify the
Merchant’s merchant in
recipient name
Functional
Validation Consent validation isn’t validation or Pending C007
Requirements
clearly defined in mismatched
scenarios. options to
override.
Include
Reports Payment Link Report OTP retries, retry count and Open C008
report.
Quantify
benefits in
terms of
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.