software requirement specification requirement specification of electronic document management...

Software Requirement Specification

Of

Electronic Document Management System

For

Ministry of Communications and Information Technology, Islamic Republic of Afghanistan

By

Universal Software Corporation, USA &

Grail Consulting Services, India

System Requirement Specification USoft/Dev/RMP/RSD/02

Confidential to Universal Software Corporation QMS Template Version 2.0 of 43

Version History

Author Name Role Date of Preparation Signature Syed Rasheed Consultant 10-Feb-2010 Reviewer(s) Name Role Date of Review Signature Alka Bansal Consultant 12-Feb-2010 Approver Name Role Date of Approval Signature Chinmay Shah Project Manager 15-Feb-2010 Document Path Version Number Date of Release 1.0 19-Feb-2010

Revision History Version Number Date of Release Section/ Page #

Changed Details of Changes

1.0 15-Feb-2010 Baseline



Table of Contents 1. Client Background & Area of Operation 4

2. Overview of the existing system 4

3. Project (General) 10

4. User Awareness with respect to Computerization 11

5. Scope of Project 11

6. Description of Proposed system 12

7. System Interfaces (If any) 17

8. Data Migration Requirements 19

9. Assumptions & Dependencies 19

10. Functional Requirements 21

11. Forms/Reports/Screens/ Workflows 24

12. Context Diagram 32

13. Strategy 33

14. Acceptance Criteria 40

15. Delivery Specification 43

16. Annexure 43



1. Client Background & Area of Operation Ministry of communications and information technology is one of the core ministries of the

Islamic Republic of Afghanistan. The Ministry of Communications and Information Technology

(MCIT) is the specialized governmental body of Afghanistan in the Communications and IT sector,

established with the objective of implementing the Afghanistan Government policy in this sector.

The mission of the Ministry is to create solid grounds that will ensure the effective and

efficient development of the telecommunication sector and transition to the

Information Society in Afghanistan. Bringing Afghanistan to the Information Society is

a strategic objective for the MCIT.

MCIT aims to provide telecommunications and IT services through its advantageous

policy, transparent legal framework and considerable support to private sector to

invest in the sector and provide services. The goal of this is to ensure the provision of

possible best services with reasonable prices, expand and speed up the application of

the Telecoms and IT systems in socio-economic development of Afghanistan.

2. Overview of the existing system 2.1 Existing System Details

The current process is manual and the documents are being handled by the staff of departments

manually. Apart from few exceptions majority of the documents coming in and going from MCIT

are handled by the documents and external relations department. To handle the workload and

facilities better, the Documents and Relations Department is divided into several units. The

directorates at MCIT are created for performing following functioning

Administration

Based on the respective Job Description, the Administration Department of the Ministry of

Communications extends its cooperation and collaboration to all other Technical as well as

Administration Departments of the ministry located either in Kabul, provinces or the districts in all

over the country. It facilitates provision of human resources, transportation of necessary tools as

well as the equipments to the stated points, opening the required L/C, distribution and

maintenance of the stated items and any further services.

Finance



This department is co-worker with other departments in the MOC; it is responsible for arranging

the budget, collecting the incoming money, acre the spending money, making clear the previous

accounting and performing the allocation of central and provinces.

Planning

The Planning Presidency (Project & International Relations Department) is a one of the key

department within the Ministry of Communication. Consist of the Planning President, Deputy

Planning President, Technical Planning Director, Foreign Relations Director, Development &

Research Manager, Policy Making Manager, and the External / Internal Agencies Liaison Officer.

Totally 85 members of staff are working in this department.

Documentation

Liaison and Documentation Department is responsible to arrange the sessions of minister Agenda

and Issues the decision of sessions to other departments of MOC. This department connects the

offices among the MOC and other ministries, Non Governmental Organizations and Embassies;

also it is responsible for broadcasting the deal of ministry propaganda. The “ Areka “ magazine

which is broadcasting from ministry belongs to this department, this department aware the

people of Afghanistan from developments, improvements, exchanging and other services in the

field of ICT{ Information Communications Technology} from via of interviews , media, holding of

conferences and round tables.

Information Communications Technology (ICT)

ICT Directorate is one of the mission critical directorates of the MCIT. This entity is responsible for

the ICT related issues in the country e.g policies, standards, legal framework, e-government, data

centres, cyber security, cctld, IRs and development projects in the ICT arena.

Supervision and Evaluation

Evaluation Dept. which indicate its name it is responsible for evaluation of incoming, services and

activities of communication, illegal deal from incoming, and accounting in the Kabul and provinces

of Afghanistan. Also evaluate the laws and in laws of national and international which approve,

issues from presidency of Afghanistan in communication fields, reports the doing of laws and in

laws to the main presidency of control and inspect. Evaluation Dept. is consist to the chart of MoC

and has 29 employees and 10 servants. This is Head of Dept., deputy head, Director of members,

central professional, Director of member’s provincial professional, Director of evaluation, Director



planning, Director of administration.

Information Communications and Information Technology Inst (ICTI)

The Information and Communication Technology Institute is the educational branch of the

ministry, responsible for the development of professional human resource in the areas of ICT at

the bachelor level. The institute will be offering graduates in the area of communications, IT,

Electronics, science and post to the national and international organization in the country.

List of exiting directorates

Following is the list of directorates which have been created for smooth functioning of the above

mentioned functionaries

1. Minister Admin Directorate

2. Procurement Directorate

3. Internal Monitor ing Directorate

4. Afghan Telecom

5. ATRA

6. Administration Directorate

7. Finance Directorate

8. Post Directorate

9. Human Resource Directorate

10. Province communication Directorate

11. Information and communication technology Directorate

12. ICTI Institute Directorate

13. Plan and Policy Directorate

14. Military Directorate

List of excluded directorates

From the above list, the following directorates have been excluded from requirements study

phase as they would not have EDMS implementation

1. Military Directorate

2. Province Communication Directorate

3. Afghan Telecom

4. ATRA



Minister Admin/ Documentation liaison directorate is divided into five sub departments.

1. Documentation and liaison department.

2. Relation and Documentation department.

3. Archive department.

4. Media and Relations department .

5. Dawaat-e-ershad department.(dept responsible for answering religious queries)

Documents from President’s office/Parliament/ Council of ministers/ Civil service commission.

• All the documents from president’s office are delivered directly at the Document ation and

liaison department

• Registration of the document and further actions to be taken on the document are

handled by the documentation and liaison department. In almost all cases the document

is forwarded to the minister for further action

Documents from other ministries

• All the documents from other ministries are delivered at the Archive department, after

registration of the document; it is then sent to concerned directorate whose name

mentioned on the document

• Documents from other ministries addresse d to minister initially delivered at the archive.

After the registration, the document is forwarded to the Relation and documentation

department, it will forward the document to the minister for the further action

• All the documents send outside the MCIT go through the archive department. But

documents which are addressed to president’s office will be dispatched directly from

minister admin directorate

The process of sending/receiving documents in the ministry is carried out manually. The

documents handled by the different departments of ministry are broadly divided two categories

1. Internal documents.

2. External documents.

Internal documents are those which are exchanged within the directorate and within the ministry.

External documents are the documents which are sent outside the ministry to other ministries or

parties and president’s office. All the documents that sent outside the ministry are sent through



the archive department. All the documents from outside the ministry are dispatched through

archive; archive will deliver the documents to the related directorates.

The documents from president’s office are dispatched directly to the documentation and liaison

directorate, after processing the document they will send the document to related directorate or

minister. The documents addressed to president’s office are sent directly through the

documentation and liaison directorate.

Every document created in each directorate is initially sent to the director of the directorate, if

document needs further action, then it is sent to concerned directorate or to the deputy minister

depending on the action that needs to be taken.

Current Work Process Flow:

The process map on the next page depicts the “Manage Movement of External Documents”

process flow. This process is essentially the same for the both of the Departments of Official

Documents regardless of whether the documents are received from the President’s Office,

Ministry of Foreign Affairs, other Ministries, or the Provinces.

Note: Documents from the president’s office will dispatched directly at the documentation and

liaison directorate. The documents from other ministries will be initially delivered at the archive

department of documentation and liaison directorate.

Current Work Process Description:

Step 1: The Department receives the external document and manually registers it in a paper

ledger. Examples of information recorded include: date, time, document number as assigned by

the sending ministry, and MCIT document number which is a concatenation of a number and the

received date, e.g. 101-12/98. The document is also prioritized for internal delivery based on

received date.

Step 2: The document is delivered to the MCIT Minister who checks it for required action and may

write or der on the document before passing it back to the Documentation Department.

Step 3: If no further action is required, the Department archives the document.

Step 4: If further action is required, the Department prepares a cover letter to that effect and

updates the document register.



Step 5: The Document Department deliver the document that requires action to the concerned

internal MCIT department.

Step 6: The concerned Department takes action based on the Minister’s orders.

Step 7: The concerned Department returns the document back to the Documentation

Department if no further action is required, or they may pass it to another internal MCIT

Department if another Departments needs to take further action on the document.

Step 8: The Documentation Department archives the document after all internal MCIT actions

have been taken.

Step 9: If required, the Documentation Department will send the document back to the

originating ministry.

2.2 Business Drivers / Objectives

The MCIT in its present processes of handing documents faces the issues of a typical paper based

processes following organization. The main pain areas of MCIT with the present system are

• Documentation process takes up time



• Redundant process is followed many of the time in proof reading

• All official communication is by paper document and manual

• All official communication goes through the Minister, which usually depends on minister

schedule, and takes time

• Documentation is kept in paper filing cabinets “forever” and upon increment in quantity the

record keeping space and searching problems increases.

• Security is another unaddressed issue

2.3 Implementation Site

EDMS system is to be implemented at the Ministry of communication and information technology,

Kabul, Islamic Republic of Afghanistan. The servers hosting the application will be residing in the

National Data Center which is in the building of MCIT, Ka bul. (At present, the data center is being

setup but it is expected to be ready when the EDMS would move to production server.)

3. Project (General) Electronic Document Management System (EDMS) would be a computer based, web based

system used for managing electronic and paper-based documents. The EDMS would offer a means

of checking documents into the system, searching for documents in the system, and version

control over the documents. The system will also provide workflow and collaboration capabilities.

Electronic document management system supports store, organise, retrieve and process

electronic documents. This system would help the users to perform all the tasks/operations which

they were performing manually faster, with more ease and, with more efficiency. Management of

paper based documents, hard copies of documents will also be possible by a feature which will

allow user to scan and convert into soft copies, and providing facility to capture data from the

documents, there by the documents will be forwarded over the system. The system will also

address the security concern of the documents at MCIT by support ing digital signatures whenever

documents required to be approved by the concerned officer /authority. Following are the bullet

points of the functionalities which would form EDMS

• Data Capture

• Document Retrieval

• Integration

• Workflow

• Version Control

• Security



• Administration

• Archival

• Traceability

• Distribution

• Template Support

• Optimized Search Functionality

• MIS Reporting

4. User Awareness with respect to Computerization Computer literacy in MCIT is high and usage of websites is known to almost everyone. The

proposed EDMS would be developed as a web based system which would easily be usable by the

end users with minimum training required.

5. Scope of Project This to be built system of EDMS is expected to fulfill all the needs with respect to document

management. EDMS is required to provide document management solution for both the type of

documents – soft copies of the document and hard copies of the document (print outs). The scope

of the project also consists of secured access to documents and providing top notch security

options for the signing authorities. Usage of biometric authentication and digital signatures for

authentication and authorization of the documents is the scope of the application.

Following points explain the EDMS scope in detail

• Development, implementation of Electronic Document Management System with all the

desired features of the EDMS only for MCIT

• Implementing access protocols to systems for EDMS application / role based access

mechanism

• Creation of digital signatures for signing authorities

• Development, implementation of workflow for EDMS

• Installation, configuration of EDMS at National Data Centre within the MCIT building in Kabul

• Installation, configuration of data capture and delivery solution at client location

• Converting part of existing documents in digital format

• Setting up hardware and software infrastructure required for hosting the EDMS application

• Training of EDMS application for end users during the launch

• Training of EDMS administrator for performing administrative activities



• Preparing application user manuals

• Preparing application related documentation like architecture, design, etc.

• System performance tunning

• System documentation

6. Description of Proposed system A web based EDMS (Electronic Document Management System) has been proposed for the

understood requirements of MCIT. The web based EDMS would provide all the desired features

mentioned in the project scope.

Following functionalities will be provided in the proposed EDMS

• Authorization and authentication – Users of the system will be authorized to create, destroy,

modify, review, and retrieve the various documents based on their role permissions. For

documents being generated, ordered upon, the users authentication will be validated

• Imaging and conversion – Digitizing paper-based documents into electronic format and

capturing metadata as per the Dublin Core Standards for metadata capture for the document

using Optical Character Recognition (imaging), as well as translating electronic documents

between different formats (conversion)

• Workflow management – automates the flow of documents and information in the work

process whereby we can precisely define working methods with regard to staff and their tasks

based on their roles and hierarchy, their input and output values. At the same time the

automated process will enable the ministry to create business policies and strategies for the

management of workflow, control and communication in the completion of work tasks

• Indexing – Filing documents into different categories according to predefined numbering

system, keywords, or other uniquely identifiable parameters which enables faster retrieval of

documents

• Storage and retrieval – will allow users to store the documents generated, converted to

digital format by them. The storage will be done in predefined fashion on to a database which

will enable the retrieval of the document in a most efficient and fast way

• Destruction – users will be permitted to destroy / erase the digital documents, its history and

versions based on role based hierarchy

• Multi-lingual – the document capture will be supporting English, Dari and Pashtu (Arabic

script). The proposed solution will also be configured in English and Arabic languages

• MIS Reporting – MIS reporting will be made available to the users based on their role

permissions. The reporting will be in the form of tables and charts



• Audit and Security – The application will provide an option to record the user events and

activities while using the solution. The user will be able to maintain different versions of the

document without any hassle

• Administration - The administrator of the solution will have access to all the user

management, document management, workflow management, backup and archival

management, site and sub-site management, and many more features of application

performance tuning

• General features - apart from these there will be general features for user like search, help

etc.

• Training & Documentation – As an effort to ease the use of EDMS of MCIT officials, there

would be training provided to both – the end users of the application as well as the

administrator of the application for performing the administrative activities. There would be

users documentation and operations details documentation would be provided

6.1 Architecture

The application architecture is multi-tier, with a clear separation of presentation, business logic,

and data. The system will be highly distributed and componentized for flexibility and scalability in

deployment. This makes it very easy to configure.

The open source based technology ensures that the application is completely flexible and

collaborative. This architecture allows EDMS to easily be integrated to other business critical

applications built on the Microsoft technology stack.

Scope Solution architecture layer

User interface screens/

Data Capture Software

Presentation layer

Business Rules Web Application layer

Data center Data layer



Presentation Layer

Presentation Layer provides the unified view of the application. The Presentation layer will be

developed using JSP, AJAX. This layer will function as an interface between user and the core

business logic of the EDMS.

Web application Layer

This is the Controller layer of the MVC pattern. Business Logic layer holds the core application. The

MVC based framework provides flexibility, modularity, data encapsulation etc. This is the middle

layer of the architecture. This layer has the core business logic embedded in it.

Data Layer

This is the layer at the barrel for the MVC architecture. Access to this layer is made only via

business layer. The communication adapter or database bridge is used to communicate with this

layer from the application. DMS (Document Management System) will use MS SQL relational

database server as the data storage for sequential storage of data and files.

6.2 Hardware

The EDMS application will be hosted on new servers which will be procured. Since this is the pilot

project, it is not expected to be used heavily and widely. The configuration of the hardware

required will be sufficient enough to support MCIT usage.

Following is the hardware required for production environment

Hardware Make / Version

DELL PowerEdge 2800 Dell: Power edge 2800

Up to 2 single or dual core 64-bit

Intel® Xeon® processors with

2MB L2 Cache per core at up to

3.8GHz

Operating System Windows 2003

Virtualization Software Offerings None

Operating System Additions None

Memory 2GB RAM

Chassis Configuration Default

Hard Drive Configuration 300GB SATA

Primary Hard Drive 300GB SATA

External Storage Controller(s) None



Fiber Channel HBAs None

Tape Backup Software None

Network Card Default

TCP/IP Offload Engine Enablement Default

Documentation

Power Edge 2800

Documentation

Bezel None

Optional Optical Drive DVD-RW, SATA, Internal

Server Accessories None

Keyboards, Mice, Displays and Related

Devices

Keyboard and Optical Mouse,

USB, Black, English, with 17”

LCD Monitor

O/S Partitions None

Power Cords As provided by manufacturer

6.3 Software

Following is the software technology stack for EDMS

Technical Platform Product

Application architecture 3 Tier Web Architecture

Application development language Java

Reports solution Jasper

Database MySQL

Presentation business tier

components

Java, AJAX, JSP, GWT

View / presentation framework Framework of Open Source Document

Management System

ORM Mapping Hibernate

Application Server JBoss 4.0



Version control system /

repository

CVS / SVN

Build / deploy / dependency tool Ant / Maven

Integrated Development

Environment (IDE)

Eclipse Galileo

Detail modelling / design tool Rational Rose / MS Word / Visio

Data capture and delivery solution Daybreak – eCapture Enterprise

version

6.4 Network Tools

Local Area Network (LAN) will be required for this application to be accessed within the MCIT

premises.

7. System Interfaces (If any) EDMS will be a web based application. They system will be accessible to the users from the web

browsers. Because of the wider applicability and scope, the EDMS will have following interfaces

7.1 User interfaces

EDMS will have a 'user friendly' full graphical interface where options and functionalities are

logically and dynamically placed on the screen.

The user interface of the EDMS system will be accessible after user has been authenticated with

the user name and password.

After the user logs in, the EDMS desktop screen will automatically adjust the user interface to only

provide the access to the functionality that user is authorised to access.

The User interface will have look and feel of windows explorer by which the user can easily

manage, organize, create, forward, search, edit the documents.

The notifications, tools, templates, help, bookmarks, all these options will be available in the form

of buttons, ta bs (different kinds of controls) through the user interface.



The user interface of the EDMS will have the support for Dari and Pashto languages.

User interface for the administrator of the system will have advanced controls by which he can

add/delete users, assign access levels of different kinds of users, create different user groups.

The User interface will have a dashboard which will consist of following features

• User view ( documents check-out, locked downloaded, subscribed, last modified, last

uploaded )

• General view (documents more (modified / viewed) last (week / month), last uploaded, last

modified)

• User news ( search agents )

• Workflow view

• Mail view ( new mails and attachments )

• Tag search and browsing

EDMS will be hosted onto a server and will be accessed by the MCIT officials over web as a client.

Following are some of the features of the client

• Web-based client: can access your document from anywhere

• Fast and enhanced user experience using AJAX

• Compatibility with most popular browsers: Firefox 1.5 or above, IExplorer 5.5 or above, Opera

and Safari

• Multilingual user interface

• No client side software install

• Preview of multimedia files

• Default language can be configured

• Web-based admin client



7.2 Hardware interfaces

Scanners will used be to scan the existing documents. And with help of e4x capture suite, data will

be captured from the, and delivered to the database of EDMS, there by the documents will be

converted to electronic documents.

7.3 Software interfaces

Being a web based application; EDMS will be accessed via several web browsers the primary one

and mostly used by all employees at MCIT is Microsoft Windows Explorer 7

7.4 Communications interfaces

An email notification will go to the users intimating pending action/ response on the flow of the

document in EDMS.

8. Data Migration Requirements There is need for data migration in this project. The documents which already exist with Archive

department are required to be converted to electronic format. The users of the system shall be

trained for performing this activity.

8.1 Inflow

The hard copies of different documents and templates that are used in the existing system

8.2 Outflow

All the hard copies of the documents will be converted into soft copies and metadata captured

from it

8.3 File Formats

Ms Word, MS Excel (for reports)

9. Assumptions & Dependencies

There are certain assumptions and dependencies in this project.

Assumptions

• All the users roles and information database of users will be provided by MCIT



• No end users will be directly approaching to Universal for grating permissions to access EDMS

during any time of the project

• Physical / Network security of the EDMS will be taken care of by MCIT

• It is assumed that Identification and timely availability of Application stakeholders and key

Operations and Support personnel for participation in information sharing

sessions/workshops conducted by Universal, would be the responsibility of MCIT

• MCIT will ensure availability of the required business users and the IT team during relevant

phases of the engagement. Universal assumes that the resources from will be available as

agreed upon during the course of this program and any delay caused by resources

unavailability may cause effort estimates to be revised which will be discussed with as

appropriate.

• All changes to scope will be handled using the change management procedures and may

result in potential changes to project timelines and costs.

• MCIT will take the responsibility for providing data for acceptance testing, interfaces testing,

data migration testing and performance testing, for providing acceptance test cases,

conducting acceptance testing and providing acceptance.

• All the documents related to project created will be in English only

• For the application hosting site, space, internet will be provided by MCIT

• MCIT would arrange gathering of officials who would receive the training of EDMS usage as a

part of project plan

• MCIT would arrange for / nominate administrator for the EDMS application who will be

trained on admini stration activities by Universal

Dependencies

• MCIT officials would respond to the queries (related to project )raised by Universal’s project

team within 2 working days

• MCIT would provide proper support or translator / conversion of the documents or

information in Dari and Pashto to English for Universal



10. Functional Requirements

By Mode

EDMS will support the following two modes of operation. The modes of operation are as follows.

1. User / Non privileged user mode of access.

2. Admin / Privileged user mode of access.

User access / Non privileged user access:

This is the mode which is accessible to all the users (common) of the EDMS system.

Users can log on/connect to the EDMS system by providing the proper user name and password.

All the basic functionalities like document creation, edition of documents, organise the

documents, forwarding the documents, document history, help, search, mark book marks,

tracking documents will be accessible to the user through this mode. The user can perform the

activities which are under his zone of authority. E.g. users will have signing authority, approval

authority based on their roles.

Admin / Privileged user mode of access:

All the administration activities of the EDMS will be accessible through this mode. Admin /

administrator are the super user of the EDMS system. The design of workflow, assigning roles to

different users, creating users, configuring the application, generating reports ; all these activities

will be accessible through this mode of operation.

The following activities will be performed through this mode operation

1. Perform routine audits of system and software

2. Performing backups if any needed

3. Answering technical queries from the users of the system

4. Installing and config uring new hardware and software

5. Trouble shooting of any reported problems

6. System performance tuning

7. Generation and analysing the system logs

8. Ensure the network is up and running

9. Creating the user groups

10. Generate the detailed user activity log

11. Advanced search facility

12. Workflow administration



By User class

The EDMS system is classified into four categories of the users on the basis of user class. The four

categories of the users are as follows.

1. Writers.

2. Reviewers.

3. Approvers.

4. Viewers.

Writers:

Create or revise documents. They use the check-in/check-out and versioning functionality in their

daily work activities. Writers are also responsible for assigning or updating key aspects of the

document. The interface to the EDMS system may be through a vendor -specific interface or the

authoring package (e.g., Microsoft Word).

Reviewers:

Reviewers participate in the review cycle of draft documents. They annotate the documents and

route them back to the writer. Annotations can be made using tools provided by the authoring

packages (e.g., Microsoft Word’s change-tracking capability) or other reviewing tools (e.g., Adobe

Acrobat). Reviewers also use the workflow tools that drive the distribution of documents. A work

queue view into the EDMS system alerts these users to the latest documents they must review.

Approvers:

Approvers promote the draft documents to a next level of review or final status, depending on the

rules defined for the review cycle. They use the workflow and sign-off capabilities of the EDMS

system.

Viewers:

Viewers use the final documents in the execution of their job functions. They search the document

repository and attributes for a particular document or set of documents. Once the documents are

found, they open them in a view-only mode. Viewers can locate documents by navigating the

repository tree structure, or by using the EDMS system’s search capabilities. In the latter case,

they may perform an attribute-based or full-text search to find the document or information they

need. Some systems provide different sets of functions to different classes of users. For example,

an elevator control system presents different capabilities to passengers, maintenance workers,



and fire fighters. When organizing this section by user class the outline as given below should be

used:

By Feature

The EDMS system will have following features:

Authorization and authentication – Users of the system will be authorized to create, destroy,

modify, review, and retrieve the various documents based on their role permissions. For

documents being generated, ordered upon, the users authentication will be validated.

Imaging and conversion – Digitizing paper-based documents into electronic format and capturing

metadata as per the Dublin Core Standards for metadata capture for the document using Optical

Character Recognition (imaging), as well as translating electronic documents between different

formats (conversion).

Workflow management – automates the flow of documents and information in the work process

whereby we can precisely define working methods with regard to staff and their tasks based on

their roles and hierarchy, their input and output values. At the same time the automated process

will enable the ministry to create business policies and strategies for the management of

workflow, control and communication in the completion of work tasks.

Indexing – Filing documents into different categories according to predefined numbering system,

keywords, or other uniquely identifiable parameters which enables faster retrieval of documents.

There is no indexing format being followed currently at MCIT, a standard indexing format needs to

be created.

Storage and retrieval – will allow users to store the documents generated, converted to digital

format by them. The storage will be done in predefined fashion on to a database which will enable

the retrieval of the document in a most efficient and fast way

Destruction – users will be permitted to destroy / erase the digital documents, its history and

versions based on role based hierarchy

Multi-lingual – the document capture will be supporting English, Dari and Pashtu (Arabic script).

The proposed solution will also be configured in English and Arabic languages



MIS Reporting – MIS reporting will be made available to the users based on their role permissions.

The reporting will be in the form of tables and charts

Audit and Security – The application will provide an option to record the user events and activities

while using the solution. The user will be able to maintain different versions of the document

without any hassle

Administration - The administrator of the solution will have access to all the user management,

document management, workflow management, backup and archival management, site and sub-

site management, and many more features of application performance tuning

General features - apart from these there will be general features for user like search, help etc.

11. Forms/Reports/Screens/ Workflows

11.1 Forms

Following are some of the document templates being used in different directorates

Maktub

Request letter used to communicate within and outside the ministry. It does have issue number.

Estelam

Request letter used to communicate within the department and within ministry. It doesn't have

issue number.

Peshnehad

Suggestion and Request Letter used to communicate within the department and within ministry.

All the samples of the above documents are attached in Dari and Pashto languages. Please see the

Annexure 1 for the templates.

11.2 Workflows

Following are the workflows captured from different directorates

11.2.1 Workflow in Documentation and Liaison Department

1. Hokum/ defense à recorded at R/D administration office then send it to director ; the

director will check it and then will send it to minister/ deputy minister for getting the order of minister then administration office will send it to all departments.



2. farman/-à recorded at R/D administration office then send it to director ,the director will check it and then will send it to minister/ deputy minister for getting the order of minister then administration office will send it to all departments.

3. Musawbat/ council of misters recorded at R/D administration office then send it to director the director will check it and then will send it to minister/ deputy minister for getting the order of minister then administration office will send it to all departments.

Note: Hokum, farmaan and musvabat will signed by the director of documentation and liaison and minister of MCIT.

4. Civil service commission maktubà R/D administration officeàdirectoràministeràR/D

Administration officeàrelated department.

5. Parliament maktubàR/D administration officeà directoràministeràrelated

departmentàanswer to this maktub (sent to parliament).

6. By the instruction/advice of ministeràR/D administration office (prepare this doc)àdirectoràministeràpresidential administration àR/D directorateàall directorates. (letter/doc from Ministry of MCIT) minister is going on leave, all depts will be informed.). Director and minister will sign on this letter. Minister will instruct the R/D directorate, to prepare the document. This letter will be sent to presidential administration office. Director and minister will sign on this letter.)

Note: 5, 6 both will be signed by the director of R/D directorate and minister, if the above letter needs a reply, then it will reply through maktub.

7. Order sheet widthà R/D administration officeàdirectoràpresidential administration deptà R/D administration officeàrelated department. This document is known as Daari varakey arz. If employee of some directorate is ill, he want s to go some other country, and then director asks to prepare the letter, then it will be send to the minister.

8. Maktubà R/D administration officeàdirectoràsend to all directorates or related

Directorates. Maktub will be prepared in the R/D administration office, after director sign, it will be sent to all departments.

9. Received MaktubàR/D administration officeàdirectoràsaved it or answer to that related department. (If they receive maktub from other directorate).

10. Request letter/peshehadàcomes to R/D administration office/or make it in this

directorateàdirectoràministeràrelated department. (If they receive request letter/peshehaad from other directorate).



Documentation and Relation sub department:

1. Document from outside the ministryàarchive(MCIT)àRelation and documentation deptà GM (will sign) àif it needs to be send, then doc will be sent to the documentation liaison Departmentàdirector (Sign)àsent to the concerned department.

Note: In the absence of the director, GM(mr Haji of documentation and liaison dept) will sign the document.

Media and Relation sub department: 1. Manager (sign)àGM (Media and Relations )àDirector(documentation and liaison

Departmentàif it is needed then the document will be sent outside.

11.2.2 Workflows in Planning and Policy directorate

Statistics and Research department: 1. Employee-à manager-àGM-àprincipal--à admin-àdirectoràexecutive officer (of

deputy minister)-àdeputy minister (technical)-àadmin (policy dept)-àarchiveàCentral statistics dept.

2. Employee-à manager-àGM-àprincipal--à admin-àdirectoràExecutive officer (of deputy minister)-àdeputy minister (Technical)àadmin(policy dept)àarchive-àMinistry of economy.

3. Employee-à manager-àGM-àprincipal--à admin-àdirectoràadmin/secretary (of deputy minister)-àdeputy minister -àadmin (policy dept)àarchive-àPresident’s office.

4. Employee-à manager-àGM-àprincipal--à admin-àdirectoràadmin/secretary (of deputy minister)-àdeputy minister -àadmin (policy dept)àarchive-àConstitution of Afghanistan. Note: Once report delivered successfully at the destination, they send the maktub back to the planning/policy department.

International Relations department: 1. If a director of one department went to china for visit, after coming from his visit, he asks his admin to prepare the report, and then the following workflow is followed. Admin-àdirector(sign)-àadmin(policy dept)-àdirector(planning){sign}-àHead(IR dept){sign}-àGM(IR dept)-àexecutive officer(deputy minister)-àdeputy minister{sign}-àexecutive officer(deputy minister)àGM(IR dept)àArchiveàMinistry of external affairs.

Note: If letter needs reply then in that case, it will be sent to Ministry of affairs else it is stored in the culture dept. Note: when letter is addressed to the International Relations dept, sometimes it goes through admin (planning and policy dept), or some times it sent directly to GM of the International affairs dept .

Control and evaluation of Projects department:



1. The following hierarchy is followed in the generation of reports. Employeeà Manager (sign)àGMà Head(control and evaluation of projects)àdirector(sign).

Note: Director submits the report in the board meeting with the deputy minister (quarterly). 11.2.3 Workflows in the Finance directorate:

Income General Management Department:

1. Form Meem27 (Revenue collection report): Using this form, income department submits report of revenue collection to Finance Ministry along with the following workflow:

GM(income department)àFinance Director ateà Finance ministry. Number of signing authorities in Meem 27 —3

2. Form Meem 28 (collector’s journal): Using this form, daily journal of ministry income collection is registered and kept.

3. Form Meem 29 (income collection report): Using Form Meem 28 monthly income

collection report of ministry is written and sends to Finance Ministry (Treasury Directorate) along with the following workflow:

GM(income department)àFinance Directorateà Finance ministry Number of signing authorities in this document -3.

4. Form Meem 67 (income transference): Using this form, Collection Management sends

report of daily income collection of ministry to Income General Management (these reports are used while generating Form Meem 27 and Form Meem 28).

Workflow: M(Collection Management)àGM(income department) Budget General Management department:

Ordinary and development budget is covered in center (Kabul) & provinces (34).34 directorates of MCI T. 1. For acceptance of this budget—ministry of finance

GMàDirectoràAdmin Deputy Minister (registers it and approves it) àFinance Ministry Archive/Admin Directorate (then referred to related department in Finance Ministry).

Note: There are two Admin Deputy Minister’s: technical and admin Templates used to get it approved. 2. Form B-23 (Fund transfer request): This form is used to request for fund

appropriation and transfer from Finance Ministry, also after approval too, this form is used for extra fund request (extra fund is requested using specific codes like 91, 93, 95, and 99).

Workflow: GMà Finance Directorate àFinance Ministry Number of signing authorities in B -23 —5



3. Form B-27: Once budget is approved, after every 3 months, Finance directorate, request to the finance ministry to approve and transfer the specified amount from the full allocated amount. (Say 20,000rs out of 1, 000, 00). This form is used for both ordinary and development budget of ministry.

Wor kflow: GMà Finance Directorate àFinance Ministry Number of signing authorities in B -27 —4 4. From B-3: General annual appropriation of budget for capital and provinces is

calculated and created in this form and send to Finance Ministry for approval. Workflow: GMà Finance Directorate àFinance Ministry Number of signing authorities in B -3 —3 5. B-10 (Ordinary Budget Plan for Capital/Provinces): After final approval of requested

budget, every province specific budget/part is specified using this B-10 form and send to Finance Ministry for approval.

GMà Finance Directorate àFinance Ministry Number of signing authorities in B -10 —1 6. Form Alef 1 (Ordinary Budget proposal summary): This form is created by Budget GM

to send a summary of next three years ordinary budget proposal to Finance Ministry. Form Alef 1 has three templates: Budget detail, Ordinary budget apportion for provinces, proposed employees apportion.

GMà Finance Directorate àFinance Ministry 7. Form Alef 4 (forecasted income summary for budget creation): Using this form, next

year budget is requested from finance ministry. GMà Finance Directorate àFinance Ministry

Companies’ accountant General Management department:

1. Form Meem 25 (revenue collection money order): This form is used to send information about money order collection to Finance Ministry Treasury Directorate.

2. Budget appropriation calculation General Management:

Form B 27: This form is described in previous part, while this form is send by Budget GM to Finance Ministry for Budget appropriation, after approval its send back to Budget Appropriation GM, for further process B 27 form is used while generating Form Meem 38 (registration of appropriation) and Form B 20 (province budget part).

3. Form B 20 (appropriation coding table): Using this form, a table for appropriation

coding according to the program is created and every province and capital share is arranged and send to Finance Ministry after 3 months.

GMà Finance Directorate àFinance Ministry Number of signing authorities in B -20 —5



4. Form Meem 20 (Book of Money order appropriations expenditure): While budget appropriation is approved through Form B 20, expenditure and payments of appropriated b udget are registered in Form Meem 20 and kept.

5. Form Meem 22 (Expenditure Report): Every month expenditure report (ordinary and

development budget) of capital and provinces is send to Finance Ministry. It has two templates one is send to Finance Ministry and another is kept. Written reports from capital/provincesàGM (Budget appropriation dept creates Form Meem 22)à Finance Directorate àFinance Ministry

6. Form Meem 38 (Book of appropriation money order control): After approval of

Ordinary and development budget appropriation by Finance Ministry, it’s registered and kept in this book.

7. Form Meem 17 (Payment Book): Detail information about any payment is registered

and kept in this book.

8. Form Meem 90 (Budget dissuasion): information about unused appropriated bu dget is registered, it has two templates one is a book that’s kept and another one is a form that’s send to Finance Ministry.

GMà Finance Directorate àFinance Ministry Number of signing authorities in Meem-90 —4

9. Form Meem 91 (Final report of budget expenditure): Using this form, annual budget

expenditure is created and send to Finance Ministry. GMà Finance Directorate àFinance Ministry.

Payment General Management:

1. Form Meem 16: This form is used in three cases and has three templates (for ordinary budget, development budget and salary).

2. Form Meem 16 (Payment order): This form is used for money order from ordinary

budget by Budget expenditure Management.

3. Budget expenditure M (creates Form Meem 16) àGM (Payment dept creates 4

copies, 1 copy is kept, 2 copies to Finance Ministry, 1 copy to budget appropriation GM)à Finance Directorate àFinance Ministry

Number of signing authorities in Meem-16 —6 4. Form Meem 16 (Payment order): This form is used for money order from

development budget by Budget expenditure Management. Budget expenditure M (creates Form Meem 16) àGM (Payment dept creates 4 copies, 1 copy is kept, 2 copies to Finance Ministry, 1 copy to budget appropriation GM)à Finance Directorate àFinance Ministry

Number of signing authorities in Meem-16 —1 5. Form Meem 16 (Payment order): this form is used for money order for salary

payment and sends to finance ministry.



GMà Finance Directorate àFinance Ministry Number of signing authorities in Meem-16 —4 6. From Meem 12 (Advance Acquittal): Using this form, money that is taken in advance

(using Form Meem 10) is acquitted through this form from persons account (like person is going on official trip 10,000 is given in advance and in return have to pay back the remaining money). Budget expenditure M (creates Form Meem 12) àGM (Payment dept creates 4 copies, 1 copy is kept, 2 copies to Finance Ministry, 1 copy to budget appropriation GM)à Finance Directorate àFinance Ministry

7. Form Meem 9 (Request/Approval for trip): This form is used by directorates within

ministry for request and approval of a trip. Number of signing authorities in Meem-9— 4 8. Form Meem 13 (Request/Payment order for trip): This form is created by ordinary

budget expenditure management for trip request and money order and it’s copies attached with Form Meem 16 are send to finance ministry and budget appropriation GM.

9. Form Meem 10 (Request & registration of advance fund): Using this form advance

money is asked for procurement, trips and salary and this form is created by Procurement department, Salary Department and expenditure Department.

10. Form Meem 40 (Book of individual salary and deduction): Using this form, Salary

Department registers monthly salary amount and details of whole year of an employee in single paper.

11. Form Meem 41 (Salary estehqaq): Using this form, Salary dept creates salary estehqaq

and attached with Form Meem 16 sends to Budget appropriation dept, then Form Meem 41 copy attached with Form Meem 16 is send to Finance Ministry for approval.

11.2.4 Workflows in Internal Monitoring Directorate:

1. ManageràHeadàDirectorateàßGM 2. Directorateà Head of Inspection 3. DirectorateàMCIT Minister

Note: Head refers to the (Income Inspection and Monitoring/ and Inspection of Project Development)

11.2.5 Workflows in Human Resources Directorate:

1. HD manageràGMàheadà Hiring Directorateà minister admin office 2. HD’s manager àGMàheadà HR Directorà Commissionà HR dept.

3.EmployeeàMinister/directorateàDeputy Ministerà HR Directorateà head biography dept.



11.2.6 Workflows in Administrative Support Directorate:

1. If any department requires something like Goods, directorate of that department will contact the Admin directorate. Admin directorate will refer it to the Head of services department.

Directorate (concerned directorate)àAdmin Directorateàhead of Services

11.2.7 Workflows in Procurement Dire ctorate:

Administrative department: 1. Request form of goods( form darkhwaste ajnas) 2. Expenditure form / Masrafi form 3. Goods submission form(form ahada) Note: Process of these three kinds’ forms comes form related department à PR administration will register it -à director -à store house then gets the goods.

Purchase and Ratemaking department: 1. Form of registration/Registration Profile form goods in goods listed.

Budget preparationàdirectoràdeputy minister -à sent to finance ministry,àapprovalà Call for biddersàgive their proposalsàcommittee of 3(appointed by minister)àsubmit reportàdirector signsà send to deputy ministeràfinally contract will be made. Note: approval needed from minister only in case the amount is more than 5000 afs, otherwise director will sign it.

Foreign logistics department:

1- Form mafee/ Q forms custom product pricing after filling will sign it in th is departmentàdirectorà ministerà ministry of finance (more details). Employeeàmanageràdirectoràminister àcustoms officeàget goodsàgive at inventory.

2- asnad mahsul gumruke/ Product documentation Customs the same process but by maktub. This document is filled by the customs people which contains the details of product documentation.

3- tashreh tajhezat/ Anatomy Equipment form for Goods purchased with the described offers signed by this departmentà directorà commissionà related department. (more details) .(along with form-e-mafee, the document contains specification of goods).

Inventory management department: 1. Form mawjode / inventory form is inventory value of known goods.

Note: This is used by the inventory to check goods are available or not. Employeeàmanageràdirector (procurement)àcommittee of 3(appointed by president)àsubmit report to directorateàdeputy ministeràback to inventory dept.

Leelam wa waguzare management department:



1. form ahada/ Form restoration because the goods are then submitted to store house.If employee want to hand over the goodsàform-ahadaàdirector(sign)àprocurement(director)àsend to mausabi agencyàcollect the card(which contains the details of ownership of computer)àhand over to inventory dept.

12. Context Diagram

<Please draw a context

Following steps as depicted in the diagram explain how the system would function with user at

the centre

1. User scans the paper document using the scanner. As soon as the documents have been

scanned, it would be visible to user in eCapture – the document capture and delivery

application

2. User verifies the captured metadata of the scanned document and marks the document for

upload to repository over the LAN connection.



3. eCapture, transmits the document image to the DMS (Document Management System /

Server) with metadata attached to the document file

4. User can create MS Word, MS Excel documents on his local workstation in Microsoft Office

client (MS Office will not be provided as a part of solution) OR receives a document as a part

of signing or reviewing authority as per the workflow implemented

5. Alternatively uses the templates of documents fr om DMS to generate the document. We will

create few templates which are commonly used in MCIT. These templates will be stored in

DMS as Library and can be used to generate document. User would need to fill in the content

in to the library document.

6. User can upload the documents to the EDMS system over the web browser and apply his/her

digital signature stored in to the server

13. Strategy 13.1 Development

Project is planned to be executed using the pure waterfall development methodology with entire

business functionality being developed and delivered at once.

• There will be one release whereby functionalities are integrated to make one application

• During the requirement analysis phase, universal will deploy its consultants at client

location who will work with MCIT officials to understand their current processes,

requirements of EDMS in depth. Getting the requirements and design out of the way first

also improves quality; it's much easier to catch and correct possible flaws at the design

stage than at the testing stage, after all the components have been integrated and

tracking down specific errors is more complex. Finally, because the first two phases end in

the production of a formal specification, the waterfall model can aid efficient knowledge

transfer when team m embers are dispersed in different locations

• The requirements once completely understood and documented in consultation with

MCIT officials, would be mould into an technical design which will address entire gamut

of activities of EDMS

• During the construction phase, the design would be adopted and the customization and

configuration jobs will be done to make a system which addresses client needs. In this

phase batches of features will be created together.



• The batches of features created in the earlier stage will be integrated together to make

one system – EDMS.

• Several testing methodologies would be applied to test the integrated solution and ensure

that the developed system is completely defect free.

• Once testing is complete and a defect free solution has been established, Universal will

deploy the serves, EDMS at client location.

• Post implementation warranty and support would be provided. Support would be limited

to training of the MCIT officials.

Project Lifecycle Phases – Activities and Roles

Assessment Phases – Requirement Study, Analysis

Requirement Study Requirement Analysis

Input

• Business Process Knowledge

• System Profile

• Signed off high level

requirements

Activities

• Gap Analysis

• Detailed project implementation

plan

• Requirement extraction from

business users

• High level business requirement

document

• Identification and modelling of

processes

• Identify Infrastructure

requirement priorities

• Requirement Prioritization

• User sign off on process models,

• Standardization and

optimization of model

process created in

requirement study

• Refine and revaluate the

scope, cost estimate and

effort with detailed work

breakdown

• Document additional

requirements related to

Reporting, Integration,

Non Functional

Requirements

• Document additional



object models, and high level

requirements

requirements related to

Reporting, Integration,

Non Functional

Requirements

• User sign off on to-be

process models

• Define Quality of Service

expected from the system

Role wise

participants

• Project Manager

• Business Analyst

• SQA

• Solution Architect

• Infrastructure and

environment

management team

Design and development Phase:-

Design Build

Input

• Optimized process model from

pervious stage

• Business rules

• Detailed process specification

• Additional requirements

• Infrastructure requirements

• Detailed solution

design document

• Detailed integration

design document

• System architecture,

architecture diagrams,

data model

Activities

• Detailed architecture

• Detailed design solution

• Broad integration strategy

• Release matrix based on

different parameters such as

location, user base, business

• Detailed development

scheduling

• Build core and sub

processes and

associated routing

logic



units etc.

• Test Strategy

• Deployment Architecture.

• Review and sign off on System

Architecture, Infrastructure

Architecture Diagram, Data

Model Diagrams.

• Procurement and installation.

• Development of Test Strategy

• Development of Test Cases

• Build UIs and related

attribute validation

logic

• Implement integration

as documented in the

integration

specification

document

• Develop various

reporting requirement

• Conduct frequent

demo to get user

feedbacks.

• Unit test the

developed solution

• Complete

development of test

cases

• Test case sign off

Role wise

participants


• Test manager

• Tester


• Project Manager

• Developers

• Tester

• Configuration

Manager

Test and Deployment Phases:

Test Deploy



Input • Fully functional code base

ready for testing

• Test strategy document

• Test Case document

• High Level requirement

document

• Process specification

documents

• Fully tested code base

• Test reports

• UAT test cases

• Production

deployment plan

Activities

• Execution of system test cases

for all the modules

• Documentation of test results

• Updating the Issue tracking tool

with identified issues

• Tracking of identified issues to

closure

• Performance and Integration

testing

• Resolution of any performance

related issues

• Set up for User acceptance

testing

• Coordinate user

acceptance testing

• Classification of issues

raised by UAT team as

Bugs and

enhancements.

• Modification of code

for identified bugs and

enhancements for

present release

• Set up of production

environment

• Deployment of final

accepted code base/

configurations on

production

environment

Role wise

participants

• Test Manager

• Tester

• Development Team

• CM

• Business Analysts

• End Users

• Development team

• Test team

• Environment

management team



Testing Strategy

Universal will adapt to robust testing strategy to make sure that the system is stable in usability as

well as business functionalities.

Following testing strategies will be applied during the life cycle of EDMS

• Unit Test: Unit test cases will be created and executed for every module in iterative manner.

This will assure a lower defect rate and higher efficiency of code at the time of integration

• Integration Test: This test will be carried out after all the units have been integrated to form

the complete application. This test ensures that the integrated system is working to produce

functionality as expected.

• Performance Test: Performance tests will be carried out on application to test if the

application meets the standard requirement for response time.

• Stress Test: A simulated flow of concurrent virtual users will be created in controlled

environment to make sure that system can handle the user load or number of concurrent users

accessing several features.

• Beta Test : Few users will do the beta test to find out if application feature set and functioning

is as per the plan

• User Acceptance Testing: Once complete application has been built and tested using above

testing strategies, finally MCIT will be asked to test the application and gauge entire feature set

and performance of the application. Acceptance criterion will be defined and agreed upon in the

inception phase of the project. After completion of acceptance test, project will enter into

warranty phase

The test data will be supplied by the MCIT in the form of templates of the documents, workflow

etc.

13.2 Implementation

Following activates will be carried out one by one for implementation of the EDMS at MCIT post

development of the software

1. Site Analysis

2. Setting up hardware production environment

3. Setting up software production environment

4. Set up user base



5. Setup / Configure DMS

6. Installation of eCapture on user desktops

7. Application rollout

8. Training of end users and application support staff (for administration activities) for a

weeks time

Since this is the pilot project, the implementation will be done at once on the production

environment.

Training plan

Training on EDMS will be provided for usage of the EDMS system and uploading and downloading

of the documents and following the workflow

1. Train the Trainer approach for the ICT directorate trainers

2. Every department which will use EDMS will nominate approximately 5 officials for training

of EDMS

3. Universal and ICT trainers will train the other directorate officials in batches

4. A separate training will be conducted with administrator group for training them on

administration activities

13.3 Risk Areas

Following are the generic and specific risks which are applicable to this project

• Scope Change

Business users may want to increase or reduce the scope of the project based on further

deliberations External dependencies like Vendor Interactions or other Initiatives could result

in changes to the plans

• Non-Availability of Business User Time

Key Business User is on vacation or is unable to provide time due to other commitments

• Introduction of New Members to the Core Team

This could lead to new perspectives late in the requirements process leading to delays

• Consensus Building

The user group disagrees on the solution approach and is unable to reach a conclusion

• Communication

The user group providing inputs feels isolated since they are not having an idea of the big

picture



• Delayed Inputs or Decisions

Delay in decision making or providing inputs with respect to the agreed schedule

• Delays in Signoff

Lack of consensus, time or quality of the deliverable could lead to delays in the signoff and

approvals of the documents

• Incorrect Translation

Translator’s lack of language expertise in English from Dari / Pashto can have severe impacts

• Natural Issues / Catastrophic events / War like Situation

Due to the sensitivity of the geographic region, there could be natural disasters / war like

situation which could delay or completely halt the project execution

Risk monitoring plan and mitigation strategy will be required for the project

14. Acceptance Criteria

Following are the acceptance criteria put forward by the client

Data Capture

Paper documents can be entered onto an EDMS by simply scanning images of them. The EDMS

should prompt the user to provide information for its appropriate storage.

Documents already in an electronic format can also be entered in the system – again, aided by

storage information provided by the user.

Document Retrieval

Individual electronic documents are assigned metadata to assist in their correct filing and tracking.

Metadata typically includes the date of storage and the identity of the user storing it. In addition

to these basic details, EDM systems attach additional data (compiled through either user input or

an automatic extraction from the document content) to allow users to locate documents quickly

using keyword searches. Documents must be indexed correctly to ensure that retrieval is possible.

Integration

In order to make best use of documents, EDMS should be accessible from other applications. The

changes to be done in other application for collaboration are not in the scope of EDMS however.

Workflow



EDMS should support role based workflow implementation and should have facility to administer

and update the workflows implemented.

Version Control

EDMS should maintain the versions of the documents as it progresses in its life cycle.

Security

In any enterprise it is vital that the security of electronic documents is appropriately managed.

EDM systems ensure that access to the system is restricted only to those with the correct access

permissions, both to ensure the integrity of data and to reduce the number of documents

presented to the user only to those documents that are relevant to his or her role.

MIS Reporting

MIS reporting should be made available to the users based on their role permissions. The

reporting should be in the form of tables and charts.

Indexing

Based on the predefined format i.e. Combination of numbering system, date(date format will be

in lunar calendar) and other uniquely identifiable parameters, there should be a uniform indexing

scheme across all the departments. This will enable the faster retrieval of documents.

Reminders

Reminder of unread/new documents will be sent through emails and there should popup windows

for the remainders.

Destruction

Users should be permitted to destroy / erase the digital documents, its history and versions based

on role based hierarchy.

Audit

The application should provide an option to record the user events and activities while using the

EDMS.

Administration



The administrator of the EDMS should have access to all the user management, document

management, workf low management, backup and archival management, site and sub -site

management, and many more features of application performance tuning.

User Interface

The document management system can be accessed through user friendly graphical interface. The

users of the system can easily work on it and create, modify and forward documents as per their

requirements.

Distribution

The document should be available to all the people who are involved in the life cycle of the

document; they can access the document as per needs.

Traceability

The document management system should support the traceability of the documents, e.g users

can find when, where and by whom the document is created, modified and stored. The details of

the life cycle of any document can be easily fetched by the users based on their role and

responsibilities.

Digital Signatures

EDMS should facilitate use of Digital signatures which helps identify the authenticity of the

document and signer. Biometric authentication (thumb impression) will be used for validating the

user identity.

Production Environment

For the delivery of optimized runtime performance, the application server hosts the Java

components and framework to be used that makes the production environment more scalable.

Database layer stores the Co ntent, configuration, and Index and Reporting data. Secure and

scalable environment

Users

EDMS should support approx. 1000 users.

EDMS should also support approx. 100 concurrent users at any time.



Documents

EDMS should be capable to support processing of at least 100 documents in a day.

15. Delivery Specification

15.1 Packaging

The software built will be deployed onto the production servers by Universal. The software will be

in the form of a WAR file which can be deployed onto the application servers.

15.2 Installation

The installation of the software would be done by Universal staff and there would be training /

manuals provided to MCIT officials for installation of the application in future.

15.3 Documentation

Following documents are required to be maintained during the lifecycle of the project

• Software requirement Specification

• Application Design Document

• Application User Manuals

• Project Operational Details Document

16. Annexure

16.1 Forms (templates) used in MCIT