SYSTEM REQUIREMENT SPECIFICATIONS
Existing System:
In current situation lot of medicine manufacturing companies maintain
their product details and employee details either manually or by using
computer. At the same time they maintain their suppliers and dealers details
also but they are not providing any interface to either suppliers or dealers to
interact with administrator of that manufacturing organization. Because of this
situation entire details must be maintained by administrator of that company only.
This is the major disadvantage in current scenario. To avoid this quandary we
are going to introduce a special portal called “Online Sedative”.
Proposed System:
This Project “Online Sedative”
is a solution to all Pharmacy companies to take the orders from its
distributors who are geographically distributed. This new system not only takes
the orders from distributors for Pharmacy companies but also facilities. The
administration, as well as the report generation for the firm. The basic structure of the system as follows.
This
project is a web-based project, the system maintains vendors, category of
products they are supplying, products under each category, discount, and
payment modes such as DD, Cheque, and online payment mode Credit Card. This system also maintains the order details,
to provide the valuable reports regarding sales to the organization whenever
they want. Here we are providing the
administration part too for the organization.
Virtually from any part of the world with out any difficulty our portal
is Launching a new web site with these benefits of internet they can provide
better and Cost effective services to distributors, not only that with this
kind of design they can Go for online shopping for other users.
Need
for Computerization
Computerization is absolutely necessary to facilitate or automate
various procedures and several transactions. Some salient features of
computerization are:
¨reduction in
processing time
¨data
security
¨reduced
redundancy & inconsistency
STUDY OF THE SYSTEM:
To provide flexibility to the users,
the interfaces have been developed that are accessible through a browser. The
GUI’S at the top level have been categorized as
- Administrative user interface
- The operational or generic user interface
The ‘administrative user interface’ concentrates on the consistent
information that is practically, part of the organizational activities and
which needs proper authentication for the data collection. These interfaces
help the administrators with all the transactional states like Data insertion,
Data deletion and Date updation along with the extensive data search
capabilities.
The ‘operational or generic user interface’ helps the end users of the
system in transactions through the existing data and required services. The
operational user interface also helps the ordinary users in managing their own
information in a customized manner as per the included flexibilities.
Functional Requirements:
Number of Modules
After careful analysis the system has been identified to have the
following modules:
1. Admin
module.
2. User
module.
3. Order Products
4. Reports Module.
1. Admin Module:
This is all about an
Administrator who will control this portal, admin is having full access
permeations like adding, deleting and modifying product details, customer
details, vendor details, category details and discount details. Administration
contains the following options.
¨
Product Administration:
By using this
functionality administrator can add product details and also can modify and
delete.
¨
Seller Administration: By using this functionality administrator can delete all
existing customer details.
¨
Vendor Administration:
By using this
functionality administrator can add vendor details and also can modify and
delete.
¨ Category
Administration:
By using this
functionality administrator can add category details and also can modify and
delete.
¨ Discount
Administration:
By using this functionality administrator can add discount details and
also can modify and delete.
2. User Module:
By using this module user
can order the products which are added by administrator by providing some
important information like DD or Credit card details. The options under User
Interaction are
F Signup
F Login
3. Order
products:
By
using this module users can give orders to the manufacturing companies by
providing their requirements along with credit card details.
4. Reports Module:
In this
module administrator will get different types of reports regarding customer
details, product details, vendor details, category details and discount on
products details etc. And this module is controlled by administrator only.
Software Engineering
Methodology:
Object
Oriented Analysis and Design (OOAD Standards)
Non-Functional Requirements:
Software requirements:
Operating System : Windows
Technology : Java/J2EE (JDBC, Servlets, JSP)
Web Technologies : Html, JavaScript, CSS
IDE :
MyEclipse
Web Server : Tomcat
Database : Oracle
Java Version : J2SDK1.5, Tomcat 5.5, Oracle 9i
Hardware requirements:
Hardware : Pentium based systems with a minimum of P4
RAM : 256MB (minimum)
Project Approach:
SDLC Methodology:
This document play a vital
role in the development of life cycle (SDLC) as it describes the complete
requirement of the system. It means for
use by developers and will be the basic during testing phase. Any changes made to the requirements in the future
will have to go through formal change approval process.
SPIRAL
MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement.
This model was not the first model to discuss iterative development, but
it was the first model to explain why the iteration models.
As
originally envisioned, the iterations were typically 6 months to 2 years
long. Each phase starts with a design
goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied
at each phase of the project, with an eye toward the end goal of the project.
The steps for Spiral Model can be
generalized as follows:
· The new system requirements are
defined in as much details as possible.
This usually involves interviewing a number of users representing all
the external or internal users and other aspects of the existing system.
·
A
preliminary design is created for the new system.
·
A
first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and
represents an approximation of the characteristics of the final product.
· A second prototype is evolved by a
fourfold procedure:
1. Evaluating the first prototype in
terms of its strengths, weakness, and risks.
2. Defining the requirements of the
second prototype.
3. Planning an designing the second
prototype.
4. Constructing and testing the second
prototype.
·
At
the customer option, the entire project can be aborted if the risk is deemed
too great. Risk factors might involved development
cost overruns, operating-cost miscalculation, or any other factor that could,
in the customer’s judgment, result in a less-than-satisfactory final product.
·
The
existing prototype is evaluated in the same manner as was the previous
prototype, and if necessary, another prototype is developed from it according
to the fourfold procedure outlined above.
·
The
preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
· The final system is constructed, based
on the refined prototype.
·
The
final system is thoroughly evaluated and tested. Routine maintenance is carried on a
continuing basis to prevent large scale failures and to minimize down time.
