Traffic management at MSTPL EMC

Project / Initiative / Innovation

Version V1.0

Dated 20.05.2024

<Lead>
TEMPLATE VERSION TRACKING
Version Release Date Template Owner* Changes Incorporated

1.0 06-Jul-2020 Vivek Gupte – Group IT Governance Initial Draft

3.0 09-Jul-2020 Vivek Gupte – Group IT Governance Merged Tech BRD to create common template

*For any changes / additions / deletions / modifications to the template, please connect with the template owner

Wednesday, April 9, 2025 1

BUSINESS REQUIREMENTS DOCUMENT TEMPLATE
To aid in the creation of a successfully complete BRD document, please adhere to the following guidelines

A requirement is a documented condition or capability to which the product, service, or system must conform in meeting project
objectives. Requirements management is a systematic approach to eliciting, organizing, and documenting the requirements of the
product, service, or system. The Business Requirements Definition document serves as the project baseline that explains, in business
terms, what is to be accomplished as a business outcome being delivered by implementing a technology solution.

Because requirements are dynamic, the BRD is a progressive document in that the objective is to record what is known at the time
and then build on it as the project progresses. It is from this document that the more specific design documentation (Functional
Purpose
Reqs. Specification) can be produced based on the needs of the project and any unique and/or complementary methodology.

The business requirement document (BRD) describes the high-level business needs whereas the Functional Requirement Document
(FRD) outlines the functions required to fulfill the business needs. BRD answers the questions what the business wants to do whereas
the FRD gives an answer to how it should be done. Whereas a business requirement states the “why” for a project, a functional
requirement outlines the “what”. Functional requirements are very detailed and provide information on how business needs and
goals will be delivered through a specific project/program.

Wednesday, April 9, 2025 2

 The objective of a business requirement document.

• To get an agreement among stakeholders

• Communicate to the IT/Tech/Analytics/CyberSec teams, the business needs, the customer needs, and what the solution
Objective need to do to satisfy business and customer outcomes.
• To determine the input to the next phase of project
• Describe the details of the needs of the customer and business that the solution intends to meet
• The BRD is also the mechanism by way we at Adani drive standardization of tools, platforms, solutions across the group.
The cost associated with the tools, platform proliferation on both licensing and as well as implementation teams add to
greater expense, training and quality issues

A business unit representative who has a thorough understanding of the business processes drafts the BRD and
is the owner of the BRD. The most critical component of a business requirement document is the scope of the
project/initiative/innovation along with the restriction and constraints. The scope comprises of three key things

Key Elements • What are the problems which the business wants to solve?
• What are the restrictions?
• Is it worth to invest the time and money required for the project?
• The Value proposition has to be approximate and signed off by the BU Owner/Leadership

Defining business requirements is mandatory required deliverable for all projects

Collecting requirements is not as straightforward as it may first appear. It can become challenging because requirements:

BRD Template • aren’t always obvious.

Completion • can come from many and varied sources
• need to be managed by cross-functional groups of people
• can be hard to express clearly in words
• can be expressed at different levels of detail

Wednesday, April 9, 2025 3

 For a project that is an enhancement to an existing product, service, or system, the project team reviews existing documentation;
therefore, the BRD tends to be briefer. However, a project that is developing a new product, service, or system would tend to
generate a longer and more detailed document.

1. Do not include the Template Guidelines in your final document. Enter the project information document contributors and
version control.
2. Complete the document utilizing suggested text where applicable. Note that the blue text is NOT to be included in your final
document. Its purpose is to either provide guidance for completing the document
3. Once changes are made to your document and you’re ready to finalize, ensure that you update your Table of Contents (TOC)
section.
4. Route the document for review and approval to those individuals identified as per the process flow
5. Because the BRD is a dynamic document, once the Project Team obtains approval, the BRD is to be retained and modified as
necessary to record any additional, changed, or cancelled requirements.
6. If changes are to be made, update the Revision History information accordingly.
7. The Business Requirements Definition document is to be retained with other project-related documentation and maintained in
accordance with the business line’s records retention policy.

This template is provided as a guideline to follow in producing the minimum basic information needed to successfully complete a
Empowerment
Business Requirements Definition document. Business Teams are empowered to use this template as needed to address any specific
& Scalability
requirements of the proposed project at hand. The amount of detail included in the template will depend on the size and complexity
of the project. Depending on project or business line needs, requirements can be added,

The primary ownership and responsibility of generating the Business Requirement Document is with the Business Unit,
Ownership • Section 3,4,5 of the document has to be written and owned by the business
• Section 6 is to be filled in by the appropriate BU Service Teams (IT/Tech/Analytics/CyberSecurity)
• Section 7,8,9 has to be filled up jointly by BU Owner and BU Service Teams

Wednesday, April 9, 2025 4

 TABLE OF CONTENTS

TEMPLATE VERSION TRACKING ............................................................................................................................................................................................................................................................. 1

1 DOCUMENT REVISIONS ................................................................................................................................................................................................................................................................ 6

2 DOCUMENT APPROVALS .............................................................................................................................................................................................................................................................. 7

3 BUSINESS REQUIREMENTS SUMMARY ......................................................................................................................................................................................................................................... 8

3.1 BUSINESS NEED AND WHY? ....................................................................................................................................................................................................................................................... 8

3.2 BUSINESS NEED BACKGROUND? .................................................................................................................................................................................................................................................. 8
3.3 PROBLEM STATEMENT: ............................................................................................................................................................................................................................................................. 9
3.4 BUSINESS VALUE DELIVERED ........................................................................................................................................................................................................... ERROR! BOOKMARK NOT DEFINED.

4 BUSINESS PROCESS ...................................................................................................................................................................................................................................................................... 9

4.1 PAIN AREAS OR OPPORTUNITY IN EXISTING OPERATIONAL PROCESS ..................................................................................................................................................................................................... 10

4.2 PAIN AREAS OR OPPORTUNITY IN EXISTING TECHNOLOGY / SYSTEMS ................................................................................................................................................................................................... 12
4.3 BUSINESS FUNCTIONALITY IMPACT ............................................................................................................................................................................................................................................. 12
4.4 BUSINESS PROCESS IMPACTED .................................................................................................................................................................................................................................................. 12
4.4.1 As-Is Business Process ............................................................................................................................................................................................................................................. 12
4.4.2 To-Be Business Process (New / Changes only) ........................................................................................................................................................................................................ 13

5 BUSINESS REQUIREMENTS ......................................................................................................................................................................................................................................................... 15

6 FUNCTIONAL REQUIREMENTS ................................................................................................................................................................................................................................................... 16

7 SOLUTION OVERVIEW – CLOUD FIRST APPROACH..................................................................................................................................................................................................................... 19

8 KEY CONSTRAINTS ...................................................................................................................................................................................................................................................................... 21

9 KEY ASSUMPTIONS ..................................................................................................................................................................................................................................................................... 22

10 MILESTONES PLANNED.......................................................................................................................................................................................................................................................... 23

11 DEFINITIONS & ACRONYMS................................................................................................................................................................................................................................................... 24

11.1 DEFINITIONS ......................................................................................................................................................................................................................................................................... 24

11.2 ACRONYMS .......................................................................................................................................................................................................................................................................... 24

Wednesday, April 9, 2025 5

1 Document Revisions

Date Version Number Document Changes

05/02/20xx 0.1 Initial Draft

Wednesday, April 9, 2025 6

2 Document Approvals

Role Name Title Signature Date

Business Owner Munish Goel

Business Analyst

Architect

BU IT Piyush Sheth / Nishant

Nigam

Group IT

Cyber Security

BU Tech

BU Analytics

Wednesday, April 9, 2025 7

3 Business Requirements Summary
3.1 Business Need and Why?

MSPTL EMC Mundra comprises of 24 units which includes operations, commissioning, and projects, which spreads out in the area of approx. 1000 acres.

It comprises of manufacturing units of Solar modules, Cells, Wafers, Glass, Frames, EVAs and Windmills. Operating on 24 hours basis in 3 shifts.

It’s the only commodity business Adani Group is operating. In terms of transportation, site receives more than 600 vehicles in 24 hours comprises of
transportation goods and passenger vehicles which is expected to increase to approx. 2500 vehicles in next 2 years.

Traffic management is one of the major challenges as site going to have huge movement of manpower which is approx. 25 K in next 2 years.

In view of ensuring the safe movement of pedestrian and vehicles inside EMC, it is important to have effective system to monitor real time movement of
vehicles which helps in having a control of the site traffic during emergency response and reducing the TAT.

MSTPL EMC have constraint of space pertaining material vehicles came for loading and unloading activities and which also need to be managed effectively to
ensure timely movement of vehicles without any major hassles.

3.2 Business Need Background?

At MSTPL EMC, we are going to have dispatch of more than 14 GW modules and approx. 3000 ODC movements of blade and nacelles per
annum. Along with movement of glass and other miscellaneous items from more than 24 units.
Same way, raw materials will also be received for manufacturing of these finished goods.
Site have limited roads to approach warehouses and dockyards. As business operations continues for 24 hours, business need to have smooth
movement of traffic which should be supportive and controllable during the course of emergency facilitating emergency services movement
like ambulance and fire.

Wednesday, April 9, 2025 8

3.3 Problem Statement:

a) There is no intermediate parking space which lead to congestion on road.

b) What are we risking if we do not address this business need?
i. Traffic jam and vehicle congestion
ii. Delay in prompt response.
iii. No real time monitoring of traffic movement within EMC cluster
iv. Vehicle management issues.
v. TAT monitoring

4 Business Process

Currently there is a manual process for managing the traffic at various stages like external parking yard, gate in process , manual
process of weighment, gate out etc withing EMC.

Below is current process of various stages.

External parking As-Is Process:

• Driver reports at Origin Location (External Parking).
• Driver gives details of the Vehicle and the information about the Consignment.
• Security checks the Documentation of Vehicle & Driver.
• Security will validate the Vehicle & Transporter with a Predefined Checklist
Plant Gate In As-Is Process:
• Vehicle Reports at the Plant Gate In from the External Parking.

Wednesday, April 9, 2025 9

 • Security checks the Documentation of Vehicle & Driver.
• Security will advise the Driver about next workstations pertaining to the logistics process flow.
Weighbridge As-Is Process:
• Vehicle reports to the weigh bridge to record the weight (Gross/ Tare) of the vehicle.
• Person at weighbridge guide the driver to place the vehicle for weighment.
• Record the entry into manual register & weighbridge software.
• Manually update the weighman into SAP
Loading / unloading As-Is Process:
• Vehicles reports at Loading / unloading Bay, as per the Bay availability.
• In case of different Product category, the Vehicle will move to other Loading Point.
• The Loading supervisor Loads the material based on the Picking list through DO.
Security Out and Gate Out As-Is Process:
• Security will check all the documents and Validate Gross & Net Weight, Consignee & Invoice, & Vehicle & Crew Image will
be captured details.
• Invoice is created by logistics and customs team
• Vehicle is gated out using ZVMS in SAP & the vehicle is moved out of the plant.

4.1 Pain areas or opportunity in existing operational process

[Describe in brief the current pain areas which the business faces due to the current process/system status quo

Wednesday, April 9, 2025 10

s

Wednesday, April 9, 2025 11

4.2 Pain areas or opportunity in existing technology / systems

[Describe in brief how the current pain areas which the business and or IT, Analytics’, Technology, Security teams face in being able to meet
business requirements]

4.3 Business Functionality Impact

[What type of impact will the Business see in implementing this new functionality or feature set]

a) Automation of the manual process

b) Yard Management with automated sequencing.
c) Channelize system for vehicles movement within EMC.
d) Visibility of traffic status (Commercial, personal vehicle etc.) at any given point of time
e) Emergency management during any critical situations within EMC.
f) Centralized & Automated Weighbridge operation.
g) Faster vehicle turnaround time

4.4 Business Process Impacted

4.4.1 As-Is Business Process

Process ID Scope/ Steps

PR1 Vehicle reports at external yard, driver reports to gate with documents

PR2 Security Checks vehicle & driver documents and fill the checklist manually via
TAB. Vehicle reports for gate-in process, security will check the vehicle
documents & guide him for next process

Wednesday, April 9, 2025 12

 PR3 Vehicle reports at Weighbridge for gross / tare weight, person guide drivers for
vehicle placement, capture weight of vehicle, record it manually in SAP /
weighbridge application

PR4 Vehicle reports to loading / unloading bay as per the bay availability & incase bay
is full, vehicle waits on any of the plant road which creates the congestion.

PR5 Vehicle reports at exit gate for gate-out, security person validates required gate-
out documents and allow to process for vehicle out.

4.4.2 To-Be Business Process (New / Changes only)

Process Scope/ Steps

ID
PR1 • Automatic Reporting of vehicle at Yard using RFID & ANPR Camera.
• Automatic vehicle fitness checklist validation using e-Parivahan / ULIP site.
• Automatic Vehicle parking slot management and next move allocation & announcement based on the
pre-defined workflow.
• Auto or Manual next move vehicle allocation process.
• Auto/Manual Information system to communicate the respective stakeholders on the Vehicle next move.
PR2 • All the goods vehicles across all the plants considering the Vehicle Gate IN & OUT digitized through one
platform.
• Provide detailed drill down hierarchy and sub process to manage the end-to-end Gate IN & OUT process
Integrated with SAP.
• Workflow and exception management process to manage Inbound and Outbound goods vehicle.
• Central Gate Traffic Control Dashboard along with the exception alerts management system.

Wednesday, April 9, 2025 13

 PR3 • Weighbridge becomes men less & automated.
• PA system will guide driver for vehicle placement based on sensors.
• Automatic weighment of vehicle & updation in system using integration.
PR4 • Dynamic checklist to verify proper loading / unloading.
• TAT monitoring for loading & unloading process.
• Queue management, which helps to avoid entering unnecessary vehicles entrance into plant until bay is
empty.
PR5 • Vehicle will be allowed by the system only if all processes in between are completed.
• Truck exit & Main Gate Exit will be done in tablet with image of seal/vehicle/document

Wednesday, April 9, 2025 14

5 Business Requirements

[The specific business requirements elicited from stakeholders should be listed, categorized by both priority and area of functionality to smooth
the process of reading them.]

The business requirements shall be prioritized as follows:

Value Priority Description

1 High This requirement is critical to the success of the project. The project will not be possible without this requirement.
2 Medium This requirement is somewhat important, as it provides some value but the project can proceed without it with
bare minimum.
3 Low This is a low priority requirement, or a “nice to have” feature, if time and cost allow it.
4 Future This requirement is out of scope for this project and has been included here for a possible future release.

Req# Priority Description Rationale Impacted Stakeholders

A new repository shall be created to Single repository simplifies Who are the stakeholders?
BRQ-001 1 house the name records and links to mgmt. of data across all BU
customer data Sties Site O&M, Central Engg….

BRQ-002 2

BRQ-003

Wednesday, April 9, 2025 15

6 Functional Requirements

[Document clear and unambiguous Functional requirements with reference to the Business Requirements documented in the previous section.
Capture all business scenarios that need to be catered to by a requirement solution. Also list all the validations required for each requirement]

Functional
Impacted
Req# Requireme Description Rationale
Stakeholders
nt

To have stable / reliable and scalable Yard Management system (application and Security Team
BRQ- hardware- RFID , ANPR, PA system, Tablet, 10 Line LED display) with auto queue
FR-1
001 management

Seamless integration with Operations systems: Integration between RFID Must Have Security Team
BRQ-
FR-2 (Hardware/Software), FASTAG (Govt NPCI Vehicle Vs RFID tag), business
002 operations applications (SAP) – no manual data entry between one system to
another system
BRQ- Automatically sequence and control vehicle movement to streamline the flow and Security Team
FR-3
003 reduce congestion in the parking yard and in the plant

Auto-logging of vehicle movement in system and generate exception alert in Security team
FR-4 case any compliance violation during checklist validation– enable faster
checklist processing
FR-5 Exception handling and Pro-active visibility of failure of any Security team
compliance/workflow
FR-6 Regular vehicle registration system – includes application, approvals, verification Security Team
and FASTag integration

Wednesday, April 9, 2025 16

 Functional
Impacted
Req# Requireme Description Rationale
Stakeholders
nt

Create and manage Database for Vehicle No. Vs RFId tag from FASTag database,
enable the same to be used for purpose like
FR-7 a. Gate automation Security team
b. Weighbridge automation
c. Vehicle tracking in plants & gate in/out volume information
FR-8 System should be configurable for real-time alerts like overstay, violations,
Congestion etc
Automated Men less Weighbridge Requirements Security Team
1. RFID system at Entry point triggering the Boom Barrier opening- permitting
FR-9 only approved trucks in plant
2. Vehicle Positioning & Driver Information & Truck Recognition Systems at
Weighbridges to position, Identify & Weigh the trucks
3. Update the gross / tare weight into system (integration with SAP)
Vehicle Recognition Systems at Loading & unload Bays to record the vehicle TAT Warehouse
FR-10 in plant. Centralized queue management from beginning (external parking yard)
till gate out.
Reporting Dashboard but not limited to Security
a. Real Time Vehicle visibility for each stage like Parking yard, Gate-in & gate- /Warehouse/Logist
out, Weighbridge, Loading / unloading stage etc. ics
b. Graphical map view for monitoring the inside the plant vehicle movement &
FR-11 tracking between all junctions.
c. Detailed drill-down of the any vehicle at any stage
d. Central Gate Traffic Control Dashboard along with the exception alerts
management system.
e. Any other as per requirement at the time of details BRD discussion or
implementation stage.

Wednesday, April 9, 2025 17

Wednesday, April 9, 2025 18
7 Solution Overview – Cloud First Approach

[At a high level how will this be solved. Will this be solved using the existing infrastructure, software and tools which we have inhouse,
will this be solved in putting a new platform, solution or will this be solved thru our existing teams in developing new functionality.
Briefly describe this]
• Provide real-time visibility of the vehicle movement inside the plant at a micro-level and macro-level to facilitate monitoring and
control.
• Automatically sequence and control vehicle movement to streamline the flow and reduce congestion in the parking yard and the
plant
• automate manual transactions at gates and weighbridges for faster stage updates and weighment transaction.
• Highlight deviations from defined benchmarks to relevant stakeholders to enable quick resolution and root cause analysis.
• Stage wise in-plant vehicle management and TAT, monitoring at Process, Stage, Between Stage.
• Realtime vehicle/driver verification from Vahan and Sarathi Portal to reduce administrative burden and ensuring regulatory
compliance.
• Multi channel notification mechanism to deal with exceptions on real time basis.
• End-to-end visibility of the vehicle and Placement Co- ordination between sales team, logistics team, security team, and other
stakeholders.

a) Cloud First Approach (The Solution should have a Cloud First Approach)
a. SaaS – The application is provided by partner as SaaS solution.
b) Existing Infrastructure being used for development (What solution components are being used?) → Not applicable since it’s SaaS
platform
c) New Infrastructure / Platform / Solution required → Not applicable since it’s SaaS platform

d) What Algorithms are being leveraged or used if it’s an Analytics Project? → Not Applicable
i. E.g. Vibration analysis with Fast Fourier Transformation, Multi Fragment Optimization, Constructive Heuristics
ii. E.g. Text and semantic algorithm, Static Routing algorithm, Priority Queue algorithm
e) Development / Implementation
i. SI (existing or new) – New SI along with existing SI ( IBM – for SAP integration)

Wednesday, April 9, 2025 19

 ii. In house Teams → BU IT , Security team, Warehouse & C&L team
iii. Duration → Approx 4 months post hardware delivery
iv. Cost → Under evaluation.

Wednesday, April 9, 2025 20

8 Key Constraints

• Identified Performance
i. Response time, Vehicle wait time, stage wise TAT
• Security
i. Data and functional access control requirements
ii. Confidentiality, integrity and availability requirements
iii. Speed, need of integrity, access for particular user group or locations, sensitive data
• Operational
i. Back-up, recovery of data, scheduling and executing of jobs.
ii. Provision of arrangements to support the system in live environment.
• Installation
i. Hardware installation and application implementation
ii. Contractual, regulatory and legal Obligations
• Procedural
i. Existing business practices to be followed along with new one.
• Flexibility
i. Scalability for future developments or changes
• Compatibility
ii. Particular technical environments or components currently in production on Adani platforms/solutions

Wednesday, April 9, 2025 21

9 Key Assumptions

Sr. No. Assumptions Comments

Wednesday, April 9, 2025 22

10 Milestones planned

Milestone Milestone Date

1 Gap Analysis dd-mm-yyyy
2 Workflows dd-mm-yyyy
3 Prototype dd-mm-yyyy
4 Pilot(s) dd-mm-yyyy
5 Deployment dd-mm-yyyy

Milestone Description
• Evaluate current business operations workflows
• Understand sources of data, accuracy and integrity of data, how data moves and how decisions are
1 Gap Analysis
made
• Workshops with key business and site operations leads

• Define new operational workflows to effectively fill gaps

2 Workflows
• Identification of required data sources for insights
• Prototype digital bridge buid and demo to business owner
3 Prototype
• Show early value of the business workflow
• Do pilots with identified 1-3 sites to validate the overall concept effectiveness at a medium
4 Pilot(s) scale
• Measure effectiveness, evaluate workflows, and identify enhancements
5 Deployment • Scale up to deploy across entire BU sites / entities

Wednesday, April 9, 2025 23

11 Definitions & Acronyms

11.1 Definitions

Keyword Definition
Cloud computing is a style of computing in which scalable and elastic IT- enabled capabilities are delivered as a service using
Cloud Computing
internet technologies
A data lake is a concept consisting of a collection of storage instances of various data assets. These assets are stored in a
Data Lake near-exact, or even exact copy of the source format and are in addition to the originating data stores, They are the basis
and core ingredient for a good digitization strategy
DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices
in the context of a system-oriented approach. DevOps emphasizes people (and culture), and it seeks to improve
DevOps
collaboration between operations and development teams. DevOps implementations utilize technology – especially
automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.

11.2 Acronyms

Acronym Explanation
IaaS Infrastructure as a Service
PaaS Infrastructure as a Service
SaaS Software as a Service

Wednesday, April 9, 2025 24