<Stock Management System>
Software Requirements Specification (SRS)
Version 1.0
Submitted
By:
Yasir Javaed
mc090200982
Revision
History
Date (dd/mm/yyyy)
|
Version
|
Description
|
Author
|
1.0
|
Introduction of the project
|
Mc090402972
|
|
Inventory
Management system is an enterprise-wide discipline or the system apprehensive
with the recognition and tracking of Inventory Information Services inventory
and production line asset. Managing stock effectively is important for any
business, because without enough stock, production and sales will grind to a
halt. Stock control involves careful planning to ensure that the business has
sufficient stock of the right quality available at the right time. Stock can
mean different things and depends on the industry the firm operates in. It
includes:
|
Scope Of Stock Management
System
To
create direct principles for inventory control over belongings procure or
dispensed to the association. As I know that property consists of material
goods, furniture, fixtures and equipment. The elemental intention of this
strategy is to ensure that such items are properly recorded and valued in the
inventory systems, and defended alongside burglary or loss.
This article is meant to help scope stock management
needs of a project and find a method that meets the needs of the project, and
all parties involved, without adding undue administrative or technical
overhead, and that is (hopefully) efficient, user-friendly, and secure.
Functional and non Functional Requirements:
Functional Requirement:-
"A requirement specifies a function that a system or
component must be able to perform."
Functional requirements specify specific behavior or
functions, for example:
Characteristically
some functional requirement:
ü
Transaction corrections,
adjustments, cancellations
ü
Administrative functions
ü
Authentication
ü
Audit Tracking
ü
Certification Requirements
ü
Ropes the footage of Actual Cost
by Product
ü
Wires the soundtrack of Weighted Average Cost
by Product
ü
Supports the recording of FIFO
Cost by Product
ü
Supports Planning Identifier for
Make Only, Buy Only, or a Combined Value for On-Going Make/Buy Analysis
ü
Supports Identification of
Multiple Vendors and Associated Information per Product (See Purchasing
Section)
ü
Supports Online Explosion of
Multi-Level and Indented BOM's
ü
Supports the Phantom BOM's
Non functional Requirements:-
"A non-functional requirement is a statement of how a
system must behave, it is a constraint upon the systems behavior."
In systems engineering and requirements engineering, a
non-functional requirement is a requirement that specifies criteria that can be
used to judge the operation of a system, rather than specific behaviors. This
should be contrasted with functional requirements that define specific behavior
or functions. The plan for implementing functional requirements is detailed in
the system design. The plan for implementing non-functional requirements is
detailed in the system architecture.
Examples
A system may be required to present the user with a display
of the number of records in a database. This is a functional requirement. How
up-to-date this number needs to be is a non-functional requirement. If the
number needs to be updated in real time, the system architects must ensure that
the system is capable of updating the displayed record count within an
acceptably short interval of the number of records changing.
Other examples:
• Accessibility
• Audit and
control
• Availability
(see service level agreement)
• Backup
• Capacity,
current and forecast
• Certification
• Compliance
• Configuration
management
• Dependency
on other parties
Use Case Diagrams:
Ø
Use Case:
A use case describes a sequence of actions that provide
something of measurable value to an actor and is drawn as a horizontal ellipse.
Ø
Actors:
An actor is a person, organization, or external system that
plays a role in one or more interactions with your system. Actors are drawn as
stick figures.
Ø
Associations:
Associations between
actors and use cases are indicated in use case diagrams by solid lines. An
association exists whenever an actor is involved with an interaction described
by a use case. Associations are modeled
as lines connecting use cases and actors to one another, with an optional
arrowhead on one end of the line. The arrowhead is often used to indicating the
direction of the initial invocation of the relationship or to indicate the
primary actor within the use case. The
arrowheads are typically confused with data flow and as a result I avoid their
use.
Limitations of Use Cases:
There are some limitations of
the use case that is
Usability
Color blind people should not have any difficulty in using
the system color coding should take care of common forms of color blindness.
Presentation
Authorization should be
completed within 1 minute 90% of the time.
Average authorization
confirmation time should not exceed 30 seconds.
Access
System should be accessible
over the internet – hidden requirement – security.
Because of this shortcoming,
use cases must be amplified by supplementary information.
Usage Scenarios:-
ü Login:
1. Use Case Title
|
Login |
2.Abbreviated
Title
|
Login
|
3.Use Case Id
|
(A).
|
4.Actors
|
Customer
|
5.Description
To interact with the system, the Scheme will authenticate
its registration with this system. It also defines the actions a user can
perform in this scheme.
|
|
5.1.Pre
Conditions: Customer or the user must have proper client
installed on user terminal
|
|
5.2.Task
Sequence:
|
|
5.3.Post
Conditions:
System transfer control to customer main screen to proceed
further actions
|
|
ü
Check Account:
1.Use Case Title
|
Check Account |
2.Abbreviated
Title
|
Check Account
|
3.Use Case Id
|
1
|
4.Actors
|
Customer
|
5.Description
System will show customer current purchased Items,
transaction history.
|
|
5.1.Pre
Conditions: Customer must be login to the system
|
|
5.2.Task
Sequence:
1.
System will display all Customer
history
|
|
5.3.Post
Conditions:
1.
Customer will be on member status
screen
|
|
ü
Search ITEM:
1.Use Case Title
|
Search Item |
2.Abbreviated
Title
|
Search Item
|
3.Use Case Id
|
2
|
4.Actors
|
Customer
|
5.Description
Search item makes it easy to search for
product list.
With this search cohort, customer can specify several
search criteria. For example, product name, brand name, selling price, etc.
|
|
5.1.Pre
Conditions: User must be login
|
|
5.2.Task
Sequence
1.
System will show searching screen
2.
Customer enter required information
a.
It can be customer name, product
specificatoin etc
3.
By pressing search button system will
list down all searching results
|
|
5.3.Post
Conditions:
1.
Customer can view his desire results
|
|
ü
Maintain Account:
1.Use Case Title
|
Maintain Account |
2.Abbreviated
Title
|
Maintain Account
|
3.Use Case Id
|
3
|
4.Actors
|
Sales manager
|
5.Description
From this use case system will maintain inventory
|
|
5.1.Pre
Conditions:
Customer must be login with its sales account
|
|
5.2.Task
Sequence
1.
System will open Inventory main form
|
|
5.3.Post
Conditions:
System can have updated system inventory position.
|
|
ü
Manage Customer Purchase
Order:
1.Use Case Title
|
Manage Customer
Purchase Order
|
2.Abbreviated
Title
|
Manage Customer Purchase Order
|
3.Use Case Id
|
4
|
4.Actors
|
Sales manager
|
5. Description:
From this use case
sales manager can manage purchase orders.
|
|
5.1.Pre
Conditions:
Customer must be logged on with sales account
|
|
5.2.Task
Sequence
1.
System show all users registered with
the system.
2.
Sales manager will select any customer;
system will list down all assigned and unassigned permission of current
customer.
3.
Sales manager can grant or revoke any
securities from this screen
|
|
5.3.Post
Conditions:
Customer will be restricted or granted permission
|
|
ü
Approve the order:
1.Use Case Title
|
Approve the order |
2.Abbreviated
Title
|
Approve the order
|
3.Use Case Id
|
5
|
4.Actors
|
Sales manager
|
5.Description
This use case is used to approve the customer purchase
order on some Items like reserved, for internal use only or blocked due to
any reason.
|
|
5.1.Pre
Conditions:
Customer
must be logged
|
|
5.2.Task
Sequence
1.
System show all items entered in the
scheme
2.
Customer will select any item; system
will list down all approve and unapproved orders of current item.
3.
Customer can endowment or cancel any
securities from this screen
|
|
5.3.Post
Conditions:
Items will be secure or approved
|
|
ü
Issue ordered Item:
1.Use Case Title
|
Issue ordered Item:
|
2.Abbreviated Title
|
Issue ordered Item:
|
3.Use Case Id
|
6
|
4.Actors
|
Sales manager
|
5.Description
This use case is used to issue items to
the customer.
|
|
5.1.Pre
Conditions:
System must be logon to the system
|
|
5.2.Task
Sequence
1.
System display items available for the
issuance
2.
Customer enters items and its member
code
3.
System will mark this item as issued
item
|
|
5.3.Post
Conditions:
Items will be booked
till issuance allowed.
|
|
v Encryption
Encryption is the ability to
encode files or stocks to be managed in such a way that fraudulent interception
of the files does not allow perpetrators to be able to read and open their
contents. Encryption is particular where confidentiality and classified
information is to be shared.
v Web-Based/Software
Whether the stock management
technology is web-based or software-based., most management technologies by way
of their definition are software-based as being so they supposedly provide for
greater privacy and control over the materials being made available.
v Synch
features
The ability to synchronize
files and folders shared with a selected group of customer or computers. An
automatic feature checks every time a group member goes online whether he/she
has all the files (and the latest revisions) available to everyone else.
v Max file
size
Limitations are there on the
number and size of files that can be managed or shared to the customers.
Remote Access
to specific files
Some stock management tools
provide the ability to share files by enabling one or more computers to be
accessed remotely so that certain files located on those machines can be
accessed remotely.
No comments:
Post a Comment