Track it

Software Requirements Specification

1. INTRODUCTION

1.1 Purpose of this Document

The purpose of this document is to present a detailed description of TrackiT (Geo location service). It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system and will be proposed to the Faculty of Computer Science, University Of Sindh for its approval.

1.2 Project Scope

TrackiT will help the companies know where their sales representatives are geographically at a particular instance of time. Project will have a mobile application from which the sales persons would be able to see the tasks assigned to them with a map for every task and when they complete their task they can update the company through application and their geographical location will be sent to the company so that they would know if the sales person was actually there or not. Company representative will be managing all this through a web interface from which the sales manages would be able to assign territories to the territory managers and in the same way the territory managers would be able to assign task to sales persons of their territories. The project could be beneficial for any company who want to keep track of their employees in working hours. Another example can be of any restaurant management who wants to keep track of staff person who is bound to deliver the food to customers will be able to do it with the help of TrackiT.

1.3 Purpose of this DocumentThe purpose of this document is to present a detailed description of TrackiT (Geo location service). It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system and will be proposed to the Faculty of Computer Science, Sindh University for its approval.

document.doc (05/08/14) Page 1


1.4 Description

Trackit will have four major functions. Companies will register on our website. Important information about the company will be entered into the system. Some information can be updated by the company representative, however most information will be in control of the supervisor of that company. Project will have a mobile application from which the users would sign up with their device UUID and that application will run in background and give user’s location information to the server after every hour and or if the users location change. The users/employees will also be given a to-do list by their supervisor so that they know what their goals are throughout the day. The supervisor would be able to go on the website login into his companies account and then he would be showed maps of the location that his staff members went to. This way the supervisor will be able to manage their sales person information like where they went and when, and whether they delivered their goals on time or not.



2. OVERALL DESCRIPTION

2.1 Product Functions

TrackiT will have four major functions which are described in the subsections below.

2.1.1 Registration of Companies

Companies will register on our website. Important information about the company will be entered into the system. Some information can be updated by the company representative, however most information will be in control of the supervisor of that company.

2.1.2 Track of a User/Staff person

Project will have a mobile application from which the users would sign up with their device UUID and that application will run in background and give user’s location information to the server after every hour and or if the users location change. The users/employees will also be given a to-do list by their supervisor so that they know what their goals are throughout the day.

2.1.3 Staff Management

The supervisor would be able to go on the website login into his companies account and then he would be showed maps of the location that his staff members went to. This way the supervisor will be able to manage their sales person information like where they went and when, and whether they delivered their goals on time or not.



2.2 Operating Environment

This application will operate on the android platform as well as web platform.

Software constraints

- Compatibility with Firefox, Mozilla and Internet Explorer.- Minimum level of computer knowledge in order to perform the tasks

required by the system- Login and password is used for the identification of users.- Only registered users will be authorized to use services.- Limited to HTTP/HTTPS.


Sales PersonSales PersonSales ManagerSales Manager

Territory ManagerTerritory Manager

CompanyRepresentative

CompanyRepresentative

TrackiT AdminTrackiT Admin

TrackiTSystemTrackiTSystem


Cultural constraints (includes language etc.)

- GUI is in English Only

Application shall operate with the following web browsers

Microsoft Internet Explorer 9.0 and up Google Chrome 12.0 and up Firefox 12.0 and up

Application shall operate on the following platform of Android

4.2 jelly bean

2.3 Design and Implementation Constraints

The system shall use the current corporate standard MySQL database engine. All HTML code shall conform to the HTML standard. All scripts shall be written in PHP. Beside that JavaScript and JQuery will be our secondary languages for web

development.

2.4 Assumptions and Dependencies

Assumptions and Dependencies will be added later.



3. EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces

Our software will have very simple yet effective design with a very excellent user interface. Our website will be responsive. A simple guide will be provided on how to use this application for client convenience. Any shortcuts on the website and application will be defined later in prototyping phase. See software design document for the screen shots of our software.

3.2 Hardware Interfaces

Our website will not be bound to any particular operating system or web browser thus it will run on any browser with latest configurations. As far as our application is concerned it will be an android based application which will run in almost every system of android.

3.3 Software Interfaces

Our project’s website will be scripted in PHP, which is renowned language as far as web development is concerned. Beside PHP being our primary language JavaScript, JQuery will be our secondary languages. Html, Html5, CSS and CSS3 will be used for developing interface. MySQL will be used for developing backend or database of our website. Every web developing will be written and complied in Adobe Dream Weaver (latest version). We’ll not be making a native android app using java or what not but we’ll be using a very efficient and latest technology of Phone Gap (latest version). As we defined in the scope our application will basically be a service which will send the information (location) of the user on server after every particular time period. We’ll also be using Google API’s for geo locating user’s current status.

3.4 communications Interfaces

We will be using SMS alerts to send and receive tasks and locations. When the sales person is assigned a task he will receive the coordinates of the location which will be shown in the form of map in his mobile application and then when he will reach the destination he will press the done button for that task. When he will press the done button, his coordinates will be transferred to the server through a SMS alert and will be stored in the database against his UUID for further processing.



3.5 Architecture Diagrram

Cell Phone Clients


Database

Database & Content Management System


3.6 Database Design



4. SYSTEM FEATURES

4.1 System Feature 1

4.1.1 Description and Priority

Features Priority

Installation of Application

High

Registration to the software

High

GPRS or Wi-Fi or 3G

High

Make user profile

Medium

Generate Revenue Report

Medium

4.1.2 Stimulus/Response Sequence

See software design document for detail.

4.1.3 Functional Requirements

REQ-1: Administrator must be able to add users and change user’s permissions through an administrator interface.

REQ-2: Registered user must provide all their data and maintain their profiles.

REQ-3: Registered user will also have to install application on their smart phones.

REQ-4: Supervisor of the registered user will have to monitor every location of their user in order to keep a track



4.2 System Feature 2 (and so on)

4.3 User Cases



SECTION 5 - USER INTERFACE DESIGN/SCREEN SHOTS



5. OTHER NONFUNCTIONAL REQUIREMENTS

5.1 Performance Requirements

This software will perform the same way irrespective to its Operating System environments.

Processor: Minimum 400 MHz processor, recommended: Pentium IV 1.6 GHz. RAM: 512MB RAM minimum Screen Resolution: 1024 by 768 (minimum) Minimum Connection Speed: 1mb. (We recommend at least 2mb & above for high

quality performance. While the course will function at the minimum required speed.

5.2 Safety Requirements

This requirement does not apply for our application as this can’t pose any threat.

5.3 Security Requirements

As all the operations are to be done within a single system security is not an issue for this software. But yes the companies should hold strong passwords in order to be more secured to their data. Password must contain special characters.

The administrator shall be able to login and modify the content on the various webpages, as well as change the layouts of content areas as desired. General users shall not have access to modify content within the system

5.4 Software Quality Attributes

5.4.1 Binary Compatibility

The system shall be binary compatible between Windows and Mac operating systems. Also, the system shall be accessible from any computer with Internet connectivity and at least one of the following web browsers: Microsoft Internet Explorer, Google Chrome, Safari, and Mozilla Firefox.

5.4.2 Reliability



The system shall be accessible at any time.

5.4.3 Maintainability

The system shall be easily maintainable by the administrator through the use of user interface. Also, other programmers shall be capable of easily modifying and updating code by using the documentation provided with the system.

5.4.4 Portability

The system shall be accessible to any user with a working Internet Connection and up-to-date web browser.

5.4.5 Extensibility

The system shall be extensible. Code may be modified, styles may be changed, and content may be added.

5.4.6 Reusability

The system shall be well-documented in order for new administrators to change content as needed. Also, the system shall be designed in such a way that administrators may modify content without having to modify code.

5.4.7 Application Affinity/Compatibility

The system shall be compatible with any of the following Internet browsers: Microsoft Internet Explorer, Google Chrome, Safari, and Mozilla Firefox.

5.4.8 Resource Utilization

The system shall be accessible from any type of computer with an active Internet connection. The system shall require an active server with adequate hard drive space and available memory.

5.5 Business Rules

Administrator will be able to manage accounts of the employees, he will be able to add, update or delete users. Beside that he’ll be able to register every user and monitor their activities by TrackiT.



6. OTHER REQUIREMENTS

Every requirement is been discussed in functional requirement section. Any other requirements will be added later in project deployment phase.

6.1 APPENDIX A:GLOSSARY

6.2 A

6.2.1 Aggregation

A special form of association that specifies a whole-part relationship between the aggregate

(whole) and a component part.

6.2.2 Analysis

The part of the software development process whose primary purpose is to formulate a model of

the problem domain. Analysis focuses what to do, design focuses on how to do it.

6.2.3 Architecture

The organizational structure of a system. An architecture can be recursively decomposed into

parts that interact through interfaces, relationships that connect parts, and constraints for

assembling parts.

6.2.4 Association

The semantic relationship between two or more classifiers that involves connections among their

instances.



Attribute

A named slot within a classifier that describes a range of values that instances of the classifier

may hold.

6.3 B

6.3.1 Behavior

The observable effects of an operation or event, including its results.

6.3.2 Binary association

An association between two classes. A special case of an n-ary association.

6.4 C

6.4.1 Class diagram

A diagram that shows a collection of declarative (static) model elements, such as classes, types,

and their contents and relationships.

6.4.2 Component

An executable software module with identity and a well-defined interface.

6.4.3 Context

A view of a set of related modeling elements for a particular purpose, such as specifying an

operation.



6.5 D

6.5.1 Delegation

The ability of an object to issue a message to another object in response to a message. Delegation

can be used as an alternative to inheritance.

6.5.2 Dependency

A relationship between two modeling elements, in which a change to one modeling element (the

independent element) will affect the other modeling element (the dependent element).

6.5.3 Deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components,

processes, and objects that live on them. Components represent run-time manifestations of code

units.

6.5.4 Derived element

A model element that can be computed from another element, but that is shown for clarity or that

is included for design purposes even though it adds no semantic information.

6.6 E



6.6.1 Extends

A relationship from one use case to another, specifying how the behavior defined for the first use

case can be inserted into the behavior defined for the second use case.

6.7 G

6.7.1 Generalization

A taxonomic relationship between a more general element and a more specific element. The

more specific element is fully consistent with the more general element and contains additional

information.

6.8 I

6.8.1 Implementation

A definition of how something is constructed or computed. For example, a class is an

implementation of a type, a method is an implementation of an operation.

6.8.2 Interaction

A specification of how messages are sent between instances to perform a specific task. The

interaction is defined in the context of a collaboration.

6.8.3 Interface

A declaration of a collection of operations that may be used for defining a service offered by an

instance.



6.9 M

6.9.1 Message

A specification of a communication between instances that conveys information with the

expectation that activity will ensue. The receipt of a message instance is normally considered an

instance of an event.

6.9.2 Model

A semantically closed abstraction of a system.

6.9.3 Module

A software unit of storage and manipulation. Modules include source code modules, binary code

modules, and executable code modules.

6.10 0

6.10.1 Object diagram

A diagram that encompasses objects and their relationships at a point in time. An object diagram

may be considered a special case of a class diagram or a collaboration diagram.

6.10.2 Object lifeline

A line in a sequence diagram that represents the existence of an object over a period of time.



6.10.3 Operation

A service that can be requested from an object to effect behavior. An operation has a signature,

which may restrict the actual parameters that are possible.

6.11 R

6.11.1 Relationship

A semantic connection among model elements. Examples of relationships include associations

and generalizations.

6.12 S

6.12.1 Specification

A declarative description of what something is or does.

6.12.2 Structural feature

A static feature of a model element, such as an attribute.

6.13 U

6.13.1 Use case

The specification of a sequence of actions, including variants, that a system (or other entity) can

perform, interacting with actors of the system.



6.13.2 Use case diagram

A diagram that shows the relationships among actors and use cases within a system.

6.13.3 Use case instance

The performance of a sequence of actions being specified in a use case. An instance of a use case.

6.13.4 Use case model

A model that describes a system’s functional requirements in terms of use cases.

6.13.5 Uses

A relationship from a use case to another use case in which the behavior defined for the former

use case employs the behavior defined for the latter.


Track it

Software

Transcript of Track it