Software
Requirements
Specification Report
Car Tracker
Behlül UÇAR – 1631191
Ceren Abay – 1559814
Ezel Aydoğ – 1630623
1
Table of Contents
1. Introduction 3
1.1. Problem Definition 3
1.2. Purpose 3
1.3. Scope 3
1.4. User and Literature Survey 4
1.5. Definitions and Abbreviations 4
1.6. References 4
1.7. Overview 5
2. Overall Description 5
2.1. Products perspective 5
2.2. Product Functions 6
2.3. Constraints, Assumptions and Dependencies 7
3. Specific Requirements 8
3.1. Interface Requirements 8
3.2. Functional Requirements 9
3.3. Non-functional Requirements 10
4. Data Model and Description 11
4.1. Data Description 11
4.1.1. Data Objects 11
4.1.2. Relationships 12
5. Behavioral Model and Description 12
5.1. Description for software behavior 12
2
5.2. State Transition Diagrams 13
6. Planning 14
6.1. Team Structure 14
6.2. Estimation (Basic Schedule) 14
6.3. Process model 15
7. Conclusion 15
3
1. Introduction
1.1. Problem Definition
Today most companies and settlements have their own parking lot that they don’t prefer
strangers to use, also most companies want to keep an eye on entrance and exit times of
their employee. Even though there are lots of systems to automate car entrance, still all
those systems needs a security officer to decide on some exceptional actions which cannot
be handled by an automated system. There should be a system that is not all by itself, but
works together with the officer to help him/her decide on some actions.
1.2. Purpose
The purpose of this software requirements specification (SRS) is to establish the major
requirements necessary to develop the Car Tracker project. The general objective of Car Tracker
project is to provide a system which makes job of security officers easier. The project aims to do
this by augmenting the view on the screen at which security officers look. The project
requirements will define, in general terms, project perspective, functions, requirements,
interfaces, user activities (if any), and behavioral models.
1.3. Scope
The product is named Car Tracker. It is being developed for a company which wants to
make the job of security officers easier. The company wants to control car going in and out
of our auto park. For this reason, they want software that will be responsible for recognizing
and tracking the cars' going in and out through the entrance. The software will take its input
from a camera located near the entrance and process this input to tag the cars in the view.
Then it will provide an augmented view to the security officer. In this augmented view;
speed of cars will be visible on the screen, at the same time cars will be recognized
as employees or visitors. Detailed information for employees can also be seen in
this view. Employee profile and detailed information will be accessed through a
4
database.
The benefit of this product is mainly about security. It can be used for assisting
security officers to decide on action.
If desired, in the future, this software can be integrated of bigger security system which
automatically allows or disallows entry of a car. Since current scope does not include this
function, the system will only assist security officers in their decision.
1.4. User and Literature Survey
There are similar products being used by various police forces. Most of the existing products
only deals with recognition of cars from their plates, they do not combine this feature with
tracking or augmented reality. [2]
1.5. Definitions and Abbreviations
SRS: Software Requirements Specification
OCR: Optical Character Recognition
CT: Car Tracker
CR: Car Recognizer
DB: database
IAD: Image acquisition device
FPS: Frame per second
1.6. References
[1] IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements
Specifications
[2] Wikipedia the free encyclopedia,17:41 24 November 2010,
<http://en.wikipedia.org/wiki/Automatic_number_plate_recognition>
5
1.7. Overview
The rest of the SRS contains overall description about Car Tracker system and specific
requirements which are organized according to different phases of the system. In section 2,
overall description is given about the software. Section 3 explains the specific requirements.
Section 4 mentions the data model. Then in section 5, information about how the system
behaves in different conditions is given. Section 6 explains planning model of our team and
Section 7 gives a conclusion.
2. Overall Description
2.1. Product Perspective
Car Tracker system is a component of a general security system. It contributes to the
protection of auto park entrance of a company. The Car Tracker system is used and managed
by security officers to recognize and identify the driver of a car. Also, the officer can see
information that eases his job.
System consists of a camera and a laptop as hardware and MySQL and a real time OS(Windows,
MaxOSX or Linux). Camera captures the video, and laptop processes those images to extract
information from it. Also, a database will be present in the system in order to fetch profile
information for employees. At the front-end, laptop screen is used for presenting the output of
the software to watcher. User will be using this screen to watch the augmented view and perform
user events.
6
Figure 1
2.2. Product Functions
Software will recognize cars from their plates. It will track the cars and find their speeds. On
demand, which is a click input, it will show real time information about cars on the screen.
Since our software is for making the job of officers easier, there is not much use case. Use
cases present in the system are initializing the system, clicking on a car to see information about
it, and saving a frame to access it later. Use cases are depicted below:
7
Figure 2
2.3. Constraints, Assumptions and Dependencies
For simplicity and ensuring computability, the system makes the following assumptions:
Users are expected to look at the augmented view provided on the screen
Users have access to a mouse controller that controls the pointer of the screen
Camera should not have any flaws on its lens.
There should not be any obstacle between the camera and the road.
Camera is connected to the laptop that does the processing and viewing.
Camera will be 3 meters high looking from 45 degree.
System will only work between 8:00am and 5:00pm.
Speed of cars will be lower than 20 km /hour
There will be at least 5 meters between each car.
All employee’s cars are stored in the database.
8
In addition, system will be dependent on the following constraints:
Heavy processing will be done in limited time thus computer must have more than two CPU
cores to handle concurrent processing better.
Image quality is very important. Lighting of the area, concentrated dust on the car plate, and
air effects like fog might reduce precision
.
System should work on a general computer. It will not contain any hardware designed for image
processing. Implementation will be done taking this constraint into account.
3. Specific Requirements
3.1. Interface Requirements
The primary input to the system is the image acquired from the device, i.e. camera. After object
recognition and object tracking phases, this image is used in augmented reality phase with the
resultant information. Eventually, the watcher can see enhanced view of the area on the screen.
System also is open to user input in terms of mouse clicks and/or keyboard. The watcher must be
able to click onto a car to see additional information such as profile of the driver if he/she is an
employee.
The watcher will also be able to save a special frame with a mouse click.
The records of each cars entrance and exit times are kept in the database, user can access this
information any time he wants by providing plate number. This information will be shown in another
window as a list.
User can change basic settings of the software like color of border augmentation.
As explained in Section 2.1, the system consists of mainly three components. They are camera,
processing unit and screen. Since processing unit and screen will be on the same machine, the interface
between them will be straightforward. Camera will be connected to that machine (laptop).
9
3.2. Functional Requirements
In this section we will divide functional requirements into three parts: Recognition
requirements, tracking requirements and augmentation requirements.
3.2.1. Recognition Requirements
1) There must be 5 meters between cars for camera to catch the plate of all cars for at
least in one frame.
2) There should not be any obstacles between camera and the road.
3) Weather effects like fog will reduce the accuracy of the recognition.
4) If the plate number cannot be read, then that car is assumed to be a quest.
5) Otherwise software will is desired to be able to recognize the plate on a single frame
with 100% accuracy.
3.2.2. Tracking Requirements
1) The cars that will be tracked are already recognized.
2) Re-accessing to database with the car plate won’t be needed since the car can be
tracked by far more efficient algorithms once recognized. Finding the motion in the
picture by image processing is one example.
3) While being tracked the speed and direction of the each car is calculated.
4) While being tracked if cars passes the entrance line with front or exit line with their
back a record about entrance and exit times is created/updated respectively to keep
entrance and exit times in the database.
3.2.3. Augmentation Requirements
1) Once recognized car is augmented by placing a border around it, the color of the border
is dependent on whether the car is an employee car, or a guest car.
2) While being tracked the borders move with the car.
10
3) System user/watcher can click inside any of the recognized cars’ borders to view car
speed, model, color, chassis, motor size, fuel type, employee ID, first name, last name,
department and other information if present (‘other’ is detailed in section 4).
4) System user/watcher can save a frame from the video stream.
3.3. Non-functional Requirements
There are two major goals relevant to the implementation. These are performance
and accuracy of the system.
3.3.1. Performance
Performance is one of the two major issues for our system. The system should have a
high performance such that the user should be able to see a the augmented view of the area
streaming with 25 fps.
3.3.2. Accuracy
Accuracy of the system is important for the user. For this reason, under the given
assumptions in Section 3.1, the system should have 100% accuracy, meaning that it should
recognize all cars correctly.
3.3.3. Simplicity
Regarding user interface, an important design goal is keeping it simple. User interface
should not be so complicated. Besides, the user should not need to do anything for basic
usage of the system, that is seeing the speed of cars and seeing whether a car is owned by
an employee or a visitor.
3.3.4. Security
Since the system will be used offline and by a single user, security is not an issue.
3.3.5. Availability
System will be available as long as the computer is running on is available.
3.3.6. Maintainability
Our system is specified for one task. There will not be so much change in the future.
Therefore, maintainability does not have more importance than it has in a normal software.
11
4. Data Model and Description
The software will acquire tag information from a single database.
4.1 Data Description
Stored information in the database consists of a 1-to-n relationship between
employee and car entities.
4.1.1 Data objects
Attributes of those entities are shown below;
Employee
ID::Char[] An unique ID of an employee
FirstName::Char[] First name of the employee
LastName::Char[] Last name of the employee
Department::Char[] Department of the employee
Other::Char[] All other information related to employee. Information
here should be organized with whitespaces between
them(example: “Age:24 Gender:Male”)
Car
Plate::Char[] An unique ID of an employee
Model::Char[] Model of the car
Color::Char[] Color of the car
Chassis::Char[] Chassis number of the car
12
Motor size::Char[] Motor size of the car
Fuel type::Char[] Fuel type that car uses
Other::Char[] All other information related to car. Information is
organized same as ‘other’ attribute of ‘Employee’ entity
Record
Plate::Char[] Plate number of the recorded car
Entrance::Date Entrance time of the car
Exit::Date Exit time of the car
4.1.2 Relationships
5. Behavioral Model and Description
5.1. Description for software behavior
Our software is expected to be powered on all the time. It should monitor an area,
constantly and repeatedly getting view, and deduct information from the view of that area.
13
In the case of detecting cars in the area, the system will try to do two things; first being
recognizing the cars and second being the tracking. At the same time when it creates enough
information from the context, it will reflect this information to the screen for watchers, e.g.
security officer. If there is no car in the view, system will not show any information to
watcher.
5.2. State Transition Diagrams
Figure: Data-flow model
Data structures in the data-flow model are shown below;
14
Figure: State machine model of the system
6. Planning
6.1. Team Structure
There are three people in the team. These people are:
Behlül UÇAR
Ceren Abay
Ezel Aydoğ
6.2. Estimation (Basic Schedule)
Work Starting time Ending time
Requirements Analysis 15.10.2010 15.11.2010
Initial Design 25.11.2010 26.12.2010
Detailed Design 28.11.2010 07.01.2011
Demo Preparation 06.01.2011 10.01.2011
15
Figure: First Semester
Work Starting time Ending time
Central controller 20.02.2011 24.02.2011
Image Acquisitor 24.02.2011 27.02.2011
Recognizer 27.02.2011 14.03.2011
Tracker 14.03.2011 24.03.2011
Augmenter 24.03.2011 29.03.2011
User Interface 29.03.2011 08.04.2011
Figure: Second Semester
6.3. Process Model
Iterative and incremental development model is going to be used by the team
7. Conclusion
We have given information about the software requirements specification of Car Tracker
project. The project aims to help security officers in an auto park by enhancing the view on
their screens. Since the project is mainly about algorithms and implementation, usage of the
system is a little bit straightforward. Therefore as the readers have noticed, this document
has been laconic. Nevertheless, we believe this software will be very helpful for security
officers in action.