srs on online billing and stocking management
TRANSCRIPT
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