Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PARKme System - System Requirements Specification (SRS)
#1

PARKme System - System Requirements Specification (SRS)

[attachment=993]

Identification

This System Requirements Specification (SRS) describes the requirements for the PARKme System. This document will be reviewed and approved by the PARKme system engineers and project sponsors and will then serve as the complete set of requirements necessary for the system to continue into future stages of development. After approval of this SRS, future changes to requirements will be made by submitting Requirements Change Requests and following the requirements management process set forth by the PARKme system engineers.

System Overview

This section provides a brief overview of the necessity for the PARKme system. It then briefly examines the PARKme structure and its interaction with the environment through a context diagram.

PARKme Need

Problem Statement:

"Finding a parking space at the university is a common frustration for commuters at the GMU campus. Finding the parking space that best suits your needs can be very time consuming and often times the drive around looking method does not result in the best space. Campus parking lots are often overcrowded during certain times of the day and week making parking a guessing game and a matter of luck."
University parking areas are not sufficient to handle the abundance of commuters that frequent GMU on an everyday basis. The parking process involves driving around the parking lots until you find an available space. This process works for small lots but at the university driving form lot to lot wastes time and resources and usually does not result in the user finding the best space for their needs.
The PARKme system will provide a method for those wishing to park at the university a tool to search the real-time availability of spaces from multiple locations.

PARKme System Context

The PARKme system functionality is organized into three major subsystems. Each of these subsystems is described in detail in section 1.5 along with a further breakdown of each subsystem. The three top-level subsystems are as follows:
Data Network Subsystem
Parking Space Subsystem
User-Interface Subsystem

Customer

The Customer is defined as the user who is accessing the system to view the current state of the parking situation on campus. The Customers include students looking for parking spaces, faculty looking for spaces, and visitors looking for parking spaces, staff receiving information about current parking atmosphere.

Operator

The Operator is defined as the user who is accessing the system in order to provide maintenance/administrator functions, initialize and setup the system, monitor the system, run queries on data for analysis.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

Powered By MyBB, © 2002-2024 iAndrew & Melroy van den Berg.