1.

INTRODUCTION
1.1 Purpose

Requisition management is the process of creating, processing, authorizing, and tracking

purchase requests within an organization. The purpose of this website is to once a valid
need is identified, a formal request is initiated, typically using purchase requisition form. The
purchase request is then validated by the initiator’s manager and the procurement team to
control spend and prevent potential frauds. A requisition, in procurement, is a request for
goods or services made by an employee to the person or department in a company that is
responsible for purchasing. If the request is approved, that entity will submit a purchase
order (PO) to a supplier for the goods or services.

1.1 Document Conventions

This document is available in Microsoft Word format or PDF format contains docx to facilitate
access by the users. We use various conventions in text to help more quickly identify special
terms.

FONT-Arial and Times.

BOLD- Bold interface indicates the terms that are defined in the text or terms that appears in
the glossary or both.

ITALIC-It is used to label and recognize the diagrams.

UPPERCASE-It has been used to emphasize the section headings.

LOWERCASE-It has been used to emphasize sub-section headings.

HIGHLIGHT-Highlighting is to pint out words in the glossary.

UDERLINE- It is mainly for the URLs.

1.2 Intended Audience and Reading Suggestions

The SRS for this system is intended for Development Teams.

It has been organized approximately in order of increasing specificity.

Associated organizations may review the document to learn about the project and to
understand the requirements.

The developers and project managers need to be familiar with the SRS.

Testers need an understanding of the system features to develop meaningful test cases and
give useful feedback to the developers.

1.4 Product Scope

This project will consist of creating the tool for automated orders, purchase, sale, payment,
and receipt. It will generate the reports about inventory and ledger to control inventory flow
and party ledger. It will enable party to setup order, and administrator module will enable to
approve or reject the request, and maintain various lists of shop category.

1.5 References

2.

Overall Description
2.1 Product Perspective

The software product being developed is for online requisition management system which
functions as online portal for buy required stuffs. The requisition management website will
serve two areas mainly admins and clients. Since this system will be a web based
site/application a proper internet connection will be needed for viewing and interacting with
its contents. The website is developed with the intention to ease the work, decreasing paper
work and flourishing E-Commerce. The website is completely user friendly with different
language translation, loan facility, price analysis etc. This will be just a tap away for suppliers
and the buyers.

2.2 Product Functions

Online requisition management system contains the following key features.

 Homepage
 Visitor (SIGNUP/LOG IN)
 Updating admin information
 Updating supplier information
 Updating price and availability information
 Transaction Details
 LOG OUT

2.3 User Classes and Characteristic

Expected user (client) scope is anybody who has an internet connection. The application
does not require any extra knowledge or skills other than basic browsing experience. Any
user can search the contents in the website and open and use it to buy the required product.

2.4 Operating Environment

The server-side components of the software system must operate within a Linux operating
system environment.

The client-side components of the software system must operate within common web
browser environments using Secure Sockets Layer (SSL) / Transport Layer Security (TLS)
cryptographic protocols at a minimum encryption level of 128 bits. The minimum set of
browsers that must be supported is:

1. Google Chrome
2. Microsoft Internet Explorer
3. Mozilla Firefox
2.5 Design and Implementation Constraints
Developers may implement the QDR using a data store to curate data and template
information. All QDR and administrative services must be available over a RESTful API. The
QDR must be able to curate data collected in batches from the Industrial-Equipment
Network. At a predetermined time each calendar day, the QDR must process all curated
data and populate a list of available elements for query. Setup and maintenance of the QDR
application are the responsibility of the customer. Setup and maintenance include:
installation, hosting, host-security configuration, and administration. There are no additional
constraints on the VDS other than any defined for an application that executes the MT
Connect Agent in the standard documentation.

2.6 User Documentation

Any user of the software system is the target audience for user documentation generated
about the software system. A range of short document types (e.g., guidelines, tutorials, and
frequently asked questions) in Hypertext Markup Language (HTML) and/or Portable
Document Format (PDF) format must describe the use of the software system.

2.7 Assumptions and Dependencies

 Assumptions:
 Any user with basic internet knowledge can use it independently since it is web-
based software.
 It will be user friendly software.
 It will provide unlimited searching criteria for registered as well as unregistered
users.
 It will be a time saving as well as secure system.

 Dependencies:

 Only the registered user can add and remove any particular listings of product.
 In case of any invalid user id or password, login cannot be done.
 Without proper registered profile user cannot perform transactions.

3.
External Interface Requirements

3.1 User Interfaces

 The interface should be completely user friendly so that the

client can use this system independently.
 GUI should be designed in a concentrated manner so that
it attracts user’s attention.
 Help desks numbers and email id should be there for
user’s convenience.
 Proper error messages should be displayed in case of any
irregular syntax.
3.2 Hardware Interfaces
All server-side components must execute on server-class computers. All client-side
components must execute on workstation-class and personal-class computers.

3.3 Software Interfaces

1. Operating System: Windows XP / 7 / 8 / 8.1 / 10, Mac OS, Linux.

2. Web Server: IIS Server.
3. Web Browser: IE 4, Firefox, Chrome or others.

3.4 Communication Interfaces

1. Main communication protocol over the internet Hyper Text Transfer Protocol (HTTPs)
will be used.
2. TCP /IP protocol will be used as a backend of HTTPs i.e., for the intranet
communication.
3. A web browser such as IE 6.0 or equivalent.