System Requirements

System Requirements

You have to specify the requirements for Parking Management System for a multi-national company named ABC Inc. This should be a modern parking, management system that supports management of people, operations & resources, optimization of parking space usage, disaster management, time-to-park reduction etc. The purpose of this assignment is to write a fairly complete and precise requirements specification, which is a critical step in developing a large software system.

This assignment is to write a software requirements document for the Parking Management system. The details of the requirements should be elicited by interviews with a customer. The customer will act as customer and user.
The report should be between 6 pages long.

The requirements specification should contain at least the following sections. Please pay close attention to the template sheet provided.

1. Introduction. Introduce both the system and the document. The Introduction describes the need for the system, gives a concise overview of its functions, and explains the role it plays in the organization. The Introduction also outlines the document’s organization.

2. User Requirements Overview. This section’s audience is the non-technical customer and user. It should address the goals of the system and why it is needed. Describe the major features of the system and the rationale for each. Identify and describe other software, processes, hardware, people, and policies that the system may or will interact with or affect. List in this section any assumptions made about the existing world. (Assumptions that may be revised in the future should also be addressed in the “Expected Changes” section.)

3. System Requirements Specification. Describe the functional requirements of the system in precise detail. When possible, identify the entities (components, sections, areas of functionality) that make up the system. Characterize the properties, states, functions, and interrelationships of each entity. Since this section is the core of the requirements document, it warrants its own brief introduction. Make sure this section is carefully organized.

4. Constraints and Non-functional Requirements. Discuss constraints pertaining to speed, space, safety, portability, robustness, implementation bias, operating environment, etc. Your audience here are the system designers and programmers, who will probably not be in direct communication with the users. This section will help them design the software architecture and assess trade-offs in the system’s implementation.

5. Implementation Phases. If applicable, and following the request of the customer, identify one or more subsets of the system’s functionality which can or will be implemented first.

6. Future Directions and Expected Changes. If applicable, identify other goals or features which are not addressed elsewhere in the requirements document. Again, you are providing insight and guidance to the system designers and programmers.
Scoring

The scoring criteria are outlined on the template sheet, which should be the first page of the document you turn in. Throughout the document we will be looking for:

– Adherence to the stated structure. Carefully follow the structure defined above.
– Clarity of writing. You should write your document in clear, precise, business-like English prose, avoiding jargon, humor, and wordiness. Correct spelling and correct grammar are essential. Avoid acronyms; common ones should be defined when first used. Do not put diagrams, graphs, or pictures in your document. Bulleted and numbered lists can be used, with restraint, and not as a substitute for complete sentences and readable prose.

– Fidelity to customer’s desires. It is important that your document be true to the requirements stated by the customer. Don’t add or remove requirements without approval. When in doubt, ask the Teaching Assistant but only for clarification purposes (no new requirements).

– Completeness. Your document should address all aspect of system functionality and constraints which are important to the user.
– Consistency. Your document will contain many detailed requirements. Careful thought is necessary to ensure that no subtle contradictions are introduced.
– Verifiability. State detailed requirements in a manner that facilitates determining whether they are met in the final implementation.
– Avoiding implementation bias. Focus on “what” not “how”.
– Modularity and separation of concerns. Try to divide each section into subsections or paragraphs which are largely independent of each other. Ideally, each requirement or feature is discussed in its entirety in one place. Separate UI elements from the functionality to which they pertain.
Interviews:
Project: Parking Management System
Company name: ABC Inc.
Users of the system: Employees and Visitors (At Offices), Customers and Employees (At Stores)
Budget & Timeframe: Not defined currently, depends on the initial set of requirements.
1. Five Offices Locations with No. of Employees
Santa Monica CA: ~500 employees
San Francisco CA: ~500 employees
Las Vegas NV: ~500 employees
New York NY: ~1000 employees
Portland OR: ~500 employees
Parking capacity range at the office locations: 500-1100
2. Twenty Store Locations
San Diego CA, Los Angeles CA, San Francisco CA, Las Vegas NV, Boston MA, Chicago IL, Seattle WA, San Jose CA, Charlotte NC, Denver CO, Portland, Sacramento, Long Beach, Miami, Detroit, Phoenix, Houston, New York, Columbus and Washington D.C.
Parking capacity each store locations: ~1000
3. Hours
Store: 8:00 AM to 10:00 PM
Office: Open 24 hrs
4. Parking cost
Stores
Customers:
If not waived (no purchase at the store), $10 parking for until stores are open. (Precisely 7:00 AM-11:00 PM)
If waived, $0 parking for until stores are open (Precisely 7:00 AM-11:00 PM).
Employees:
Free parking validated by showing the ID at entries and exits.
Office
Employees:
Free Parking Permits to employees.
Visitors:
Visitor Parking Permits given my employees to the visitors
Below are more recommendations:
Parking Management System
– ABC Inc. is a multinational company with offices & stores across the world. This company is responsible for design, development, maintenance, management and marketing of shopping stores.
– The parking management system is only for the stores and offices at the US locations.
– To eliminate the confusion regarding ticket and receipt: the customers at the store location receive a parking ticket at the entry of the parking lot, this ticket needs to be displayed at the dashboard. There can be two basic cases at the exit, Case 1: If the customer did not purchase anything she pays $10 and gives the ticket to the employee at the exit gate and leaves.
Case 2: If the customer made a purchase she returns the ticket and shows the receipt to the employee at the exit gate, after validation of the ticket and the receipt, only the receipt is returned to the customer and the customer leaves without paying anything.
Document Format
– The 6 page limit does not include the title and scoring page.
– The template formatting is suggestive, for eg. Single-spaced or double spaced depends on you.
Use case diagrams
– It is good to include use case diagrams in the document.
– It will be a good idea to have more than one use case diagram depending on the behavior you are trying to encapsulate. For sure everything that a parking management system includes should not be shown in one single use case diagram, however, this does not mean that you should have a use case diagram for everything.
– Pages with use case diagrams will count towards the page limit.
– Also, use case diagram is one part of the whole document, having only use case diagrams and nothing else in the document means you will score less points.