Beruflich Dokumente
Kultur Dokumente
<1.0>
<20th Aug, 2018 >
Badhe Pooja S.
Lead Software Engineer
Revision History
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
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
List of figures
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.
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.
admin
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.
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
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.
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.
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.
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.
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
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:
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.”
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.
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. .
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
Access Info
Customer/user
Brief Description
The customer will access the information from the different activity like as cakes, flavours, price,
etc.
Initial Step-By-Step Description
Before this use case can be initiated, the customer has already downloaded and installed the Cake
shop app.
Generate report
Brief Description
The Admin able to make updation on Information such as adding new cakes, policies in existing
activity, etc.
user
Brief Description
The customer order the cake online and gets home delivery.
Initial Step-By-Step Description
1. Selection of cake/ cake flavour.
2. Give order of cake and make payment.
3. Get home delivery.
Xref: section 3.3.10
Give feedback
user
Brief Description
The Feedback about the app it may be complaint or positive responsens.
Other None.
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
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
1. Sign Up
Sr.No Name Datatype Key
1 user_name Varchar -
2 Mail Varchar -
3 user_contact Varchar -
2. Customer
3. Cake
4. Order
5. Staff
6. Payment
7. Facility
8. Shop
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
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
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