Identifying software requirement
Introduction.
Purpose
The Online Shopping Mall (OSM) web application is intended to provide complete solutions for vendors as well as customers through a single get way using the internet as the sole medium. It will enable vendors to setup online shops, customer to browse through the shop and purchase them online without having to visit the shop physically. The administration module will enable a system administrator to approve and reject requests for new shops and maintain various lists of shop category
This document is meant to delineate the features of OSM, so as to serve as a guide to the developers on one hand and a software validation document for the prospective client on the other. Scope
Initial functional requirements will be: -
• Secure registration and profile management facilities for Customers
• Browsing through the e-Mall to see the items that are there in each category of products like Apparel, Kitchen accessories, Bath accessories, Food items etc.
• Adequate searching mechanisms for easy and quick access to particular products and services.
• Creating a Shopping cart so that customers can shop ‘n’ no. of items and checkout finally with the entire shopping carts
• Regular updates to registered customers of the OSM about new arrivals.
• Uploading ‘Most Purchased’ Items in each category of products in the Shop like Apparel, Kitchen accessories, Bath accessories, Food items etc.
• Strategic data and graphs for Administrators and Shop owners about the items that are popular in each category and age group.
• Maintaining database of regular customers of different needs.
• Shop employees are responsible for internal affairs like processing orders, assure home delivery, getting customer's delivery-time feedback, updating order's status and answering client's queries online.
• Feedback mechanism, so that customers can give feedback for the product or service which they have purchased. Also facility rating of individual products by relevant customers. Also feedback can be given on the performance of particular vendors and the entire mall as well.
• Adequate payment mechanism and gateway for all popular credit cards, cheques and other relevant payment options, as available from time to time.
For the previous paragraph, depicting the functions of the system, from the perspective of the various users of the system, the following colour codes has been used:
• RED for administrator
• BLUE for customer of the shopping mall
• GREEN for the employees.
Initial non functional requirements will be: -
• Secure access of confidential data (user’s details). SSL can be used.
• 24 X 7 availability
• Better component design to get better performance at peak time
• Advertisement space where it will effectively catch the customer’s attention and as a source of revenue.
In addition to the above mentioned points, due to the highly evolving nature of the project, the following are planned to be delivered if deemed necessary:
• Warehousing within the very ambits of the project
• More payment gateways.
• Dynamic price model by which prices can be changed based on demand and supply
• Dynamic Storefront: Each customer will have a web page personalized based on his or her recent purchases. This is the equivalent of having a unique storefront for each customer in hopes of drawing in as many return customers as possible.
This list is by no means, a final one. The final list will be dictated by implementation constraints, market forces and most importantly, by end user demands for whom this is being built.

Definitions, Acronyms and Abbreviations
• SLA: Service Level Agreement or SLA is a formal written agreement made between two parties, the service provider & the service recipient. It defines the term of engagement - the fundamental rules that will govern the relationship.
• EJB: Enterprise Java Beans.
• JAVA EE: Java Enterprise Edition 5 is a programming platform— part of the Java Platform-for developing and running distributed multi-tier architecture Java applications, based largely on modular software components running on an application server.
• HTTP: Hypertext Transfer Protocol is a transaction oriented client/server protocol between a web browser & a Web Server.
• HTTPS: Secure Hypertext Transfer Protocol is a HTTP over SSL (secure socket layer).
• TCP/IP: Transmission Control Protocol/Internet Protocol, the suite of communication protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. References
IEEE SRS Format Technologies to be used
Programming languages:
• JAVA EE: Java Enterprise Edition is a programming platform— part of the Java Platform-for developing and running distributed multi-tier architecture Java applications, based largely on modular software components running on an application server.
• HTML, XML: Hyper Text Markup Language and Extensible markup Language are the predominant markup languages for web pages. It provides a means to describe the structure of text-based information in a document and to supplement that text with interactive forms, embedded images, and other objects.
• JavaScript: A client side scripting language used to create dynamic web content and user interface.
Tools & Development Environment
• Apache Tomcat 6.0.18 Server: Apache Tomcat is a Servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the Java Server Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.
• ECLIPSE J2EE: Eclipse is a toolkit which is designed for the creation of complex projects, providing fully dynamic web application utilizing EJB’s. This consist of EJB tools , CMP ,data mapping tools & a universal test client that is designed to aid testing of EJB’s.
Overview
The rest of this SRS is organized as follows: Section 2 gives an overall description of the software. It gives what level of proficiency is expected of the user, some general constraints while making the software and some assumptions and dependencies that are assumed. Section 3 gives specific requirements which the software is expected to deliver. Functional requirements are given by various use cases. Some performance requirements and design constraints are also give. Overall Description
Product perspective
OSM is aimed towards the vendors who want to reach out to the maximum cross-section of customer and common people who can be potential customer. This project envisages bridging the gap between the seller, the retailer and the customer. OSM should be user-friendly, ‘quick to learn’ and reliable software for the above purpose. OSM is intended to be a stand-alone product and should not depend on the availability of other software. It should run on both UNIX and Windows based platform.

Product functions
User: Mall Administrator
Functions: The Mall Administrator is the super user and has complete control over all the activities that can be performed. The application notifies the administrator of all shop creation requests, and the administrator can then approve or reject them. The administrator also manages the list of available product categories. The administrator can also view and delete entries in the guestbook.
User: Shop Owner
Functions: Any user can submit a shop creation request through the application. When the request is approved by the Mall Administrator, the requester is notified, and from there on is given the role of Shop Owner. The Shop Owner is responsible for setting up the shop and maintaining it. The job involves managing the sub-categories of the items in the shop. Also, the shop owner can add or remove items from his shop. The Shop Owner can view different reports that give details of the sales and orders specific to his shop. The Shop Owner can also decide to close shop and remove it from the mall.
User: Mall Customer/Guests
Functions: A Mall Customer can browse through the shops and choose products to place in a virtual shopping cart. The shopping cart details can be viewed and items can be removed from the cart. To proceed with the purchase, the customer is prompted to login. Also, the customer can modify personal profile information (such as phone number and shipping address) stored by the application. The customer can also view the status of any previous orders, and cancel any order that has not been shipped yet.
User: Employees
• Functions: Purchase department under a Purchase manager to overlook purchasing activities if warehousing needs arise.
• Functions: Sales department under a Sales manager who will look after the sale of products and services, the most important activity.
• Functions: Accounts department under an Accounts manager to look after the accounting activities of the enterprise
User characteristics
• The user should be familiar with the Shopping Mall related terminology like Shopping cart/Checking out/Transaction etc.
• The user should be familiar with the Internet.
Constraints
• There is no maintainability of back up so availability will get affected.
• Limited to HTTP/HTTPS.
• Real-life credit card validation and Banking system is not implemented.
• No multilingual support Assumptions and Dependencies
• The details related to the product, customer, payment and service transaction provided manually.
• Administrator is created in the system already.
• Roles and tasks are predefined. Specific Requirements
This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section. Use-Case Reports
In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model or subset thereof, refer to or enclose the use-case report in this section. Make sure that each requirement is clearly labeled.] Supplementary Requirements
Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications which are applicable to this subsystem or feature should be included here, refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or refer to separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled. Supporting Information
The supporting information makes the SRS easier to use. It includes: a) Table of contents, b) Index, c) Appendices. These may include use-case storyboards or user-interface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.