SRS Document

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
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
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
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
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
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
3 Models
3.1. Context Model
Administrative Privileges
Document Departments
Main Server Integration
Processing Devices
Operation Management
Computer
Electrical
Electronics
Chemical
Info & Technology

Mechanical
Document Processing Synchronizatio
Ci
Devices
Petrochemical
7|Page
3.2 Object Model
Customer - DPD
-Description
-DPD no.
Student Staff -Status
Server Document
Name -Pages
Roll No Name -Description
-Comm. Control
-Password -Contents
Other DPDs
-Description
-DPD no.
-Status
8|Page
3.3 Behavioral Model
Customer
Read the Document Data
Check if the
Data Processing Device reached Process the Document
No
its limit
Yes
Check the server for Relax DPD
Inform the customer

of relax DPD
Process the document
by relax DPD
9|Page
Software Requirement Specification
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

SRS Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SRS Document

Uploaded by

Copyright:

Available Formats

Software Requirement Specification 2010

1.1 Purpose of this Document

2.1 Stake holders and Concerns

3.1 Context Model

1.1 Purpose of this Document

1.2 Scope of the Development Project

1.3 Acronyms, Abbreviations and Definitions

Communication - The activity of conveying information.

2. Learning SRS Documentation

3. Description of management system

2.1 Stake Holders and Concerns

Sr. Stake Holders Concerns

1. Student To ensure that the product meets the needs of the

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

2.2 Overview of Functional Requirements

2.3 Existing System

2.4 Proposed System

3.1. Context Model

Info & Technology

3.2 Object Model

3.3 Behavioral Model

Read the Document Data

Check the server for Relax DPD

Inform the customer

You might also like