CDAC-ACTS,PUNE

Software Requirements Specification

On

Online billing and Stoking Management System

Submitted by

Rakesh kumar PRN:0212004010194

Viraj patil PRN:0212004010208

Nitish Rashivadekar PRN:0212004010130

Rohit Sarda PRN:021 2004010229

Rishabh Verma PRN:0212004010210

Project No: 13

2012

Under the guidance of

Mr. Prashant Singh Sisodia

Table of Contents

1.0 …………………………………………………………..….2

1.1. Introduction…………………………………………………………………….…2

1.2. Scope…………………………………………………………………………........2

1.3. Document overview………………………………………………………….…....3

1.4. Web references………………………………………………………………….…3

2.0 Overall description………………………………………………………….……...4

2.1. System environment………………………………………………………….…....4

2.2. Requirements……………………………………………………………………....5

2.3 Functional requirements…………………………………………………………....5

2.4. Non-functional requirement……………………………………………………………….6

3.0 Analysis model for our project…………………………………………………………….8

4.Design………………………………………………………………………………….8

4.1 Introduction to UML …………………………..………………………………………….…9

4.2 System Design……………………………………………………………………….…….10

4.3 Use case Diagram…………………………………………………………………………10

4.4 Class Diagram………………………………………………………………….…….….. 12

4.5 Detailed Use cases ………………………………………………………………....…….13

4.5.1. Usecase1: functionalities of admin………………………………………...13.

4.5.2. Usecase2: functionalities of customer.....…………………………………..14

4.5.3. Usecase3: bill processing by Credit card…………………………………..16

4.6 system evolution………………………………………………………………… 17

1

1.0. Purpose of the system

1.1. Introduction

A Software Requirement Specification (SRS) is the starting point of the software developing

activity. It is a complete description of the behavior of a system to be developed. It includes a set of

use cases that describe all the interaction the users will have with the software. It is a complete

description of the behavior of a system to be developed. It includes set of use cases that describe all the

interactions the users will have the software.

The main objective of this system is to keep records of the complete inventory .

It support for inventory management helps you record and track hardware parts on the

basis of both quantity and Model no.

It improves cash flow, visibility, and decision making.

1.2. Scope

The scope of this system is to provide user efficient working environment and more

output can be generated through this. This system provides user friendly interface resulting in

knowing each and every usability features of the system.

This system helps in tracking records so that past records can be verified through them and one

can make decisions based on the past records. This system completes the work in a very less time

resulting in less time consumption and high level of efficiency.

This system is developed in such a way that even a native user can also operate the system

easily. The calculations are made very quickly and the records are directly saved into databases

and the databases can be maintained for a longer period of time. Each record can be retrieved and

can be verified for the future transactions.

Also this system provides high level of security for data leaking as only admin people can access

the database no changes can be made in it until it verifies the user login id and password.

We also have operator login through which operator can sells the product but can’t make

changes in the database. Limited access is available to the operator.

2

1.3. Document overview

The remainder of this document is two chapters; the first provides a full description of the

project for the administrator, which lists all the functions performed by the system. The final

chapter contains details of each of the system functions and actions in full for the software

developers’ assistance. These two sections are cross-referenced by topic; to increase

understanding by both groups involved.

1.4. Web References

www.google.com,

www.roseindia.com

3

2.0 Overall description

For optimal sales and inventory management processes, you need robust functionality for

managing your logistics facilities. Support for inventory management helps you record and track

Products on the basis of both quantity and model no.Additional benefits of inventory

management include improved cash flow, visibility, and decision making.This software is user

friendly and hence easy to use.Employees can plan, enter, and document warehouse and internal

stock movements by managing goods receipts, goods issues, storage.

2.1 Requirements

Hardware Requirements:

Processor : Any Processor above 500 MHz.

Ram : 256MB.

Hard Disk : 40GB.

Input device : Standard Keyboard and Mouse.

Output device : VGA and High Resolution Monitor.

Software requirements:

Operating System : Windows Family.

Programming language: Java,J2EE(Hibernate,Struts)

Tools : Eclipse IDE

Pages developed using : Java Server Pages and HTML.

Techniques : Apache Tomcat , JDK 1.6 or higher

Web Browser : Microsoft Internet Explorer.

Data Bases : Oracle 11g

4

2.2. Functional requirements

Functional Requirements are those that refer to the functionality of the system, i.e., what

services it will provide to the user. Functional requirements capture the intended behavior of the

system. This behavior may be expressed as services, tasks or functions the system is required to

perform. In product development, it is useful to distinguish between the baseline functionality

necessary for any system to compete in that product domain, and features that differentiate the

system from competitors’ products, and from variants in your company’s own product

line/family. Features may be additional functionality, or differ from the basic functionality along

some quality attribute (such as performance or memory utilization)

A. INPUT/OUTPUT

1. System shall have a form to accept the customer details.

2. System shall have a form to accept the Product details.

3. System shall display transaction details.

4. System should provide facility for change in Product details and Price.

5. System should maintain the details about placing order/dispatch .

B. PROCESSING

1. System should automatically generate the bill.

C. ERROR HANDLING

1. Should report any errors on duplicate primary keys.

2. Should report any ‘Out of Range’ values on numeric fields

3. Should report any data type mismatches any field on the forms.

4. Should report on any ‘Invalid dates’.

5. Should report any violation of authorization of rights

6. Should report any Invalid Login errors

5

2.3. Non-functional requirements

There are requirements that are not functional in nature. Specifically, these are the constraints

the system must work within. The user and vendor must be registered in the application before

using the system. This Supplementary Specification lists the requirements that are not readily

captured in the use cases of the use-case model The Supplementary Specifications and the use-

case model together capture a complete set of requirements on the system. In general, functional

requirements define what a system is supposed to do whereas non-functional requirements define

how a system is supposed to be. Functional requirements are usually in the form of "system shall

<do requirement>", while non-functional requirements are "system shall be

<requirement>".Non-functional requirements are often called qualities of a system. Other terms

for non-functional requirements are "constraints", "quality attributes", "quality goals", "quality of

service requirements" and "non-behavioral requirements". Qualities, that is, non-functional

requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.

2. Evolution qualities, such as testability, maintainability, extensibility and scalability,

which are embodied in the static structure of the software system.

Usability:

. A system that has high usability coefficient makes the work of the user easier. This section lists

all of those requirements that relate to, or affect the usability of the system.

Design for ease of use:

The user interface of the the system architecture shall be designed for ease-of-use and shall be

appropriate for a computer-literate user community with no additional training on the System.

For the beginners it needs training on how to view the items and how to select and buy the

products.

Flexibility:

If the organization intends to increase or extend the functionality of the software after it is deployed, that

should be planned from the beginning; it influences choices made during the design, development,

testing, and deployment of the system. New modules can be easily integrated to our system without

disturbing the existing modules or modifying the logical database schema of the existing applications.

6

Integrity:

Integrity requirements define the security attributes of the system, restricting access to features or

data to certain users and protecting the privacy of data entered into the software. Certain features

access must be disabled to user such as modifying the details of companies which is the sole

responsibility of the administrator. Access can be disabled by providing appropriate login

screens for users and administrator separately.

Performance:

The performance is high . Whereas this application doesn’t need any external a resource hence

working with it is easy by just using the appropriate software which is compatible. And even the

result can be computed faster

Security:

It can be used by any user at a time it provides authentication to the user.

7

3.0. Analysis model for our project

Software process is a framework for the tasks that are required to build high-quality

software. Software engineers and their managers adapt the process to their needs and then follow

it. As it provides stability, one can control the software development. Processes that you adopt

depend on the software you’re building.

4. Design

System design is the process of applying various techniques and principles of defining a

system in sufficient detail to permit its physical realization. Software design is the kernel of the

software engineering process. Once the software requirements have been analyzed and specified,

the design is the first activity.

4.1 Introduction to UML

The Unified Modeling Language allows the software engineer to express an analysis

model using the modeling notation that is governed by a set of syntactic semantic and pragmatic

rules. A UML system is represented using five different views that describe the system from

distinctly different perspective. Each view is defined by a set of diagram, which is as follows.

User Model View

i. This view represents the system from the users perspective.

ii. The analysis representation describes a usage scenario from the end-users

perspective.

Structural model view

i. In this model the data and functionality are arrived from inside the system.

ii. This model view models the static structures.

Behavioral Model View

It represents the dynamic of behavioral as parts of the system, depicting the

interactions of collection between various structural elements described in the

user model and structural model view.

8

Implementation Model View

In this the structural and behavioral as parts of the system are represented as they

are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which the

system is to be implemented are represented.

UML is specifically constructed through two different domains they are:

UML Analysis modeling, this focuses on the user model and structural model views of

the system.

UML design modeling, which focuses on the behavioral modeling, implementation

modeling and environmental model views.

4.2 System design

Module Description:

1.Admin

In this module admin login only when the username and password are valid. If admin

login successfully then he provides other sub modules like registration, transaction, Product

details, Selling price and cost price

2. Employee details

In this module Employee want to access the details he has to login successfully then it

contains other sub modules. If the employee want to change the details i.e. changing password.he

can also sells the product

3. Product Information

Admin fill the all the product details like model number,company name etc.

9

4. Billing

In this module employee can sells the product available in Stock are and get the details of

the product. This module can see any one who accessing the application

4.3 Use case Diagram

Use case Diagrams represent the functionality of the system from a user’s point of view. Use

cases are used during requirements elicitation and analysis to represent the functionality of the

system. Use cases focus on the behavior of the system from external point of view. Actors are

external entities that interact with the system. Examples of actors include users like

administrator, bank customer …etc., or another system like central database.

3.4 Use case Diagram for Salesman

10

Checks Inventories

Dispatch order on timeSends InvoiceUpdates Records Customer

Login Id and Pwd

4.5 Detailed Use cases

4.5.1. Usecase1: functionalities of admin:

11

Tracks Order

salesman

<<include>>

1.1 Data Dictionary

1.1.1 Entity 1

LOGIN_DBT

Attribute Type Optional? Notes

<Attribute Name>

<Data type of the attribute>

<Y or N> <Explain any specific restrictions or rules applcable on this attribute>

admin

login

registration

Product detail

employee details

Setting cost and selling price

+enter username and password

provides

+performs

check

performs

12

Username Varchar2 N

Password Varchar2 N

Type Varchar N

Name Varchar N

Address Varchar2 N

Email_id Varchar2 N

phonoNo Number N

STOCK_DBT

Attribute Type Optional? Notes

modelNo Varchar2 N

company Varchar2 N

stockQty Number N

soldQTY Number N

purchasePrice Number N

priceToSell Number N

MODEL_DBT

Attribute Type Optional? Notes

modelNo Varchar2 N

company Varchar2 N

type Varchar N

13

HP Varchar N

stage Varchar2 N

discharge Varchar2 N

phase Varchar2 N

head Varchar2 N

size Number N

CUSTOMERINFO_DBT

Attribute Type Optional? Notes

billNO Number N

date Date N

custName Varchar2 N

address Varchar2 N

phoneNo Number N

email Varchar2 N

salesman Varchar2 N

billAmt Number N

totalAmt Number N

SOLDSTOCK_DBT

Attribute Type Optional? Notes

serialNo Number N

billNo Number N

modelNo Varchar2 N

date Date N

4.6 System Evolution

14

The objectives of this maintenance work are to make sure that the system gets into work all time

without any bug. Provision must be for environmental changes which may affect the computer or

software system. This is called the maintenance of the system. Nowadays there is the rapid

change in the software world. Due to this rapid change, the system should be capable of adapting

these changes. In our project the process can be added without affecting other parts of the

system. This system has been designed to favor all new changes. Doing this will not affect the

system’s performance or its accuracy.

The project has covered almost all the requirements. Further requirements and improvements can

easily be done since the coding is mainly structured or modular in nature. Improvements can be

appended by changing the existing modules or adding new modules. One important development

that can be added to the project in future is file level backup, which is presently done for folder

level.

15