CET & CSC 490: Software Engineering
California University of Pennsylvania
Specification Document
Josh Good
Charles McClure
Annabel Mosco
Anthony Wilson
November 20th, 2013
Instructor Comments/Evaluations
Table of Contents
1.
2.
3.
a.
b.
4.
a.
b.
c.
d.
5.
a.
b.
c.
6.
7.
8.
9.
10.
11.
List of Figures & Tables
Abstract
Description of the Document
Purpose and Use
Intended Audience
System Description
Overview
Environment and Constraints
i.
End User Profile
ii.
User Interaction
iii.
Hardware Constraints
iv.
Software Constraints
v.
Time Constraints
vi.
Cost Constraints
Acceptance Test Criteria
i.
Testers
ii.
Criteria for User Acceptance
Integration of Separate Parts and Installation
System Modeling
Functional: Use Cases & Scenarios
Entity: Class Diagrams
i.
Class name / description / type
ii.
Attributes
Dynamic: Statechart
i.
States
ii.
Events
iii.
Transitions
Dataflow / Diagrams
Components / Tools Needed
Appendix: Glossary of Terms
Appendix: Team Details
Appendix: Writing Center report
Appendix: Workflow Authentication
1
2
3
3
3
4-8
4
5
5
5
5
6
6
6
7
7
7
8
9-14
9-11
12-13
12
12
14
14
14
14
15
16
17
18
19
20
Page |1
List of Figures and Tables
1.
2.
3.
4.
5.
General Setup Diagram
Transponder State Diagram
Class Diagram
State Transition Diagram
Data Flow Diagram
9
10
11
14
15
Page |2
Abstract
EZPark is a garage door opener that will work like an EZPass. We will discuss the
components of our project and specify the requirements we will need to meet in this document.
Our main goal is to design and construct a garage door opener that will open/close the garage
door using radio frequencies to communicate between the transponder and antenna when the car
is within the correct range. This will help promote safe, hands free driving at all times. The
EZPark will be created using a Raspberry Pi, as well as other hardware/software that we feel will
work best for this project. A transponder will be kept inside the vehicle and will work with an
antenna that will be located above the garage door.
Not only will this project demonstrate the programming abilities we have learned over
the years in the computer science department, it will also demonstrate the skills and techniques
the computer engineers possess in building the hardware for the project. Finishing this project on
time will take excellent teamwork and communication, as well as staying motivated to complete
EZPark with little or no errors and high efficiency. Test versions and all progress will be updated
and available as we work towards completing this project.
Page |3
Description of the Document
Purpose and Use
The purpose of this document is to provide vivid details of every feature of the EZPark,
allowing the users to contemplate if this product is for them and if it is going to fulfill all their
requirements. In addition, taking the time to break everything down and concentrate on each
individual section allows us as the designers to master our knowledge of the project. Later down
the road, this document could reassure ourselves that we are completing all the necessary steps.
To conclude, not only is this document beneficial to the end user, but also to us as we both will
use it as a checklist.
Intended Audience
Almost every house built today comes equipped with a garage. It is used daily by all
homeowners, and the garage door opener and keypads both require you to physically operate
them to open/close the garage door. It happens all the time. People get to where they need to be
and wonder, “Did I remember to shut my garage door?” This could potentially be a huge
problem. It allows easy access to the home for any passerby and could be an easy target for
burglars. The only way for someone to know for sure if the garage door is closed is for him or
her to rush home and check for themselves or to call a friend or neighbor and ask them to check.
Page |4
System Description
Overview
Our solution is to create a hands free operating system that will open and close when it
reads your car’s sensor. This would prevent you from ever having to get out of your car to
operate your garage door. The sensor would open the garage door when you pull into your
driveway or when you are ready to leave your house to start off your day. The sensors would
then be able to read when your car is completely out of the path of the door, closing it every time
you enter or exit your garage. This would prevent the user from every wondering if they
remembered to shut their garage door whenever they left their house.
The main objective for our project is to create a functional garage door opener that is
completely hands-free. This will not only make it easier for the user, but it will also promote
safe, hands-free driving. The user will not have to fumble around and look for their phone or
garage door opener to open/close the garage door. It will be easy to install for someone of any
age, making it useful for a wide range of people.
Page |5
Environment and Constraints
i.
End User Profile
The end user for the EZPark will primarily be the owner of the vehicle and the garage.
Other family members or anyone else who has access to the garage may also be included in this
list as they will be entering this area as well. The user will only need to obtain basic setup skills
using the given instructions in the user manual in order to take advantage of the product.
ii.
User Interaction
One of the advantages of this product is that the user interaction does not vary from
person to person. The system will require basic setup in order to sync the transponder with the
desired garage door. After this, the device will run almost completely by itself while giving the
user the option to turn off the system if desired. For example, one may not need the services of
the device while doing work around the house or washing the car in the driveway.
iii.
Hardware Constraints
The main hardware constraint with this product is power. In order for the hardware to
function and the system work, it is essential that the garage has power. Much like a normal
garage door, if there is no power available during a storm, then it will not work. It is the same
thing for this product as it will not only use the garage door itself but also a number of other
components, such as sensors and an antenna as well.
Page |6
iv.
Software Constraints
In this project, there are not any software constraints. This is the case because once the
transponder is in range and communicates with the antenna, the radio frequency waves are
processed, and the door either does or does not open, depending on if it was a match to the
correct garage door.
v.
Time Constraints
The only time constraint with this project is the amount of time spent communicating and
processing the radio frequencies once the vehicle is within the required range. The rate at which
this information is delivered and processed should be less than a second. Overall, the concept
and function of this device will be quick in order to truly be effective.
vi.
Cost Constraints
The cost of the final product was one of the main focuses for us while approaching this
project. Our goal is to make this product as cheap as possible while making it durable as well.
The product will be made to last, but by keeping the price point low, those with various incomes
will all be able to take advantage of this device.
Page |7
Acceptance Test Criteria
i.
Testers
The four of us will be the primary testers as we will design, construct, and install our
completed project. In addition, we will use one of our vehicles and garage doors to verify
whether our project works without errors or not.
ii.
Criteria for User Acceptance
The EZPark will be considered completed and acceptable when it meets the following criteria:

The garage door opens when the car is within the appropriate range.

The garage door closes once the car is completely in the garage.

The user is able to choose whether they want the EZPark on/off.

The garage door will open when the users wishes to leave their house.

The garage door will close when the users leave their house and when they are out of the
appropriate range.
Once all of these requirements are met, we will consider our project completed.
Page |8
Integration of Separate Parts and Installation
The EZPark will properly execute with the combination of the following components:
Hardware
 Automobile
 Garage Door
 Transponder
 Sensors
 Switch
 Raspberry Pi
Software
 C
The installation of all the components will have its challenges. Establishing
communication between all these peripherals is going to require a lot of troubleshooting and
debugging. Not to mention, we will have to have all of this done in the most cost-efficient
manner. Nonetheless, all of the components mentioned above will be utilized to satisfy our users
as we will work towards a hassle-free device with no user interaction.
Page |9
System Modeling
Functional: Use Cases & Scenarios
The general installation and setup of the EZPark is very simple. The garage area will
contain all the components, excluding the transponder. These items consist of an antenna, a
Raspberry Pi, and sensors to trace the location of the incoming or outgoing vehicle. The antenna
will communicate via radio frequency identification with the transponder, located inside the
vehicle with the current user.
Figure Number 1: General Setup Diagram
P a g e | 10
The user is able to choose between two states when dealing with the transponder. If the
switch is toggled into the “on” position, the system will be working as a unit with the
transponder and antenna communicating via radio frequency. Likewise, if the switch is changed
to the “off” position, the system will do nothing while it awaits for all components to be active.
Figure Number 2: Transponder State Diagram
P a g e | 11
The main class of the EZPark system is the console class. It will interact with both the
door and sensor classes. The sensor class will interact with its button subclass.
Figure Number 3: Class Diagram
P a g e | 12
Entity: Class Diagrams
i.
Class name / description / type
ii.
Attributes
Noun extraction is a method of extracting class candidates from a brief description of the
software or hardware of a system. The following paragraph is a description of the EZPark system
with its nouns highlighted in bold for consideration of that noun to be created into a class.
A person would need to install the transponder in their personal vehicle along with the
EZPark console in their garage. After the installation is completed, the EZPark console will
go into the waiting mode. The person can decide when the door will open using a button on the
EZPark transponder. When the person approaches the garage, the door will open if the
EZPark sensor is in range of the EZPark console and the button is toggled to the open
position. Once the vehicle is in the garage, the EZPark console will return to the waiting mode.
When the vehicle is in the garage, the person will reverse the vehicle into the EZPark
console’s range to open the door. If the person does not want the door to open when the vehicle
approaches the garage the button on the EZPark transponder is toggled to the off position.
Nouns with class relevance:
EZPark Transponder
EZPark Console
Button
Door
P a g e | 13
Nouns without class relevance:
Person
Vehicle
Garage
P a g e | 14
Dynamic: Statechart
i.
States
ii.
Events
iii.
Transitions
The EZPark system will have automated state transitions with little to no user interaction.
The operator will have control on whether to engage the device via the switch on the
transponder, but this does not interact with the classes directly.
Figure Number 4: State Transition Diagram
P a g e | 15
Dataflow / Diagrams
Figure Number 5: Data Flow Diagram
P a g e | 16
Components / Tools Needed
The code for EZPark will be written in the C programming language. The bulk of the
code will be written and edited in Vim Editor. The main reason that we have decided to use Vim
is because it is a cross platform system with the ability to run on UNIX, Linux, and Windows.
We feel that in order to avoid future problems, it is best to use a known, reliable product. By
choosing to utilize Vim, the creation of our software is on the right track.
From the user’s point of view, the hardware and software components of the final product
will generally not vary from person to person. Every system will be required to possess a
Raspberry Pi, transponder, antenna, and sensors in order to work successfully. With these, any
vehicle will be able to utilize the product by simply keeping the transponder component inside
the automobile, as no new vehicular constraints come with the EZPark. After the initial set up,
this device is able to be exchanged between vehicles as it simply works with that individual
garage door.
The designers of the EZPark have the goal of making this product accessible to the
largest amount of potential users as possible. By offering a simple device with an easy initial set
up, at an affordable price, we feel that the achievement of this goal is very realistic. Another
advantage of this product is that it will work with all garage doors. There are no variations
required in order to connect this device to a garage door larger than the standard size. The option
to choose between using the standard opener or the EZPark is left to the user, but our team
believes that we have created an efficient, reliable, and convenient product for all to enjoy.
P a g e | 17
Appendix: Glossary of Terms
Antenna- An electrical device used to convert radio waves into electric power, and vice versa.
C- A general-purpose programming language developed between 1969 and 1973 by Dennis
Ritchie. It is one of the most widely used programming languages of all time.
Radio Frequency Identification (RFID) - The use of radio-frequency electromagnetic fields to
transfer data in a wireless and non-contact state in order to identify and track object’s tags
containing electronically stored information.
Raspberry Pi- Essentially a credit-card sized personal computer installed with a Linux operating
system used to carry out tasks similar to that of a desktop PC.
Sensor- Device used to convert a measured physical quantity into a signal that can be read by the
user or another instrument.
Transponder- A device used to emit an identifying signal in reply to an interrogating received
signal.
P a g e | 18
Appendix: Team Details
Teamwork was demonstrated throughout the completion of this specifications document
as each member contributed essential pieces needed in order to produce a successful result. The
division of the workload for this document was Annabel Mosco’s role. In doing this, she assured
that the work was distributed evenly throughout the team members. Annabel also created the
abstract, description of the document, and the acceptance of test criteria portions of the file.
Anthony Wilson contributed the table of contents, integration of separate parts and installation,
and completed the organizational structure of the document. Charles McClure added the system
modeling, entity class diagram and dataflow diagrams, while Josh Good supplied the
components and tools needed, environment and constraints, and the appendix sections to the
document. The final product was a group effort with everyone proofreading and offering helpful
advice on what would make this document better. Everyone pulled their own weight and the
ending result would not have been a success without the help of each and every one of our team
members.
P a g e | 19
Appendix: Writing Center report
The Cal U Writing Center Report
Client: Anthony Wilson
Staff or Resource: Shawn
Date: 2013-11-20, 3:00pm - 4:00pm
Student requested that instructor receive report: No
Course: CSC 490
Planning stage: Not Checked
Drafting stage: Not Checked
Revising stage: Checked
Editing stage: Checked
Understanding assignment/subject matter: Not Checked
Determining thesis: Not Checked
Organizing ideas/paragraphs logically: Not Checked
Matching content to audience/purpose: Checked
Integrating research/reading material into paper: Not Checked
Using appropriate documentation/formatting: Not Checked
Using punctuation: Checked
Understanding agreement (number/tense): Checked
Eliminating fragments/run-ons: Checked
Using correct spelling: Not Checked
Finding vocabulary to express ideas: Checked
Using function words (articles, conjunctions, etc.: Checked
Increasing clarity and conciseness: Checked
Comments: Josh and Wilson came into the writing center to work on their specification document for
their Senior Project class. They read aloud as I followed along, stopping to discuss whenever we came to
an issue. During the session, Josh and Wilson primarily wanted to make sure that the writing was
effective and that there were minimal grammatical errors. As we worked, we identified any areas that
were confusing or unclear and revised them to make sure that the writing was easy to understand. We
also reviewed some minor grammatical errors, such as comma usage. By the end of the session, we
were able to look through several portions of the assignment, and Josh and Wilson went on their way to
revise the assignment based on what we had discussed in the appointment.
P a g e | 20
Appendix: Workflow Authentication
I, Josh Good, confirm that I have performed the work documented herein.
Signature: ________________________________ Date: ________________
I, Charles McClure, confirm that I have performed the work documented herein.
Signature: ________________________________ Date: ________________
I, Annabel Mosco, confirm that I have performed the work documented herein.
Signature: ________________________________ Date: ________________
I, Anthony Wilson, confirm that I have performed the work documented herein.
Signature: ________________________________ Date: ________________