Cake Shop Application SRS

Cake Shop Application
Software Requirements Specification
“Tutu’s Cake Shop Application”
<1.0>
<20th Aug, 2018 >
Badhe Pooja S.
Lead Software Engineer
Submitted in Partial fulfillment of

Project .
Software Requirements Specification Page 1

Revision History
Date Description Author Comments

<date> <Version 1> <Badhe Pooja> <First Revision>
Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:
Signature Printed Name Title Date
<Badhe Pooja> Lead Software Eng.

Table of Contents
REVISION HISTORY ........................................................................................................................... 2
DOCUMENT APPROVAL .................................................................................................................... 2

1.INTRODUCTION ............................................................................................................................... 5
1.1 PURPOSE................................................................................................................................................. 5
1.2 SCOPE ..................................................................................................................................................... 5
1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS......................................................................6
1.4 REFERENCES .........................................................................................................................................6
1.5 OVERVIEW..............................................................................................................................................7
2. GENERAL DESCRIPTION................................................................................................................ 8
2.1 PRODUCT PERSPECTIVE ..............................................................................................................9
2.2 PRODUCT FUNCTIONS .................................................................................................................9
2.3 USER CHARACTERISTICS .................................................................................................................. 9
2.4 GENERAL CONSTRAINTS ...................................................................................................................10
2.5 ASSUMPTIONS AND DEPENDENCIES...............................................................................................10
2.6 SYSTEM ENVIRONMENT……………………………………………………………………………..11
3. SPECIFIC REQUIREMENTS ............................................................................................................12

3.1SYSTEM INTERFACE…………………………………………………...…………………………..13
3.1.1ANDROID……………………………………………………………………....................................13
3.1.2HIGHLIGHTOFANDROID………………………………………………………………..…….......13
3.1.3 INTRODUCTION OF ANDROID………………………………..…………………………..……..14
3.1.4 APPLICATION FUNDAMENTALS………………………………………..………..……...………14
3.1.5 LOCATION SENSING TECHNOLOGY………………………………..……………...…………...15
3.2 EXTERNAL INTERFACE REQUIREMENTS ................................................................................ 16
3.2.1 HARDWARE INTERFACES ............................................................................................................16
3.2.2 SOFTWARE INTERFACES ..............................................................................................................16
3.2.3 COMMUNICATIONS INTERFACES ...............................................................................................16
3.3 FUNCTIONAL REQUIREMENTS .......................................................................................................16
3.3 USE CASES ..............................................................................................................................................16
. 3.3.1 USER USE CASE ............................................................................................................................... 16
3.3.2 ACCESS INFORMAION USE CASE ...............................................................................................16
3.3.3 ADD USE CASE ............................................................................................................................... 17
3.3.4 ORDER CAKE USE CASE .............................................................................................................. 17
3.3.5 FEEDBACK USE CASE ……………………………………………………………………………18
3.4 NON FUNCTIONAL REQUIREMENTS ..............................................................................................19
3.5 LOGICAL STRUCTURE ……………………........................................................................................21
3.6 DATABASE OF APPLICATION……………........................................................................................22
3.7 OTHER REQUIREMENTS ....................................................................................................................24
3.8 SECURITY……………………………………………………………………………………………….24
4. CHANGE MANAGEMENT PROCESS ..................................................................................................25

List of figures
Figure 1-System Environment----------------------------------------------------------------------------------10

Figure 3.1.3-Android Architecture-----------------------------------------------------------------------------12
Figure 3.1.4-Android Lifecycle---------------------------------------------------------------------------------14
Figure 3.5-ER Daigram-------------------------------------------------------------------------------------------21

1.INTRODUCTION
The project uses the research method Design Science. Through designing and
implementing an artifact (i.e. prototype of Cake shop), the goal of the project is reached.
Finally, the project is evaluated in four aspects including platform evaluation, general
functional evaluation, scenario evaluation, and non-functional evaluation. The prototype
implemented includes basic functionalities of cake shop such as the” Cake Shop
Application (CSA)”activity is based on ordering and selling the cake for each customer.
Each customer will be given unique order number. As soon as this the customer’s name
and contact details are added for reference. Next the cake is selected and stuffing type is
also added if required. The user should enter the date of delivery and also the quantity. A
separate bill is produced for the confirmation and the customer can do any advance
payment. During the day of delivery, the customer will be producing the bill of order.
According to it, again a bill is generated for selling purpose and the customer is supposed
to pay the balance amount. All the data’s are being stored in the database.
Admin has the authority to add cake details, flavour details and rate. And he also
has the right to edit and delete those details to/from the list. Admin provides username and
password for each user.
Overall, the project presents a comprehensive understanding of how to realize city

guide on the new mobile platform android
1.1 Purpose
Now a day mobile phone is a necessary part of the people’s life. There is
continuously rising in a number of mobile computing applications, centered on the
people’s daily life. In such applications, location dependent systems have been detected as
an important application. Our system takes advantage of light-weighted mashup
technology that can combine more than one data sources to create value-added services,
while overcomes the limitations of mobile devices.
Online shopping is becoming trend nowadays. People like online
shopping compared to the traditional way to safe their cost and time. Tutu’s Cakes is
an online Cakes ordering system where various types of cakes are the main product to
sell online.
1.2 Scope
 Human efforts or Manual labour can be decreased drastically.
 Major operations that are done manually can be done within a matter of
seconds.
 Reduction of Manual work.
 It automates the entire process of purchasing cake from shop manually.

1.3 Definitions, Acronyms, and Abbreviations

User Someone who interacts with the mobile
phone application and computer system
Admin/Administrator System administrator who is given
specific permission for managing and
controlling the system
Company Employee Someone who has a company and wants
his branch to be a part the application
Web-portal A web application which present special
facilities for company employee and
admin
GPS Global Positioning System
Application Store An installed application on mobile phone
or computer which helps user to find new
compatible applications with mobile
phone platform and download them from
Internet
DESC Description
RAT Rational
1.4 References
The document in this file is an annotated outline for specifying software requirements
adapted from the IEEE Guide to Software Requirements Specifications (Std 830-1993).

1.5 Overview
The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It describes the informal requirements and is used to
establish a context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written
primarily for the developers and describes in technical terms the details of the functionality of
the product.
Both sections of the document describe the same software product in it entirety, but are
intended for different audiences and thus use different language

2. GENERAL DESCRIPTION
Cake shop application manages the overall information about the Cake shop. It includes
the major function of planning, organizing, staffing, directing, developing the smart phone
application for easily getting information about different aspects of the Cake shop like Cake
flavours, price, types, delivery, receipt, etc.
2.1 Product Perspective

The application described in this SRS is the application for a cake shop. The application
merges various hardware and software elements and further interfaces with external systems.
Thus, while the application covers the majority of the system's functionality, it relies on a
number of external interfaces for persistence and unhandled tasks, as well as physically
interfacing with humans.
Navigation Software puts navigation support as its main feature.
Tailorable Software enables users to tailor their visit based on their personal interest, and tailors
the information they want.
In addition, I list other applications briefly, some of them can let users to add review,
some support audio navigation, some are the solutions based on browser.
2.2 Product Functions

This subsection of the SRS should provide a summary of the functions that the software will
perform. Information about cake, delivery details, order details and it also manages customers
information.
Allowing user to give there feedback/complaints
2.3 User Characteristics

The end-users of the application fall into three primary categories, unskilled, partly skilled and
highly skilled.
Unskilled user
The users of the surface computers are walk-in customers and should therefore be assumed to
have no relevant prior skills or education other than basic abilities to operate an automated
system; no more complex than a parking meter or vending machine.
Partly skilled user
The users of the tablets and displays are waiters and chefs respectively and they should be able to
use the system and further be able to train others with minimal training themselves. They must
be able to explain all elements of the user interfaces except the server. Supervisors also fall into
the same category, though they will have to learn other sections of the system (refunds etc); these
should not be of notably greater complexity than the standard functions. This class of user would
be expected to have a junior high-school certificate education or equivalent.

Highly skilled user
The initial installation and configuration of hardware and the constituent RMOS system
components (especially the server) is guaranteed to require someone with notable computer
experience, including extensive experience with network and operating systems to complete it.
The software should not be needlessly complex, but it is still expected not to be entirely 'plug
and play'. This class of user is expected to have a high-school certificate or equivalent, as well as
extensive computer experience.
2.4 General Constraints

The mobile application is constrained by the system interface to the GPS navigation system
within the mobile phone. Since there are multiple system and multiple GPS manufacturers, the
interface will most likely not be the same for every one of them. Also, there may be a difference
between what navigation features each of them provide. The Internet connection is also a
constraint for the application. Since the application fetches data from the database over the
Internet, it is crucial that there is an Internet connection for the application to function. Both the
web portal and the mobile application will be constrained by the capacity of the database. Since
the database is shared between both application it may be forced to queue incoming requests and
therefor increase the time it takes to fetch data
2.5 Assumptions and Dependencies

One assumption about the product is that it will always be used on mobile phones that have
enough performance. If the phone does not have enough hardware resources available for the
application, for example the users might have allocated them with other applications, there may
be scenarios where the application does not work as intended or even at all. Another assumption
is that the GPS components in all phones work in the same way. If the phones have different
interfaces to the GPS, the application need to be specifically adjusted to each interface and that 6
would mean the integration with the GPS would have different requirements than what is stated
in this specification.

2.6 System Environment
The Tutu’s Cake shop application has five active actors and one cooperating system.
The User, Admin, Visitor, Staff, manager accesses the Flavours of cakes through the Cake shop
Application. Any User or viewer communicate with the application is through email. The Admin
and owner accesses the entire application directly . There is a link to the (existing) Historical
Society.
<< The division of the Cake Shop Application into three component parts, the
Flavours of Cakes and managing overall operations and order, is an example of
using domain classes to make an explanation clearer. >>

3. SPECIFIC REQUIREMENTS
Requirements Analysis in systems engineering and software engineering, encompasses those
tasks that go into determining the needs or conditions to meet for a new or altered product, taking
account of the possibly conflicting requirements of the various stakeholders, such as
beneficiaries or users.
Requirements analysis is critical to the success of a development project. Requirements must be
documented, actionable, measurable, testable, related to identified business needs or
opportunities, and defined to a level of detail sufficient for system design. Requirements can be
functional and non-functional.
Conceptually, requirements analysis includes three types of activity:
their requirements are. This is sometimes also called requirements gathering.

incomplete,
ambiguous, or contradictory, and then resolving these issues.
natural-language documents, use cases, user stories, or process specifications.
3.1 System Interface

3.1.1 Android
Android is Mobile Platform developed by Google. Developers create applications in Java on the
platform. It includes some important features like 3D graphics, Media support for common
audio, video, and still image formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF),
GSM Telephony, Bluetooth, 3G, Wi-Fi, GPS depending on hardware capability of mobile
devices.
3.1.2 Highlights of Android

Firstly, Android is open-source platform. Secondly, Android enables reuse of components. For
example, there is one component for editing text files in one application; other applications can
make use of the component as needed, of course, the application has released the permission that
other applications can use it. In J2ME [Sun 2010], one application implements most
functionalities in a single midlet extending from Midlet base class but Android contains different
components types of Activity, Service, Content Provider, Broadcast Receiver in one application
and they can communicate through sending intent message, J2ME is not easy as Android to write
modular code. Thirdly, Android can be native access to Google map infrastructure. And it
supports GPS localization. Fourthly, its network can work in the way of Bluetooth, 3G or Wi-Fi.
Finally, it provides Widgets classes and Layout classes for designing UI. Developers can write
UI in XML layout file.

3.1.3 Introduction of Android
Figure 3.1.3: Architecture of android platform

There is a figure (figure 3.1.3) of the architecture of android platform showed above. For the
layer applications at the top, android ship with some core applications including email, sms,
calendar, map, browser, contacts and others. Applications are developed in java. Different
from other mobile platforms like j2me, application framework below applications enables reuse
or replacement of components. For example, there is the component of displaying image in one
application; other applications can make use of the component if needed. Of course, there is
permit protocol between them. Libraries include a set of c/c++ libraries used by various
components of android system. These are exposed to developers through the application
framework. The core libraries includes browser engine library, 2d and 3d graphics libraries,
media libraries, sqlite that is a powerful and lightweight relational database engine available to
all applications and so on. For android runtime, [android 2010] says “android includes a set of
core libraries that provides most of the functionality available in the core libraries of the java
programming language.” Each android application runs on its own process, with its own instance

of dalvik virtual machine. Says “the dalvik vm relies on the linux kernel for underlying
functionality such as threading and low-level memory management.” For Linux Kernel,
[Android 2010] says “Android relies on Linux version 2.6 for core system services such as
security, memory management, process management network stack, and driver model. The
kernel also acts as an abstraction layer between the hardware and the rest of the software stack.”
3.1.4 Application Fundamentals

The part presents main concepts for application development. There are four types of
application components: Activity, Service, Broadcast Receivers, and Content Provider. Android
application may consist of one or several of these components types. Activity presents user
interfaces that users will interact with. For example, in text messaging application, one activity
presents the user interface to let users write message to others. All activities are written through
extending Activity base class. Service does not have user interface and run in background, for
example, play background music. Service extends Service base class. The component Broadcast
Receivers receives and reacts to broadcast announcements. For example, when low battery is
low, the information is needed to inform users. All the receivers extend BroadcastReceiver base
class. The final one, Content Provider stores data and provide data. The content provider
extends ContentProvider base class but applications do not call directly to the methods in
ContentProvider, instead they call methods in the object ContentResolver, which call
ContentProvider. Android provides the following four mechanisms for storing and retrieving
data: Preferences, Files, Databases, and Network. The Android API contains support for
creating and using SQLite databases. Each database is private to the application that creates it.
The SQLiteDatabase object represents a database and has methods for interacting with it —
making queries and managing the data. To create the database, call SQLiteDatabase.create() and
also subclass SQLiteOpenHelper. All databases, SQLite and others are stored on the device in
/data/data/package_name/databases. Except that the Content provider is activated by a request
from ContentResolver, other three components are activated by asynchronous messages called
intents. Android must know that application components exist before it can start the application
components. So, the components written in applications should be registered in the manifest file,
which is bundled into Android package, and is XML structured, and named
AndroidManifest.xml for all applications. Next, I want to say some about the lifecycle of
components; it is important to understand lifecycle before developing applications. The Activity
lifecycle is showed below in Figure 3-1-4. The colorful ovals are major states of Activity. The
rectangles are possible operations in the process of transitions between different states.. The
entire lifetime of one activity starts at the onCreate() and finishes on onDestroy(), where release
all the remaining resources. If one activity is between onResume() and onPause(), it is
foreground and interact with users, at the most top of all the activities. When one activity is
between onStart() and onStop(), it is visible but may not be in the foreground and interact with
users. During the time, the activity can maintain resources. The lifetime of Service is divided
into two kinds of ways. One is that it is started standalone. The other one is that it is operated
programmatically using an interface. Broadcast Receiver is considered to be active while
executing the method OnReceive() in the component, otherwise it is inactive. Finally, UI can be
designed in XML layout document including layout and widgets.

Figure 3.1.4: The Lifetime of Activity
3.1.5 Location sensing technologies
GPS (Global Positioning System) is the most widely known location-sensing technology today.
A GPS receiver estimates position by measuring satellite signal’s time difference of arrival.
The US Department of Defense maintains the expensive satellite infrastructure in earth orbit. It
is said in [Patterson 2003] that there are several reasons why GPS is not a universally
applicable location sensing mechanism. Firstly, it does not work indoor, particularly in steel-
framed building. Secondly, GPS use an absolute coordinate system, whereas some applications
(for example, guidance systems for robotic equipment) require coordinate relative to specific
objects. Finally, the specific component needed for GPS impose weight, cost and energy
consumption requirements that are problematic for mobile hardware. In addition, GPS’s
performance degrades in high-rise urban areas, and receivers have a relatively long start-up
time. As a consequence, other location sensing technologies is developed. Wi-Fi Localization
is one of them. It uses algorithms to compute localization based on data from Wi-Fi access
points. In [Hazas 2004], there is the Figure 2-8 showing comparison of several location sensing

technologies including GPS and Wi-Fi and mobile phones. We can see from the figure that
usually GPS has higher accuracy than Wi-Fi and mobile phones. Actually, Wi-Fi accuracy
depends on how dense the access points are positioned. However, Wi-Fi can work indoor in a
way that GPS cannot do. And Wi-Fi also can cover across the whole large metropolitan area.
3.2 External interfaces Requirements
3.2.1 User Interfaces
There are three separate user interfaces used by the application, each related to an
interfaced physical hardware device. These three user interfaces are the Surface Computer UI,
Tablet UI and Display UI.
3.2.2 Hardware Interfaces

Since neither the mobile application nor the web portal have any designated hardware, it does not
have any direct hardware interfaces. The physical GPS is managed by the GPS application in the
mobile phone and the hardware connection to the database server is managed by the underlying
operating system on the mobile phone and the web server
3.1.3 Software Interfaces
The mobile application communicates with the GPS application in order to get geographical
information about where the user is located and the visual representation of it, and with the
database in order to get the information about the cake shop, The communication between the
database and the web portal consists of operation concerning both reading and modifying the
data, while the communication between the database and the mobile application consists of only
reading operations.
3.2.4 Communication Interfaces
The communication between the different parts of the system is important since they depend on
each other. However, in what way the communication is achieved is not important for the system
and is therefore handled by the underlying operating systems for both the mobile application and
the web portal. .

3.3 Functional Requirements

This subsection presents the identified functional requirements for the subject Cake shop app.
Initially, general requirements that pertain to the whole appliction are given. Where possible,
subsequent requirements have been demarcated based on their relevance to the users of the
system, that is, customers & admin.
3.3.1 Customer use case:
Download app
User
Brief Description
A user should be able to download the mobile application through either an application store
or similar service on the mobile phone. The application should be free to download.
Initial Step-By-Step Description
1. The User download the application by connecting to the internet from the google play store.
2. The system displays the choices to the User.
3. The User selects the rules/agreements desired.
4. The system presents the abstract of the rules/agreements to the customer.
5. The User chooses to the rules/agreements.
6. The system accepted the requested rules/agreements.
Xref: section 3.3.7
3.3.2 Accessing Information::
Access Info
Customer/user
Brief Description
The customer will access the information from the different activity like as cakes, flavours, price,
etc.
Before this use case can be initiated, the customer has already downloaded and installed the Cake
shop app.
1. Customer Accept the Policy and terms.

2. Customer access different Information from homepage.
Xref: section 3.3.8

Generate report
Add cakes details

Admin
3.3.3 Add usecase:
Brief Description
The Admin able to make updation on Information such as adding new cakes, policies in existing
activity, etc.

Before this use case can be initiated, the customer has already downloaded and installed the
Cake shop app
1. After selecting Activity admin is able to add new details in the previous activity
2. The Admin simply click on top left side icon on any activity where user gets the window
for adding new information .
Xref: section 3.3.9
3.3.5 Order usecase:
Order for cake
user
Brief Description
The customer order the cake online and gets home delivery.
1. Selection of cake/ cake flavour.
2. Give order of cake and make payment.
3. Get home delivery.
Xref: section 3.3.10

3.3.6 Feedback usecase:
Give feedback
user
Brief Description
The Feedback about the app it may be complaint or positive responsens.

1. . Selection of Feedback Activity or Complaint Activity.
2. Both options provide facility to the customer for Allowing them to give their feedbacks
about app.
Xref: section 3.3.11
Section 3.3.7: Download app

Use Case Name Tutu’sCakes.apk
Called from Google play store
Inputs required Internet Connection
Process The User download the application by connecting to the
Internet from the google play store.
The system displays the choices to the User.
The User selects the policy desired.
The system presents the abstract of the policy to the customer.
The User chooses to the policy.
The system accepted the requested policy.
o/p Installed Successfully.
Exception Insufficient space/Internet connection required
Section 3.3.8: Access Information
Use Case Name Accountant

XRef Section 3.3.1, Download app and 3.3.2 Access usecase
Trigger The User gets the homepage activity.
Precondition The System uses the policy providing.
Process Customer Accept the Policy and terms. Customer access
different Information from homepage.
Postcondition The user information has been added to the database.
Exception Paths Internet Connection Required.

Other None.
Section 3.3.9: Add Information
Use Case Name Add usecase

XRef Sec 3.3.3
Trigger The Admin clicks on add icon on any activity which is on top
left side on activity.
Precondition The admin needs an internet connection and valid information
Basic Path The admin will enter the information
Alternative Paths The app will add the information..
Postcondition The Information has been added to the database
Exception Paths Internet connection required.
Other None
Section 3.3.10: Order Cake
Use Case Name Agent

XRef Sec 3.3.4
Trigger The user clicks on categories of cake and order the cake.
Precondition The customer have knowledge about app.
Basic Path Customer checks for all types of cake
Postcondition Cake is ordered and information added to the database.
Exception Paths Internet connection required.
Other None
Section 3.3.11: feedback usecase
Use Case Name Feedback usecase

XRef Sec 3.3.5
Trigger The Feedback about the app it may be complaint or positive

responses.
Basic Path User enters there feedback
Postcondition The database has been updated.
Alternative Paths The feedback is stored on the database.
Other None
3.4 Non-Functional Requirements

The Tutu’s cake shop application will be on a server with high speed Internet capability. The
physical machine to be used will be determined by the Historical Society. The application

developed here assumes the use of a tool such as Android studio and jdk for connection between
the activities and the database. The speed of the users connection will depend on the hardware
used rather than characteristics of this system.
The Article Manager will run on the editor’s PC and will contain an Access database. Access
is already installed on the mobile and is a Android operating system.
3.5 Logical Structure of Application
The logical structure of the data to be stored in the internal Cake shop application database is
given below.

Fig3.5: ER Diagram

3.6 Database of Cake shop Application.
1. Sign Up
Sr.No Name Datatype Key
1 user_name Varchar -
2 Mail Varchar -
3 user_contact Varchar -
2. Customer
1 c_id Integer Primary Key

2 c_name Varchar -
3 c_address Varchar -
4 c_contact Varchar -
5 email_id Varchar -
3. Cake
1 cake_id Integer Primary Key

2 cake_name Varchar -
3 cake_flavour Varchar -
4 cake_price Varchar -
5. cake_expiry Varchar -

4. Order
1 order_id Integer Primary Key

2 order_type Varchar -
3 d_date Date -
4 d_time Time -
5 staff_id Varchar Foreign key
6 cake_id Integer Foreign key
7 c_address Varchar Foreign key
5. Staff
1 staff_id Integer Primary Key

2 staff_name Varchar -
3 staff_address Varchar -
4 staff_DOB Date -
5 staff_contact Varchar -
6 staff_email_id Varchar -
6. Payment
1 p_id Integer Primary Key

2 p_method Varchar -
3 p_details Varchar -
4 p_amt Integer -

7. Facility
1 facility_id Integer Primary Key

2 facility_name Varchar -
3 facility_type Varchar -
5 facility_desc Varchar -
8. Shop
1 shop_id Integer Primary Key

2 shop_name Varchar -
3 shop_address Varchar -
5 shop_contact Varchar -
6 shop_mailid Varchar -
3.7 Other Requirements

Catch all section for any additional requirements.
3.8 Security
The server on which the Application resides will have its own security to prevent
unauthorized access of the application. There is no restriction on access. The use of email by an
admin or customer is on the application and thus is external to the system.
The Phone on which the Application resides or installed will have its own security. Only
the User will have physical access to the mobile and the application installed on it. There is no
special protection built into this application.

4. CHANGE MANAGEMENT PROCESS
Identify and describe the process that will be used to update the SRS, as needed,
when project scope or requirements change. Who can submit changes and by what means,
and how will these changes be approved.
A. Appendices
A.1 Appendix 1
A.2 Appendix 2
*End of the SRS*

Cake Shop Application SRS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cake Shop Application SRS

Uploaded by

Copyright:

Available Formats

Cake Shop Application

Software Requirements Specification

“Tutu’s Cake Shop Application”

Submitted in Partial fulfillment of

Software Requirements Specification Page 1

Date Description Author Comments

Software Requirements Specification Page 2

DOCUMENT APPROVAL .................................................................................................................... 2

3. SPECIFIC REQUIREMENTS ............................................................................................................12

Software Requirements Specification Page 3

Figure 1-System Environment----------------------------------------------------------------------------------10

Software Requirements Specification Page 4

Overall, the project presents a comprehensive understanding of how to realize city

Software Requirements Specification Page 5

1.3 Definitions, Acronyms, and Abbreviations

phone application and computer system

Admin/Administrator System administrator who is given

specific permission for managing and

controlling the system

Company Employee Someone who has a company and wants

his branch to be a part the application

Web-portal A web application which present special

facilities for company employee and

GPS Global Positioning System

Application Store An installed application on mobile phone

or computer which helps user to find new

compatible applications with mobile

phone platform and download them from

Software Requirements Specification Page 6

The third chapter, Requirements Specification section, of this document is written

intended for different audiences and thus use different language

Software Requirements Specification Page 7

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

Partly skilled user

Software Requirements Specification Page 8

Highly skilled user

2.4 General Constraints

2.5 Assumptions and Dependencies

Software Requirements Specification Page 9

2.6 System Environment

Flavours of Cakes and managing overall operations and order, is an example of

using domain classes to make an explanation clearer. >>

Software Requirements Specification Page 10

their requirements are. This is sometimes also called requirements gathering.

natural-language documents, use cases, user stories, or process specifications.

3.1 System Interface

3.1.2 Highlights of Android

Software Requirements Specification Page 11

3.1.3 Introduction of Android

Figure 3.1.3: Architecture of android platform

Software Requirements Specification Page 12

3.1.4 Application Fundamentals

Software Requirements Specification Page 13

Figure 3.1.4: The Lifetime of Activity

3.1.5 Location sensing technologies

Software Requirements Specification Page 14

3.2.2 Hardware Interfaces

3.2.4 Communication Interfaces

Software Requirements Specification Page 15

3.3 Functional Requirements

End of the SRS