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.