|
02/02/08 Software Requirements Specifications1.0 Introduction1.1 Purpose of this Document
The purpose of this document is to describe the functional and performance requirements to create the Parking Suite. The Suite is a database of cars parked at Diamond coupled with an easy to use web interface.
1.2 Scope of the Development Project
Team Diamond Cutters will develop web application software. It will consist of two parts; the Microsoft Access Database, and the web application. The application will be a user friendly interface while the database will hold all the customers information. With this robust system, the valet's will be able to predict their days workload and keep track of where all the customers cars are parked.
1.3 Definitions, Acronyms, and Abbreviations
Parking Suite - The application that encompassed the web user interface and the background Microsoft Access database.
Packet - A container valets use to hold all the information of a customer and the customer's car
1.4 References
- Core Servlets and JavaServer Pages, Vol.1 Core Technologies, Second Edition by Marty Hall, Larry Brown
- GlassFish Documentation
https://glassfish.dev.java.net/
1.5 Overview of Document
The first section is to provide enough information for the user to see the usefullness of the Parking Suite. The second section is a technical overview of the project; this section will help the developer understand how the Suite should run and help identify important requirements.
2.0 General Description2.1 User Persona's and Characteristics
- Valet Customer - This is a person who brings their car into Diamond wanting valet service. They are in need of a speedy process so they can get to the airport as quickly as possible.
- Valet Employee - The valet needs the system to report his/her current workload to anticipate busy times.
2.2 Product Perspective
This product consists of a browser user interface and a back-end database server. Administrators will have the ability to login online. The server will be put on a Microsoft Windows XP system using Microsoft Access.
2.3 Overview of Functional Requirements
- Input Info - Allows users to input information about cars parked
- Update Info - Allows users to edit information about cars parked
- View Info - Allows users to view current data in database respective to given needs
- Archive Data - Functionality for keeping records of past customers
2.4 Overview of Data Requirements
- Input - The input will given by valets as packets.
- Output - The output will be user requests of the database
2.5 General Constraints, Assumptions, Dependencies, Guidelines
The Parking Suite will be installed on the valet computer. Therefore in order to use it the user will need to have access to the valet area or have administrative priviledges to view online. The ability of online connectivity will of course be determined by Diamonds ability to get an internet connection. And the ability of multiple users will be dependent on the capabilities of the server machine.
2.6 User View of Product Use
No log on will be required for the valets. The valets will be presented with a main menu: Add Packet, Edit Packet, and View/Print Packets.
3.0 Detailed Description of Components3.1 Component Template Description
| Type | A module, a subprogram, a data file, a control procedure, a class, etc | | Purpose | Function and performance requirements implemented by the design component, including derived requirements. Derived requirements are not explicitly stated in the SRS, but are implied in the SDS requirements. | | Function | What the component does, the transformation process, the specific inputs that are processed, the algorithms used, the outputs produced, where the data is stored, and which data items are modified. | | Subordinates | The internal structure of the component, the constituents of the component, and the functional requirements satisfied by each part. | | Dependencies | How the component's function and performance relate to other components. How this component is used by other components. Interaction details such as search times, interaction conditions, and responsibility for creation, duplication, use, storage, and elimination of components. | | Interfaces | Detailed descriptions of all external and internal interfaces as well as any mechanisms for communicating through messages, parameters, or common data areas. All error messages and error codes should be identified. All screen formats, interactive messages, and other user interface components. | | Resources | A complete description of all resources (hardware or software) external t othe component but required to carry out its functions. Some examples are CPU execution time, memory, I/O, etc. | | Processing | The full description of the functions presented in the Function subsection. Pseudocode can be used to document algorithms, equations, and logic | | Data | For the data internal to the component, describes the representation method, initial values, use, semantics, and format. This information will probably be recorded in the data dictionary. |
3.2 User Interface
| Type | Module | | Purpose | Display information of database in an easy to view manner | | Function | Assist Valet | | Subordinates | The internal structures contain storage types for the current logged Valet | | Dependencies | The user interface depends on the database | | Interfaces | Based on the keyboard and mouse. The user interface sends information to the database through drivers. | | Resources | HardWare: I/O Channels, Monitor Software: Web Browser | | Processing | Valet can add/edit/view packets coming back on his shift | | Data | All data is read from database |
3.3 Menu
| Type | Class | | Purpose | Provide the valet the ability to navigate easily | | Function | Sets the state of database to assure data quality | | Subordinates | The internal structure holds information about the different menu settings | | Dependencies | The menu depends on the User Interface | | Interfaces | Mainly buttons and messages to the user | | Resources | Same as UI | | Processing | Menu system redirects user to where they want to go | | Data | No data needed, menu is static |
3.4 Packets
| Type | Class | | Purpose | Represent a car parked in lot | | Function | Provide an abstract view of current parking lot | | Subordinates | The internal structure includes the claim#, location parked, make, color, date returning, and other information about parked car | | Dependencies | Depends on user input | | Interfaces | Interface to enter a packet will be in the UI to add/view/edit a packet | | Resources | Memory. Packets class will only be used to display recent packets in a speedy manner. | | Processing | Defensive Programming. Make sure no fields are left null that shouldn't and all values are in acceptable ranges. | | Data | Strings, Integers, and Date/Time. |
3.5 Database
| Type | Data File | | Purpose | Store all data of all packets | | Function | To act as a database of parked cars | | Subordinates | The internal structure includes various tables to accurately depict a parking lot | | Dependencies | Depends on user input, drivers, and other Microsoft utilities. | | Interfaces | Interface is all done in browser, could use Access interface as well | | Resources | Hard Disk Space and Memory | | Processing | NA | | Data | Data representations for packets |
3.3 Performance RequirementsCurrently only needs one user at a time connected. Will need support for multiple users in the future. Response time should be as quick as possible. The database, and all the files associated with GlassFish will be all the files needed; the only file that could possess a size problem is the database, however 2GB will cover it and then some. Each table consists of no more than 6 columns and only one transaction per interval is needed.
3.4 Quality AttributesMaintainable issues are keeping the server running without error. Also, having the server communicate with the database without error. Diamond has asked to put no security features. GUI has been created for maximum reliability and readabilit.
3.5 Other requirementsNone at this time.
- 4.0 Reuse and Relationships to Other ProductsWe are using GlassFish for our web server, which provides a nice interface that communicates well with JSF and our database. We are also using JPA to communicate from user to database and vice versa. We are using Microsoft Access and all its tools for the database.
5.0 Design Decisions and Trade-OffsWe continually making decisions and trade-offs between the GUI we draw up by hand and the GUI we can program. Certain aspects of JSF enhance and limit our abilities. Microsoft Access is not as powerful, but certain bit of code are being improvised to suit our needs.
| Change Log | Started 01/27/08 | | Updated | 02/07/08 | | Updated | 02/10/08 |
|
Sign in to add a comment