Table of content

1. Introduction…………………………………………………………………………3
2. System Introduction.............................................................................................. ......3
3. Problems In existing system………………………………………………………..3
4. Scope of Proposed System…………………………………………………………4
5. Feasibility Study…………………………………………………………………..4
6. Technical Feasibility……………………………………………….4
7. Operational Feasibility…………………………………………………………….5
8. Economic Feasibility…………………………………………………………..5
9. Operating Environment – Hardware and Software………………………………..6
10. Hardware Requirements…………………………………………………………6
11. Software Requirements……………………………………………………………..7
12. Proposed System
13. Objectives
14. User Requirements
15. FUNCTIONAL REQUIREMENTS
16. INPUT/OUTPUT
17. B. PROCESSING
18. C. ERROR HANDLING
19. NON-FUNCTIONAL REQUIREMENTS
20. ANALYSIS &DESIGN
21. Use case Diagram
22. Use Case Diagram for Customer
23. Class Diagram for a customer order
24. Sequence diagram
25. Test Procedures and Implementation
26. Introduction
27. Testing principles
28. White box testing
29. Black box testing
30. Testing Process
31. Menu Tree
32. User Manual
33. Menu Explanation
34. Start Up screen
35. Order Entry
36. Shipment Details
37. Accounts Department
38. Machine Installation
39. Commercial Group
40. Order Enquiry
41. Future Scope
42. Benefits15
43. Drawbacks and Limitations15
Conclusion……………….16

© University of Education 1
Software Requirement Specification

System Introduction
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 materials on the basis of both quantity and
value.
Warehouse inventory management functions cover internal warehouse movements
and storage.
Using this software we can reduce costs for warehousing, transportation, order
fulfillment, and material handling – while improving customer service.
You can significantly improve inventory turns, optimize the flow of goods, and
shorten routes within your warehouse or distribution center. 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, picking and packing, physical
stock transfers, and transfer postings.

Problems In existing system

As we know manual system are quite tedious ,time consuming and less efficient
and accurate in comparison to the computerized system.
So following are some disadvantages of the old system:

 Time consuming

 Less accurate

 Less efficient

 Lot of paper work

 Slow data processing

 Not user friendly environment

 Difficult to keep old records

© University of Education 2
Scope of Proposed System

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 naïve 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 take orders but can’t make
changes in the database. Limited access is available to the operator.
Feasibility Study
As we know each and every project needs to have a feasibility study for the
complete understandability of the project. We will consider 3 types of feasibility
study they are technical feasibility, operational feasibility and economical
feasibility.
Technical Feasibility
This new system requires 6 fully trained people to run the system perfectly. 1
admin person to maintain database n other 5 to handle the system interface and
order making things.
As our existing system is purely manual, so we need a onetime investment of Rs 4
Lacs for the purchase of 6 computers, 5 invoice printers, a laser printer, AC and
networking etc. It requires apprx. 10 Lacks PA as a operating cost.
With the above details our system is technically feasible as after investing 14 Lacs
in a year, the company is still saving Rs 15 Lacs PA.

Operational Feasibility
The new solution is feasible in all sense but operationally it is not. The new system
demands the expulsion of at least 15 people from the company. It creates an
environment of joblessness and fear among the employees. It can lead to an

© University of Education 3
indefinite strike in the company also. So the management must take corrective
actions prior in advance in order to start the further proceedings.

Economic Feasibility
With the manual system the operating cost of the system is about 60 Lacks P.A.
This cost comprises salary of 25 people, stationary, building rent, electricity, water,
telephone etc. But with the new system this reoccurring cost comes out to be about
20 Lacks P.A. Hence the new system is economically feasible.

Operating Environment – Hardware and Software

Hardware Requirements
Processor: Pentium 4 or more for optimum performance
RAM: Recommended 512MB
Hard Disk: Minimum 20GB
Software Requirements
Operating System - Certified Distribution of WINDOWS
Visual studio2017
Microsoft SQL server 2014

Proposed System

Objectives
The main objective of this system is to keep records of the complete inventory.
It support for inventory management helps you record and track materials on the
basis of both quantity and value.
It improves cash flow, visibility, and decision making.
For warehouse management, you can track quantity and value of all your materials,
perform physical inventory, and optimize your warehouse resources

User Requirements

FUNCTIONAL REQUIREMENTS

INPUT/OUTPUT
System shall have a form to accept the customer details.
System shall have a form to accept the Plant details.
System shall display transaction details.
System shall provide search facility on customer name, Order Placed, date of order,
date of order dispatch, date of transaction, transaction amount, credit card no etc.
© University of Education 4
System should provide facility for change in address/name.
System should maintain the details about placing order/dispatch or order i.e, order
status

B. PROCESSING
1. System should automatically generate the bill.
2. System should inform the pending order and make changes if the order is
dispatched.

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

NON-FUNCTIONAL REQUIREMENTS

All user manuals should be provided in the necessary format

Application should support 5 simultaneous users.
Transaction should be completed within 1/5th of second
There will be backup procedure to maintain records.

© University of Education 5
ANALYSIS &DESIGN
Use case Diagram

Login Id and Pwd

Checks Inventories

<<include>>

Tracks Order

Dispatch order on time

Supplier Customer

Sends Invoice

Updates Records

© University of Education 6
 Use Case Diagram for Customer

Studies
Requirements

Make list of requirements

Places the Order

Makes payment
Customer Clerk

Invoice

Send GRN

Class Diagram for a customer order

© University of Education 7
Customer Order
Cust_Id Order_no
Name Ordercredate
Addr1 Order_status
Addr2 Shipment_dat
Cust_city e
Pincode Challan
Addcust()
Updatecust() calcBilltotal()
Getcustdet() Payment calctotalweig
Amount ht()
Payment
date
Makepayme
nt()
Getinvoice()

Ordetdetail Material
Orderno
Materialqty Materialcode
Materialvalue Plantcode
Stckqty
Caclsubtotal
calcweight Getpriceforqty()
Credit Cheque
Number Chqno
Type Bankname
Expirydate Bankid
validating validating

GRN
Recivedqty
Damaged
Rejected

Rejectgood()
Description()

Sequence diagram

© University of Education 8
Supplier Transaction Customer Invoice

Log In

Validate

Tracks order

Places order

Takes customr details

Fill Order details

Makes Payment

Dispatch Order

Send order details

Add new entry

Send Invoice
Log Out

Send GNR

Test Procedures and Implementation

Introduction

© University of Education 9
Testing presents an interesting anomaly for the software engineer. During earlier software
engineering activities, the engineer attempts to build software from an abstract concept to a
tangible product. Now comes testing. The engineer creates a series of test cases that are intended
to “demolish” the software that has been built. In fact, testing is the one step in the software
process that could be viewed (psychologically, at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing requires that the developer
discard preconceived notions of the “correctness” of software just developed and overcome a
conflict of interest that occurs when errors are uncovered.

If testing is conducted successfully (according to the objectives stated previously), it will

uncover errors in the software. As a secondary benefit, testing demonstrates that software
functions appear to be working according to specification, that behavioral and performance
requirements appear to have been met. In addition, data collected as testing is conducted provide
a good indication of software reliability and some indication of software quality as a whole. But
testing cannot show the absence of errors and defects, it can show

Only that software errors and defects are present. It is important to keep this (rather gloomy)
statement in mind as testing is being conducted.

Testing principles

Before applying methods to design effective test cases, a software engineer must understand the
basic principle that guide software testing:
All tests should be traceable to customer requirements
Tests should be planned long before testing begins
80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all
program components. The problem, of course, is to isolate these suspect components and to
thoroughly test them.
Testing should being “in the small” and progress toward testing “in the large”.
Exhaustive testing is not possible
To be most effective an independent third party should conduct testing
A rich variety of test case design methods have evolved for software. These methods provide the
developer with a systematic approach to testing. More important, methods provide a mechanism
that can help to ensure the completeness of tests and provide the highest likelihood for
uncovering errors in software.

Any engineered product (and most other things) can be tested in one of two ways:
Knowing the specified function that a product has been designed to perform, tests can be
conducted that demonstrate each function is fully operational
While at the same time searching for errors in each function; (2) knowing the internal

© University of Education 10
Working of a product, tests can be conducted to ensure that “all gears mesh,” that is, internal
operations are performed according to specifications and all internal components have been
adequately exercised. The first test approach is called black box testing and the second, white-
box testing.

Testing performed were:

 Unit Testing
 Integration Testing
 Database Testing
 Recovery Testing
 Functionality Testing
 Sanity Test
 Compatibility Testing
 Load Testing
 System Testing
 Performance Testing
 user Acceptance Testing

White box testing

Sometimes called glass-box testing is a test case design method that uses the control structure of
the procedural design to derive test cases. Using white-box testing methods, the software
engineer can derive test cases that (1) guarantee that all independent paths within a module have
been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3)
execute all loops at their boundaries and within their operational bounds, and (4) exercise
internal data structures to ensure their validity.
White-box testing of software is predicated on close examination of procedural detail. Providing
test cases that exercise specific sets of conditions and/or loops tests logical paths through the
software. The “status of the program” may be examined at various points to determine if the
expected or asserted status corresponds to the actual status. Basis path testing is a white-box
testing technique first proposed by Tom McCabe. The basis path method enables the test case
designer to derive a logical complexity measure of a procedural design and use this measure as a
guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are
guaranteed to execute every statement in the program at least one time during testing.

In this system, the system was tested for the calculation matters were the data provided for
giving the right output or not. If wrong data was provided then what it is throwing error or
accepting.

Black box testing

Also called behavioral testing, focuses on the functional requirements of the software. That is,
black box testing enables the software engineer to derive sets of input conditions that will fully
exercise all functional requirements for a program. Black box testing is not an alternative to

© University of Education 11
white-box techniques. Rather, it is a complementary approach that is likely to uncover a different
class of error than white-box methods. When computer software is considered, black box testing
alludes to tests that are conducted at the software interface. Although they are designed to
uncover errors, black-box tests are used to demonstrate that software functions are operational,
that input is
Properly accepted and output is correctly produced and that the integrity of external information
is maintained. A black-box test examines some fundamental aspect of a system with a little
regard for the internal logical structure of the software. Black-box testing attempts to find errors
in the following categories: Incorrect or missing functions, Interface errors, Errors in data
structures or external database access, Behavior or performance errors, and Initialization and
termination errors. By applying back-box techniques, we derive a set of test cases that satisfy the
following criteria:
Test cases that reduce, by a count that is greater than one, the number of additional test cases that
must be designed to achieve reasonable testing and
Test cases that tell us something about the presence or absence of classes of errors, rather than an
error associated only with the specific test at hand.
White-box testing should not, however, be dismissed as impractical. A limited number of
important logical paths can be selected and exercised. Important data structures can be probed
for validity. The attributes of both black and white box testing can be combined to provide an
approach that validates the software interface and selectively ensures that the internal workings
of the software are correct.
Black box testing for this system was done to check the internal testing i.e, the system is working
properly in each case or no. What kind of errors are there in database design.
Testing Process
The testing process can be shown as:

Levels of testing Test Test

Plan Procedures

Test Case
Specification

Yes

Test Case
Execution
Is Error Test Case
Uncovered Analysis
?
No

Test Report

© University of Education 12
 Menu Tree

Main Page

File View Tools Master Help Logout Exit

Controls
Calcul
Transaction Toolbar ator System
Screen Customer Requirement
s

Reports
Status Notepad About
Bar Plant

Exit
Project Code
report
Material

State

© University of Education 13
User Manual
Menu Explanation
Start Up screen
The first menu item of the System screen is transaction screen this screen is the main screen it
has all the menu items which help to take order and maintain it in database. The 1 st tab is “order
entry” this screen will be disabled initially to make an order operator has to click on order entry
button at the right hand side of the screen
Order Entry
Once that button is clicked the screen is activated and orderno.,oder creation date and order
status are auto generated search cust_code by clicking search button and retrieve rest of the
customer details. If the customer is new then administrator has to add new customer into
database which is only accessed by admin person operator are not given those rights.

Once customer details are retrieved click calculate order value button this this will take to the
order detail screen where order no is auto generated material code is selected and item qty is to
be filled and by clicking on calculate the total is calculated n thus the order is placed

To add all details in transaction screen refresh button should be clicked

Customer ref number is also have to be filled by operator/admin n then to go on the next screen
click on verified

Shipment Details
The shipment details are already auto filled by the system operator has to provide the transporter
name only

Accounts Department
Accounts dept is also auto filled admin has to verify all the details and make order date
according to convenience
Machine Installation
Next screen is machine installation here the engineer who gonna install the machine is to be
given.
Commercial Group
In commercial group screen all the payment details are to be filled accordingly once customer
makes the payment

Thus the records has been created.

Order Enquiry
In the next tab we can see the order status.
Admin authority

Handling databases is in the power of the admin person only

So all customer databases and material database and all master tables are to be handled by the
admin person only.

© University of Education 14
These screens are detailed screens so no specific description is needed for the same.

Proposed Enhancements
Future Scope

 The scope of the project includes that what all future enhancements can be done in this
system to make it more feasible to use

 Databases for different products range and storage can be provided.

 Multilingual support can be provided so that it can be understandable by the person of

any language.

 More graphics can be added to make it more user-friendly and understandable.

 Manage & backup versions of documents online.

Benefits
 Manages Track sales

 Manages contacts

 Manages accounts

 Manages opportunities

 Track product issues

 Manage issue priority

 Track product features

 Manage product life cycle

Drawbacks and Limitations

The system is not capable of handling more than 6 users at a time.

Some keywords in system are difficult to understand so the admin n operator person should
understand them thoroughly to use the system accurately.
Graphs could have been added in order to get the records more clearly.

© University of Education 15
Conclusion
While developing the system a conscious effort has been made to create and develop a software
package, making use of available tools, techniques and resources – that would generate a proper
System While making the system, an eye has been kept on making it as user-friendly, as cost-
effective and as flexible as possible. As such one may hope that the system will be acceptable to
any user and will adequately meet his/her needs.As in case of any system development processes
where there are a number of shortcomings, there have been some shortcomings in the
development of this system also. The project is still under modification.

© University of Education 16