Software Requirement Specification 2010

Software Requirement
Specification
for
System for Document
Processing Devices
Management

Documented by:
Tage Nobin
Roll: 20070653
Third Year B.Tech
Dept. of Computer Engineering

1|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

Table of Contents
1. Introduction

1.1 Purpose of this Document

1.2 Scope of the Development Project
1.3 Definitions, Acronyms, and Abbreviations
1.4 References

2. System Overview

2.1 Stake holders and Concerns

2.2 Overview of Functional Requirements
2.3 Existing System
2.4Proposed System

3. Models

3.1 Context Model

3.2 Object Model
3.3 Behavioral Model

4. Feasibility Report

5. Conclusion

2|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

1 Introduction

1.1 Purpose of this Document

This Software Requirements Specification (SRS) specifies the
requirements for a Computer Software Configuration (CSC) and the methods to be
used to ensure that an efficient management prevails in context of document
processing devices. The Software documented in this SRS will solve the problem
pertaining to various Document Processing Devices (DPD) in context of over and
under utilization in Dr. BAT University.

1.2 Scope of the Development Project

Document Processing Devices Management (DPDM) is a Management
System, which combines the various methods and tools against a better
management of the document processing devices.

a) Getting all the information related to DPDs existing in Dr. BAT University.
b) Synchronizing all the DPDs with a common server.
c) Giving the necessary information regarding DPD status to the customer.
d) Process the document as per specification of the customer.

1.3 Acronyms, Abbreviations and Definitions

DPD - Document Processing Devices
DPDM - Document Processing Devices Management
SRS - Software Requirements Specification.
CSC - Computer Software Configuration

3|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

Communication - The activity of conveying information.

Synchronizing - Coordinating by causing to indicate the same time so that
things occur at the same time.
Server - A computer that provides client stations with access to files
and printers as shared resources to a computer network.
DPD - Devices that are used for processing (print, scan, fax etc.)
of document.

1.4 References
1. Description about DPD
http://www.elearningpost.com/features/archives/001022.asp

2. Learning SRS Documentation

http://www.techwr-l.com/techwhirl/softwarerequirementspecs.html

http://www.itech.fgcu.edu/faculty/zalewski/ISM4331/writingSRS.html

3. Description of management system

http://www.dataworld.com

4|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

2. System Overview

2.1 Stake Holders and Concerns

Sr. Stake Holders Concerns

No.

1. Student To ensure that the product meets the needs

of the customer
2. Teaching Staffs To ensure that the product meets the needs
of the customer
3. University Administrative Staffs To provide all the logistic & informational
support
4. HODs of all Departments To control the respective departmental DPDs

5. Software development team To make sure that they develop exactly what
is required by the customer
6. Software testing team To validate the working of the software

7. S/W Documentation team To understand the product well enough to

be able to write the users’ manuals.

5|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

2.2 Overview of Functional Requirements

We describe the functional requirements by giving various use cases.

Main scenario:
1) Customer brings the document to be processed to a DPD point.
2) DPD employee checks the DPD limit.
3) If the limit is not reached, document is processed at the particular DPD point.
4) Otherwise, DPD sends a request to the common server enquiring about the
status various other DPDs.
5) The customer is informed of the relax DPDs.
6) The customer get to the relax DPD point and get the documents processed.

2.3 Existing System

In the present system all departmental document processing devices are of
independent nature. There is no synchronization between them. There are various
sections or department which does seldom need any of these DPDs; on the other hand
some department inevitably needs them. This leads to some DPD being over utilized
and some being underutilized.

2.4 Proposed System

The Proposed System will have the capabilities of synchronizing all the
document processing devices in the University with a common server. The server will
act as a medium for all the communication between them. This will result in a common
instruction being followed allowing all the DPDs to check the status of others and work
accordingly.

6|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

3 Models

3.1. Context Model

Administrative
Privileges

Main Server Document Departments

Integration
Operation Processing
Devices
Management

Computer

Electrical

Electronics

Mechanical
Document Processing Synchronization
Devices
Petrochemical

Chemical

Info & Technology

Civil

7|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

3.2 Object Model

Customer DPD

-Description
-DPD no.
Student Staff -Status
Document

- Name - Name -Pages

- Roll No -Department
-Contents

Server

-Description
-Comm. Control
-Password

Other DPDs

-Description
-DPD no.
-Status

8|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

3.3 Behavioral Model

Customer

Read the Document

Data

Check if the
Data Processing
No Process the Document
Device reached
its limit

Yes

Check the server for

Relax DPD

Inform the customer of

relax DPD status

Process the document by

relax DPD

9|Page
Dr. Babasaheb Ambedkar Technological University
 Software Requirement Specification 2010

4. Feasibility Report
The assessment is based on an outline design of system requirements in
terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be
quantified in terms of volumes of data, trends, frequency of updating, etc. in order to
estimate whether the new system will perform adequately or not.

1) Economic Feasibility
Economic analysis is the most frequently used methods for
evaluating the effectiveness of a new system. The budget allotted for the
development of the software may lead some kind of constraints.

2) Legal Feasibility
We need to check if the proposed system conflicts with legal
requirements i.e. all the data processing devices must comply with the local
data protection acts.

3) Schedule Feasibility
A project may fail if it takes too long to be completed before it is
useful. A same kind of problem may persist in our proposed project. Since it
involves various departments, there may glitches while organizing the
various DPDs.

4) Incumbent Feasibility
Since it involves synchronizing various departments, round the
clock gathering information from each department is must. The staffs of the
various departments may not feel for go-nod as they may think that existing
system is enough.

5. Conclusion
The above documented Software would be in par with all the existing
softwares installed in various DPDs. The software would manage all the tasks
relating to processing of document that too in real time. Software of this nature
would surely enhance the functional capabilities of various DPDs in Dr. BAT
University by applying simple management procedure.

10 | P a g e
Dr. Babasaheb Ambedkar Technological University