Software Requirements Specification Report

Transcription

1 Software Requirements Specification Report Car Tracker Behlül UÇAR Ceren Abay Ezel Aydoğ

2 Table of Contents 1. Introduction Problem Definition Purpose Scope User and Literature Survey Definitions and Abbreviations References Overview 5 2. Overall Description Products perspective Product Functions Constraints, Assumptions and Dependencies 7 3. Specific Requirements Interface Requirements Functional Requirements Non-functional Requirements Data Model and Description Data Description Data Objects Relationships Behavioral Model and Description Description for software behavior 12 1

3 5.2. State Transition Diagrams Planning Team Structure Estimation (Basic Schedule) Process model Conclusion 15 2

4 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 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 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 3

5 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 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 : IEEE Recommended Practice for Software Requirements Specifications [2] Wikipedia the free encyclopedia,17:41 24 November 2010, < 4

6 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. 5

7 Figure 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: 6

8 Figure 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. 7

9 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). 8

10 3.2. Functional Requirements In this section we will divide functional requirements into three parts: Recognition requirements, tracking requirements and augmentation requirements 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 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 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. 9

11 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 Non-functional Requirements There are two major goals relevant to the implementation. These are performance and accuracy of the system 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 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 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 Security Since the system will be used offline and by a single user, security is not an issue Availability System will be available as long as the computer is running on is available 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. 10

12 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 Data objects Attributes of those entities are shown below; Employee ID::Char[] FirstName::Char[] LastName::Char[] Department::Char[] Other::Char[] An unique ID of an employee First name of the employee Last name of the employee Department of the employee All other information related to employee. Information here should be organized with whitespaces between them(example: Age:24 Gender:Male ) Car Plate::Char[] Model::Char[] Color::Char[] Chassis::Char[] An unique ID of an employee Model of the car Color of the car Chassis number of the car 11

13 Motor size::char[] Fuel type::char[] Other::Char[] Motor size of the car Fuel type that car uses All other information related to car. Information is organized same as other attribute of Employee entity Record Plate::Char[] Entrance::Date Exit::Date Plate number of the recorded car Entrance time of the car Exit time of the car 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. 12

14 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 State Transition Diagrams Figure: Data-flow model Data structures in the data-flow model are shown below; 13

15 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 Initial Design Detailed Design Demo Preparation

16 Figure: First Semester Work Starting time Ending time Central controller Image Acquisitor Recognizer Tracker Augmenter User Interface 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. 15