Anda di halaman 1dari 5

EXPERIMENT NO.

1
AIM: To prepare an SRS document for the project Shopping Mall Management System. OBJECTIVE:
SRS document accomplishes the following objectives: 1. Problem Breakdown:The SRS document divides the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information. places borders around the problem, solidifies ideas, and help breakdown the problem into its component parts in a orderly fashion. 2. Input to Design Specification:The SRS serves as the parent document subsequent documents such as the software design specification and statement of work. Hence the SRS should contain sufficient delis in the functional system requirements so that a design solution should be made. 3. Feedback to Customers:The SRS acts as a contract between eh customer and the development organization. it is the customers assurance that the development organization understand the issuers or problems to be solved and the software will be able to solve those problems. Hence the SRS should be written in a natural language, in an unambiguous manager that may also include charts, data flow diagrams, decision tables etc. 4. Production Validation Check:The SRS acts as the parent document for testing and validation strategies that will be applied to the requirements for verifications

THEORY:
The SRS document generates all necessary requirements for project development. To derive the requirement, we need to have a clear and thorough understanding of the products to be developed. This is prepared after detailed communication with project team and the customer. An SRS clearly defines the following: External interfaces of the system: They identify the information which is to flow from and to the system. Functional & Non-Functional Requirements of the system: They stand for the finding of run-time requirement.

Design Constraints.

CHARACTERISTICS OF A GOOD SRS: An SRS document should be correct, unambiguous, complete and consistent. The SRS should address the software product, not the process of producing the software product. A properly written SRS limits the range of valid designs, but does not specify a particular range. An SRS must be verifiable. An SRS is verifiable, if and only if, every requirement stated therein is verifiable. A requirement is verifiable, if and only if, there exist some finite cost effective process with which a person or machine can check that the software product meets the requirement.

SRS DOCUMENT FOR SHOPPING MALL MANAGEMENT: 1. INTRODUCTION 1.1. PURPOSE: The purpose of the SRS is to specify the requirements of the software application on shopping mall. This SRS provides a complete description of all the operations of this software. 1.2. SCOPE: The system is supposed to customize the activities required to be carried out for updating the stock and details of the products. Details are verified by the system. The system also checks if the products are expired. The details are then stored in the database server for future reference. 1.3. INTENDED AUDIENCE: The intended audience is developers, customers, testers of this application and document writers. 1.4. ADDITIONAL INFORMATION: This software is designed to run on a standalone machine. 1.5. REFERENCES: The SRS document created in the appendix follows IEEE Guide to Software Requirement Specification(Std. 830-1998) www.sourcelinecode/srsex1.doc 1.6. OVERVIEW:

This document provides details of functional and non-functional requirements of proposed system under headings of Overall Description, System Requirement and Analysis, Supplementary Requirements and all other non-functional requirements. 2. OVERALL DESCRIPTION 2.1. PRODUCT PERSPECTIVE: This product is a new and self-contained product which is designed to ease the tasks related to shopping for both, managers and customers.

2.2.

PRODUCT FUNCTIONS: The following are the functions performed by this software. Login Purchasing Items Billing Generating reports

2.3.

USER CLASSES AND CHARACTERISTICS: There are 2 kinds of users for the proposed software Manager: He will oversee all the functions of the project. Customers: They will provide login details and select the items to be purchased from the shopping mall.

2.4.

OPERATING ENVIRONMENT: This application will be operated using MS Access database and VB 6.0 in the front end.

2.5.

USER ENVIRONMENT: Any version of Windows OS can be used for running the software. Pentium 4 processor with 80GB hard disk is required.

2.6.

DESIGN/IMPLEMENTATION CONSTRAINTS: The system cannot handle a very large amount of data and the response time is moderate.

2.7.

ASSUMPTIONS AND DEPENDENCIES: The database maintaining details of customer,employee and products has already been created and information is available for use. Backups of the database are periodically taken to avoid any accidental loss of information.

3. EXTERNAL INTERFACE REQUIREMENTS 3.1. USER INTERFACES: The GUI is designed using VB 6.0. The user should have provision to go back to the home page from any other page.

3.2.

HARDWARE INTERFACES: To printer.

3.3.

SOFTWARE INTERFACES: None.

3.4.

COMMUNICATION PROTOCOLS & INTERFACES: None.

4. SYSTEM FEATURES 4.1. Login(Security Function) 4.1.1. A customer or manager with valid user-id and password can login. 4.1.2. Successful login will enable them to use other features of the system. 4.2. Purchasing Items 4.2.1. The customer can select the items to be purchased from the available items. 4.2.2. Generation of a bill. 4.3. Billing

4.3.1. A bill will be generated for the items to be purchased by the customer. 4.3.2. Bill with the final amount. 4.4. Generating Reports 4.4.1. System will generate reports on transactions in the shopping mall. 4.4.2. Generation of reports.

5. OTHER NON-FUNCTIONAL REQUIREMENTS 5.1. PERFORMANCE REQUIREMENTS: The software should give equally good performance in computers with different configurations. 5.2. SAFETY REQUIREMENTS: In case of system failure, data should not be lost. 5.3. SEQURITY REQUIREMENTS: Customers and managers with valid user-id and password should only be allowed to avail of the software failure.

5.4.

SOFTWARE QUALITY ATTRIBUTES: The software should be reliable,adaptable and portable.

5.5.

PROJECT DOCUMENTATION: Design manual.

5.6.

USER DOCUMENTATION: Operations manual.

CONCLUSION: Thus, the SRS document was successfully prepared.