Business Requirements

Document (BRD)
Electronic Document Management System
September 2016
Draft Copy

Tecton Engineering and Construction LLC

1301-1310, Skytowers, Abu Dhabi

23/08/2016

EDMS
Document Changes

Version
Number

Date

0.1

BRD

Initial Draft

1 Document Revisions
2 Approvals
Role

Name

Title

Project Sponsor

Tecton
Engineering

Business Owner

Project
Documents

Project Manager

Sankar
Subramanian

CTA

System Architect

Marikannan

Systems
Engineer

Development
Lead

Tamilanban

Systems
Engineer

User Experience
Lead

Arul raj

Document
Controller

Quality Lead

Prashant
Sharma

QAQC Manager

Content Lead

Marikannan

System
Engineer

Signature

Date

EDMS

BRD

3 Introduction
3.1 Project Summary
3.1.1 Objectives

To create a system for EDMS, this will support the centralized management of
documents for all the projects.
Text Search for documents will be made available
Keep track of documents status on the go. Up to date information of where the
document stands in any point of time.
Completely customizable system which can be tailored for each and every project and
its need.
Version control and comments sections will be incorporated for cross discipline
communications

3.1.2 Background
The need for a good EDMS system is a requirement of the business itself. For EPC
projects, EDMS system will project the engineering progress and makes it easy for project
personals to retrieve data in case of necessary. The general problem with old excel
formats are its limitations in size and usability such as speed. When we implement the
system we propose here it will have a complete solution for all our EDMS needs.
3.1.2.1Business Drivers

Customers are looking for a fast, user friendly, completely flexible system according to
their project needs.
The main focus for developing this application is to provide a complete solution for
document management.

3.2 Project Scope

The scope of this project is to create an EDMS system compatible with all projects and
eliminate the use of excels for document register process. Also it will have the option to
search and comment right on the document interface. Along with that we will the option
to track the project status based on weightage of document and submissions.
3.2.1 In Scope Functionality
Create Projects
Create Users
Provide access to user for projects
o Project Specific number system, Project Specific Departments
Searching

EDMS

BRD

Commenting
Creating weightage to documents as required by project
Transmittal creation
o Create chronological numbering format with project specific
numbering system
o Revisions
o Area Code and few more codes as required by projects

3.2.2 Out of Scope Functionality

Directly importing mail to the system from client/customer.

3.3 System Perspective

Project specific requirements may vary from project to project and client to client and so
we have a develop a system that can be completely tailored according to the
project/client.
3.3.1 Assumptions

The user will be given training and documentation.

3.3.2 Constraints

Timeline for implementation will impact execution of project.

3.3.3 Risks

Backup and DB must be regular.

3.3.4 Issues

None

4 Business Process Overview

The below example explains the process which is being followed (As-Is) and the proposed
system (To-Be)

4.1 Current Business Process (As-Is)

The current process of Document control involves inputs from various disciplines and
involves a register that should be updated manually.

Document will be sent by the discipline engineer to Document controller

with document title and document date.

EDMS

BRD

Document number for the document will be decided by the document

numbering system document which is produced when the project is
awarded.
This document number system will vary from project to project and client
to client.
Document title along with the weightage will be decided in the initial
stage itself.
Once the document is received by the document controller, he will create
a transmittal.
The transmittal will be summary for the document details, it will contain
the necessary information for delivery to right discipline
Transmittal has a transmittal number which is chronological, document
names it contains, revision, class, disciplines, date and other
informations as required by project.
The transmittal along with the document will be submitted to the clients
document controller.
The Clients document controller will forward it to the concerned inside.
They will reply back with the Commented document and CRS, which
contains list of changes.

4.2 Proposed Business Process (To-Be)

1 Technical Lead searches repository
1. If widget is not found, user creates a new widget name record.
2. WINS validates that all fields have been completed.

EDMS
3. WINS confirms that no similar widgets exist
4. User confirms record to be created.

5.
6.
7.
8.
9.

1 User searches repository to locate existing widget description.

WINS displays record
User selects Edit to open and modify record
WINS validates all fields completed correctly
User confirms changes.
WINS confirms changes and updates Audit table.

BRD

EDMS

BRD

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 and tracking them. Include links to use case
documentation, and other key reference material as needed to make the requirements as complete and
understandable as possible. You may wish to incorporate the functional and non-functional requirements into
a traceability matrix that can be followed throughout the project.]
The requirements in this document are prioritized as follows:
Value

Rating

Description

Critical

This requirement is critical to the success of the project. The project will not be possible
without this requirement.

High

This requirement is high priority, but the project can be implemented at a bare minimum
without this requirement.

Medium

This requirement is somewhat important, as it provides some value but the project can
proceed without it.

Low

This is a low priority requirement, or a nice to have feature, if time and cost allow it.

Future

This requirement is out of scope for this project, and has been included here for a possible
future release.

5.1 Functional Requirements

Req#

Priority

General / Base Functionality

Description

Rationale

Use Case
Reference

Impacted
Stakeholder
s

EDMS

Req#

FR-G-001

FR-G-002

Priority

Description

A new Master Widget repository

shall be created to house the
name records and links to the
widget objects.

Single repository
simplifies management
of widget development
across 30+ global
development teams

A widget shall be defined in the

repository via a unique identifier
and name combination.

ID+Name eliminates
duplicate widget name
records

FR-G-003
FR-G-004
FR-G-005
Security Requirements

FR-S-001

Widget creation in the repository

shall be limited to users with
Team Lead or System
Administrator,

Reporting Requirements
FR-R-001

Rationale

The system shall generate a

weekly Report of Widget Name
Status Changes

BRD

Use Case
Reference

Impacted
Stakeholder
s
Development
teams
Infrastructure
engineers

EDMS

Req#

Priority

Description

Rationale

BRD

Use Case
Reference

Impacted
Stakeholder
s

Usability Requirements

FR-U-001

User interface for the WINS

repository shall be responsive,
allowing for proper display on
tablet, laptop, and desktop
devices.

Audit Requirements
FR-A-001

Any change to a widget name

record shall be appended with
user ID and date/time stamp.

5.2 Non-Functional Requirements

[Include technical and operational requirements that are not specific to a function. This typically includes
requirements such as processing time, concurrent users, availability, etc.]

ID
NFR-001

Requirement
The WINS repository shall accommodate up to 100 users concurrently.

EDMS

NFR-002
NFR-003
NFR-004
NFR-005

The WINS repository shall be designated at Level 2 for availability and SLA purposes.

BRD

EDMS

BRD

6 Appendices
6.1 List of Acronyms
[If needed, create a list of acronyms used throughout the BRD document to
aid in comprehension.]

6.2 Glossary of Terms

[If needed, identify and define any terms that may be unfamiliar to readers,
including terms that are unique to the organization, the technology to be
employed, or the standards in use.]

6.3 Related Documents

[Provide a list of documents or web pages, including links, which are
referenced in the BRD.]