BA assignment (Karim Ashraf Nazmy)

Workflow Overview:

1. The application should handle the incoming LC (Letter of Credit) requests, including the data
and associated documentation.

2. The workflow should support the necessary approval process, where the request can be
either accepted or rejected.

3. The application should perform data validations based on the predefined set of entry data,
which may be fed from other systems.

4. At the end of the process, the approved request should be posted to the core banking
system.

Key Features:

1. LC Request Handling:

 Provide a user interface to capture the LC request data and allow users to upload the
associated documentation.

 Implement data validations to ensure the completeness and correctness of the input
fields.

 Allow users to save the request as a draft and return to it later.

2. Approval Workflow:

 Implement a multi-level approval process, where the request can be approved or

rejected by authorized personnel.

 Provide a dashboard or worklist to view and manage the pending approval requests.

 Implement notifications and alerts to inform the relevant stakeholders about the
status of the requests.

3. Data Validation:

 Integrate with the relevant systems (either database connections) to retrieve the
predefined set of entry data.

 Implement validation rules to check the consistency and accuracy of the data
entered by the users.
  Provide clear error messages and guidance to the users when validation failures
occur.

4. Core Banking Integration:

 Develop the necessary integration points to securely post the approved LC requests
to the core banking system.

 Ensure the data format and structure are compatible with the core banking system's
requirements.

 Implement error handling and retry mechanisms to handle any potential failures
during the integration process.

5. User Interface and Usability:

 Design a responsive and intuitive user interface that adheres to best practices for
web applications.

 Ensure the application is accessible and easy to navigate for users with different
levels of technical expertise.

6. Reporting and Analytics:

 Implement reporting capabilities to track the status of LC requests, including the

approval history and any rejections.

 Provide dashboards and visual analytics to help the trade finance department
monitor the performance and trends of the LC request process.

Technology Considerations:

 The front-end application can be built using a modern JavaScript framework like React,
Angular, or Vue.js, which will provide a robust and scalable solution.

 For the backend, you can consider using a server-side technology like Node.js, Java, or .NET,
depending on your organization's existing technology stack and preferences.

 Utilize a relational database like MySQL, or SQL Server to store the LC request data and the
approval workflow information.

 Implement secure communication protocols (e.g., HTTPS) and authentication mechanisms to

ensure the confidentiality and integrity of the data. (need to discuss with network team for
the configurations)
Questions and answers:
1- What is the potential questionnaire you can prepare before the meeting?

1. LC Request Handling:

 What are the key data points required to be captured in the LC request form?

 What types of documentation are typically associated with an LC request?

 How should the users be able to save and retrieve draft LC requests?

 What are the mandatory and optional fields in the LC request form?

2. Approval Workflow:

 Who are the authorized personnel involved in the approval process?

 What are the different approval levels or stages?

 What notification mechanisms should be in place to inform stakeholders about the

status of requests?

3. Data Validation:

 What are the predefined sets of entry data that need to be validated?

 What are the specific validation rules that need to be implemented?

 How should the application handle data validation failures and provide feedback to
users?

4. Core Banking Integration:

 What are the specific data points and format required by the core banking system for
the LC requests?

 What is the error occurred on LC application (trade finance) to integrate it with the
core banking?

 What security and authentication protocols should be used for the integration?

 How should the application handle error or failures during the integration process?

 What logging or auditing mechanisms are needed for the integration?

5. User Interface and Usability:

 What are the key user personas and their expected levels of technical expertise?
  What are the desired design guidelines and branding requirements for the
application?

 What accessibility standards or guidelines should be considered?

 What type of feedback or visual cues should be provided to users during the LC
request and approval process?

6. Reporting and Analytics:

 What are the key reporting requirements for the trade finance department?

 What types of analytics or dashboards would be most useful for monitoring the LC
request process?

 What data points or metrics should be captured and reported on?

 How should the reporting capabilities be integrated into the application?

Questions and answers:

2- How the process will look like?

From Business perspective and technical prospective

1. LC Request Submission:

 The user navigates to the LGs and LCs request form and enters the required data.

 The user can attach the necessary documentation associated with the LGs and LCs
request.

 The user has the option to save the request as a draft and return to it later.

2. Data Validation:

 The application validates the entered data against the predefined set of rules.

 If the data is valid, the request is saved as a draft or tanked till validation frame time
of the contract authorized.
  If the data is invalid, the application displays clear error messages to the user,
allowing them to correct the issues and resubmit the request or decline it if there is
an error occurred in the contract level.

3. Approval Workflow:

 Once the contract is saved as authorized, the authorization process is initiated.

 The application routes the request to the appropriate approvers based on the
defined approval hierarchy.

 Approvers can review the request and either approve or reject it.

4. Post to Core Banking:

 If the contract is approved, the application securely integrates with the core banking
system to post the LCs and LGs request data.

 The application should handle any errors or failures during the integration process
and provide appropriate feedback to the user.

5. Notification and Feedback:

 If the request is rejected, the application notifies the requester about the rejection
and the reason for it.

 Throughout the process, the application should provide clear feedback and visual
cues to the users about the status of their requests.

Questions and answers:

3- What are the documentations you need to prepare?

1. Functional Specification Document (FSD):

 This document will outline the detailed functional requirements for the LC request
handling and approval system.

 It will cover the following sections:

 System Overview: Provide a high-level description of the system and its

purpose.

 User Personas and Requirements: Identify the key user personas and their
specific needs for the system.
  Use Cases: Describe the various use cases and user interactions with the
system, such as submitting an LC request, tracking the approval process, and
integrating with the core banking system.

 Data Model: Define the data entities, attributes, and relationships required
to support the LC request handling process.

 Approval Workflow: Outline the approval hierarchy, decision-making logic,

and notification mechanisms.

 Integration Requirements: Specify the integration points, data formats, and

communication protocols with the core banking system.

 Security and Compliance: Outline the security measures, access controls,

and compliance requirements (e.g., data privacy, audit trails).

 Non-Functional Requirements: Capture the performance, scalability,

availability, and maintenance requirements for the system.

2. Technical Design Document (TDD):

 This document will provide the technical design and implementation details for the
LC request handling and approval system.

 It will include the following sections:

 System Architecture: Describe the overall system architecture, including the

various components, their interactions, and the technology stack.

 Security and Access Controls: Detail the security measures, authentication

mechanisms, and authorization policies.

 Deployment and Operations: Outline the deployment strategy, infrastructure

requirements, and operational procedures (e.g., monitoring, logging,
backup, and disaster recovery).

 Testing and Quality Assurance: Describe the testing approach, test cases, and
quality assurance processes.

3. User Manual and Training Materials:

 Develop a comprehensive user manual that provides step-by-step instructions for

using the LC request handling and approval system.

 Create training materials, such as video tutorials or interactive walkthroughs, to help

users understand the system's features and functionalities.

 Ensure the user documentation and training materials cover all the key user
personas and their specific use cases.
 4. Implementation Plan and Project Management Documents:

 Prepare a detailed project plan that outlines the development phases, milestones,
and timelines.

 Maintain project management documents, such as a risk register, issue log, and
status reports, to track the progress and address any challenges during the
implementation.

Questions and answers:

4- What are the sections needed in the BRD.

The key sections that should be included in the Business Requirements Document (BRD) for the LC
(Letter of Credit) request handling and approval system are:

1. Executive Summary:

 Provide a high-level overview of the project, including the business objectives, key
benefits, and the scope of the system.

2. Business Overview:

 Describe the organization's current business operations, processes, and challenges

related to LC request handling.

 Explain the rationale and strategic importance of automating the LC request handling
and approval process.

3. Functional Requirements:

 Outline the key functionalities that the system should provide, including:

 LC request submission and data capture

 Data validation and error handling

 Draft saving and retrieval

 Approval workflow and hierarchy

 Integration with the core banking system

  Notification and status tracking

 Reporting and analytics (if required)

4. Non-Functional Requirements:

 Specify the non-functional requirements, such as:

 Performance and scalability (e.g., response times, concurrent users)

 Security and access controls (e.g., authentication, authorization, data

encryption)

 Availability and reliability (e.g., uptime, disaster recovery)

 Usability and user experience (e.g., intuitive interface, accessibility)

 Compliance and regulatory requirements (e.g., data privacy, audit trails)

5. Integration and Interface Requirements:

 Describe the necessary integrations with the core banking system, including the data
exchange formats, communication protocols, and security measures.

 Identify any other external systems or services that need to be integrated with the LC
request handling system.

6. User Personas and User Stories:

 Identify the key user personas, such as LC request submitters, approvers, and
administrators.

7. Business Process and Workflow:

 Provide a detailed description of the current LC request handling process and the
proposed future state process.

 Include the approval workflow, decision-making logic, and exception handling

scenarios.

8. Data and Information Architecture:

 Define the data entities, attributes, and relationships required to support the LC
request handling process.

 Identify the data sources, data volumes, and data retention requirements.

9. Risks and Assumptions:

 Outline the potential risks, issues, and assumptions associated with the project.

 Propose mitigation strategies to address the identified risks.

 10. Project Scope and Constraints:

 Clearly define the scope of the project, including the in-scope and out-of-scope
functionalities.

 Identify any constraints, such as budget, timeline, or technical limitations, that may
impact the project.

Questions and answers:

5- Define any business rule supported with a business scenario.

Business Rule:
LC Request Approval Hierarchy

 All LC requests its preferred to be approved by a designated approver based on the request
amount and the approver's approval limit.

 Requests up to 100,000 EGP can be approved by a Branch Manager.

 Requests between 100,001 EGP and 500,000 EGP its preferred to be approved by a Regional
Manager.

 Requests above 500,000 EGP its preferred to be approved by the Head of Trade Finance.

Business Scenario:
Karim, a customer, submits an LC request for 300,000 EGP to finance a raw material shipment for his
manufacturing business. The request is received by the Branch Manager, who reviews the details and
verifies that the request is within the required parameters (e.g., customer credit standing, collateral,
and trade documentation).

Since the request amount of 300,000 EGP is between 100,001 EGP and 500,000 EGP, the Branch
Manager cannot approve the request directly. Instead, the request is automatically routed to the
Regional Manager for review and approval.

The Regional Manager logs into the LC request handling system, views the request details, and
validates the supporting documents. After careful consideration, the Regional Manager approves the
request, and the system triggers the necessary actions to process the LC and initiate the funds
transfer.

Once the LC is issued, the system sends a notification to John, the customer, informing him of the
successful approval and issuance of the LC. The system also updates the relevant records in the core
banking system to reflect the LC transaction.
Questions and answers:
6- Please support your answers with the tools/methods you used to do the requirements analysis
and grouping.

1. Document Analysis:

 Reviewed existing documents and policies related to the LC request handling

process, such as the Trade Finance operations manual, regulatory guidelines, and any
previous system documentation.

 Extracted relevant information to supplement the requirements gathered from the

interviews and workshops.

2. Use Case Modelling:

 Developed use case diagrams to model the interactions between the different user
personas (e.g., LC request submitters, approvers, administrators) and the system.

 Captured the primary and alternative flows for each use case, as well as the
associated pre-conditions, post-conditions, and business rules.

3. Requirements Grouping and Prioritization:

 Grouped the gathered requirements into logical categories, such as functional, non-
functional, integration, and user interface requirements.

 Prioritized the requirements based on factors like business value, technical

complexity, and dependencies using techniques like the MoSCoW method (Must
have, should have, could have, Won't have).

 Documented the requirements in a structured format, such as a Business

Requirements Document (BRD), to ensure clarity and traceability.