Srs Example 2010 Group2 PDF

Software Requirements
Specification
Amazing Lunch Indicator
Sarah Geagea 881024-4940

Sheng Zhang 850820-4735
Niclas Sahlin 880314-5658
Faegheh Hasibi 870625-5166
Farhan Hameed 851007-9695
Elmira Rafiyan 840724-5383
Magnus Ekberg 851022-1933
Table of Contents
1. Introduction ............................................................................................................................................... 1
1.1 Purpose................................................................................................................................................ 1
1.2 Scope ................................................................................................................................................... 1
1.3 Definitions, acronyms, and abbreviations ........................................................................................... 1
1.4 References ........................................................................................................................................... 2
2. Overall description .................................................................................................................................... 4
2.1 Product perspective ............................................................................................................................. 4
2.2 Product functions ................................................................................................................................ 4
2.3 User characteristics ............................................................................................................................. 5
2.4 Constraints .......................................................................................................................................... 5
2.5 Assumptions and dependencies .......................................................................................................... 5
2.6 Apportioning of requirements ............................................................................................................. 6
3. Specific requirements................................................................................................................................ 7
3.1.1 User interfaces ............................................................................................................................. 7
3.1.2 Hardware interfaces ..................................................................................................................... 8
3.1.3 Software interfaces ....................................................................................................................... 8
3.1.4 Communications interfaces .......................................................................................................... 9
3.2 Functional requirements ...................................................................................................................... 9
3.2.1 User Class 1 - The User ............................................................................................................... 9
3.2.2 User Class 2 - Restaurant Owner ............................................................................................... 14
3.2.3 User Class 3 - Administrator ...................................................................................................... 18
3.3 Performance requirements ................................................................................................................ 21
3.4 Design constraints ............................................................................................................................. 23
3.5 Software system attributes ................................................................................................................ 23
4. Prioritization and Release Plan ............................................................................................................... 27
4.1 Choice of prioritization method ........................................................................................................ 27
Appendix I: Selection for Cost-Value Approach ........................................................................................ 29
Appendix II: Prioritization Result of 10 selected Requirements Using Cost-Value Approach .................. 32
Appendix III: Five-Way Priority Scheme ................................................................................................... 36
Appendix IV: Release Plan ......................................................................................................................... 47
Appendix V: I-star ...................................................................................................................................... 55
1. Introduction
This section gives a scope description and overview of everything included in this SRS document. Also,
the purpose for this document is described and a list of abbreviations and definitions is provided.
1.1 Purpose
The purpose of this document is to give a detailed description of the requirements for the Amazing
Lunch Indicator (ALI) software. It will illustrate the purpose and complete declaration for the
development of system. It will also explain system constraints, interface and interactions with other
external applications. This document is primarily intended to be proposed to a customer for its approval
and a reference for developing the first version of the system for the development team.
1.2 Scope
The Amazing Lunch Indicator is a GPS-based mobile application which helps people to find the closest
restaurants based on the users current position and other specification like price, restaurant type, dish and
more. The application should be free to download from either a mobile phone application store or similar
services.
Restaurant owners can provide their restaurant information using the web-portal. This information will act
as the bases for the search results displayed to the user. An administrator also uses the web-portal in order
to administer the system and keep the information accurate. The administrator can, for instance, verify
restaurant owners and manage user information.
Furthermore, the software needs both Internet and GPS connection to fetch and display results. All system
information is maintained in a database, which is located on a web-server. The software also interacts
with the GPS-Navigator software which is required to be an already installed application on the users
mobile phone. By using the GPS-Navigator, users can view desired restaurants on a map and be navigated
to them. The application also has the capability of representing both summary and detailed information
about the restaurants.
1.3 Definitions, acronyms, and abbreviations

Table 1 - Definitions
Term
Definition
User
Someone who interacts with the mobile phone application
Admin/Administrator System administrator who is given specific permission for managing and
controlling the system
Restaurant Owner
Someone who has a restaurant and wants his restaurant to be a part the
application
Web-Portal
A web application which present special facilities for restaurant owner

1
and admin
GPS
Global Positioning System
GPS-Navigator
An installed software on mobile phone which could provide GPS

connection and data, show locations on map and find paths from current
position to defined destination
Application Store
An installed application on mobile phone which helps user to find new

compatible applications with mobile phone platform and download them
from Internet
Stakeholder
Any person who has interaction with the system who is not a developer.
DESC
Description
RAT
Rational
DEP
Dependency
TAG
A unique, persistent identifier contained in a PLanguage statement [2]
GIST
A short, simple description of the concept contained in a PLanguage

statement [2]
SCALE
The scale of measure used by the requirement contained in a PLanguage

statement [2]
METER
The process or device used to establish location on a SCALE contained

in a PLanguage statement [2]
MUST
The minimum level required to avoid failure contained in a PLanguage

statement [2]
PLAN
The level at which good success can be claimed contained in a PLanguage

statement [2]
WISH
A desirable level of achievement that may not be attainable through available

means contained in a PLanguage statement [2]
DEFINED
The official definition of a term contained in a PLanguage statement [2]
1.4 References
[1] IEEE Software Engineering Standards Committee, IEEE Std 830-1998, IEEE Recommended
Practice for Software Requirements Specifications, October 20, 1998.
[2] Feldt R,re_lecture5b_100914, unpublished.
[3] Davis M A, Just Enough Requirements Management: Where Software Development Meets
Marketing, New York, Dorset House Publishing, 2005.
[4] Karlsson J, A Cost-Value Approach for Prioritizing Requirements, Norges TekniskNaturvitenskapelige Uni. 1997
1.5 Overview
The remainder of this document includes three chapters and appendixes. The second one provides an
overview of the system functionality and system interaction with other systems. This chapter also
introduces different types of stakeholders and their interaction with the system. Further, the chapter also
mentions the system constraints and assumptions about the product.
The third chapter provides the requirements specification in detailed terms and a description of the
different system interfaces. Different specification techniques are used in order to specify the
requirements more precisely for different audiences.
The fourth chapter deals with the prioritization of the requirements. It includes a motivation for the
chosen prioritization methods and discusses why other alternatives were not chosen.
The Appendixes in the end of the document include the all results of the requirement prioritization and a
release plan based on them.
2. Overall description
This section will give an overview of the whole system. The system will be explained in its context to
show how the system interacts with other systems and introduce the basic functionality of it. It will also
describe what type of stakeholders that will use the system and what functionality is available for each
type. At last, the constraints and assumptions for the system will be presented.
2.1 Product perspective

This system will consist of two parts: one mobile application and one web portal. The mobile application
will be used to find restaurants and view information about them while the web portal will be used for
managing the information about the restaurants and the
system as a whole.
The mobile application will need to communicate to a GPS
application within the mobile phone, which in turn
communicates with a physical GPS device to find the
location of the user, see Figure 1. The GPS will provide the
mobile application with locations of both the user and the
restaurants and the distance between them, but it will also
provide maps and the functionality to display the
applications data on the map. The functionality provided
by the GPS will be embedded into the application in order
for the user to be able to use the functions in the application
in a seamlessly manner.
Since this is a data-centric product it will need somewhere
to store the data. For that, a database will be used. Both the
mobile application and web portal will communicate with
the database, however in slightly different ways. The mobile
application will only use the database to get data while the
web portal will also add and modify data. All of the
database communication will go over the Internet.
Figure 1 - Block diagram
The mobile application has some restrictions about the

resource allocation. To avoid problems with overloading the operating system the application is only
allowed to use 20 megabytes of memory while running the application. The maximum amount of hard
drive space is also 20 megabytes.
2.2 Product functions

With the mobile application, the users will be able to search for restaurants. The result will be based on
the criteria the user inputs. There are several search criteria and it will be possible for the administrator of
the system to manage the options for those criteria that have that.
The result of the search will be viewed either in a list view or in a map view, depending on what criteria
included in the search. The list view will have one list item for each restaurant matching the search
criteria and show a small part of the restaurant information so the user can identify the restaurant. The
4
map view will show each restaurant location as a pin on the map as well as the users own location. In
both views the users will be able to either select a restaurant as target destination or get information how
to get there, or view the information of a specific restaurant.
The web portal will provide functionality to manage the system and the restaurant information. It will also
provide information about the system, for example show when there is a new update.
2.3 User characteristics

There are three types of users that interact with the system: users of the mobile application, restaurant
owners and administrators. Each of these three types of users has different use of the system so each of
them has their own requirements.
The mobile application users can only use the application to find a restaurant. This means that the user
have to be able to search for restaurants, choose a restaurant from that search and then navigate to it. In
order for the users to get a relevant search result there are multiple criteria the users can specify and all
results matches all of those.
The restaurant owners will not use the mobile application but the web portal instead. There they will
manage the information about their restaurant, for example a description of the restaurant, contact
information and their menu.
The administrators also only interact with the web portal. They are managing the overall system so there
is no incorrect information within it. The administrator can manage the information for each restaurant as
well as the options for both the mobile application users and the restaurant owners.
2.4 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
would mean the integration with the GPS would have different requirements than what is stated in this
specification.
2.6 Apportioning of requirements

In the case that the project is delayed, there are some requirements that could be transferred to the next
version of the application. Those requirements are to be developed in the third release, see Appendix IV.
3. Specific requirements
This section contains all of the functional and quality requirements of the system. It gives a detailed
description of the system and all its features.
3.1 External interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also gives a
description of the hardware, software and communication interfaces and provides basic prototypes of the
user interface.
3.1.1 User interfaces
A first-time user of the mobile application should see the log-in page when he/she opens the application,
see Figure 2. If the user has not registered, he/she should be able to do that on the log-in page.
If the user is not a first-time user, he/she should be able to see the search page directly when the
application is opened, see Figure 3. Here the user chooses the type of search he/she wants to conduct.
Every user should have a profile page where they can edit their e-mail address, phone number and
password, see Figure 4. Also, the user can set the mobile application to his/her preferred language. The
P icon shows where the user can click to navigate to his/her profile page.
Figure 2 - Login page
Figure 3 Search page
Figure 4 Profile page
In Figure 5, the list view for the results is shown. When a user searches by price, this view should be the
default one. The sorting header allows the user to sort the results according to price, restaurant name,
distance, restaurant type and specific dish. Each result item includes information about the restaurants, a
link to the restaurants web-page and an information link, which provides a more detailed description of
the restaurant. There is also a filtering option, where the user can choose to filter the results by increasing
or decreasing the price or distance range, see Figure 7.
In the map view each restaurant is represented by a pin, see Figure 6. Next to every pin there is an
information link which provides a more detailed description of the restaurant, as mentioned for the list
view. The same filtering option, as for the list view, is included in the map view.
The restaurant owners and administrators interact with the system through a web-portal, see Figure 8. A
restaurant owner should be able to register on the web-portal in order to log in and manage the restaurant
information. An administrator should also be able to log in to the web-portal where he/she can administer
the system by for instance editing restaurant or user information.
Figure 5 List view
Figure 6 Map view
Figure 7 Filter menu
Figure 8 Web Portal
3.1.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
8
about where the user is located and the visual representation of it, and with the database in order to get the
information about the restaurants, see Figure 1. 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.1.4 Communications 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.2 Functional requirements

This section includes the requirements that specify all the fundamental actions of the software system.
3.2.1 User Class 1 - The User
3.2.1.1 Functional requirement 1.1
ID: FR1
TITLE: Download mobile application
DESC: 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.
RAT: In order for a user to download the mobile application.
DEP: None
ID: FR2
TITLE: Download and notify users of new releases
DESC: When a new/updated version or release of the software is released, the user should check for these
manually. The download of the new release should be done through the mobile phone in the same way as
downloading the mobile application.
RAT: In order for a user to download a new/updated release.
DEP: FR1
ID: FR3
TITLE: User registration - Mobile application
DESC: Given that a user has downloaded the mobile application, then the user should be able to register
through the mobile application. The user must provide user-name, password and e-mail address. The user
can choose to provide a regularly used phone number.
RAT: In order for a user to register on the mobile application.
DEP: FR1

ID: FR4
TITLE: User log-in - Mobile application
DESC: Given that a user has registered, then the user should be able to log in to the mobile application.
The log-in information will be stored on the phone and in the future the user should be logged in
automatically.
RAT: In order for a user to register on the mobile application.
DEP: FR1, FR3
ID: FR5
TITLE: Retrieve password
DESC: Given that a user has registered, then the user should be able to retrieve his/her password by email.
RAT: In order for a user to retrieve his/her password.
DEP: FR1
ID: FR6
TITLE: Mobile application - Search
DESC: Given that a user is logged in to the mobile application, then the first page that is shown should be
the search page. The user should be able to search for a restaurant, according to several search options.
The search options are Price, Destination, Restaurant type and Specific dish. There should also be a freetext search option. A user should be able to select multiple search options in one search.
RAT: In order for a user to search for a restaurant.
DEP: FR4
ID: FR7
TITLE: Mobile application - Search result in a map view
DESC:
Search results can be viewed on a map. On the map, the relevant and closest restaurants according
to the users position are shown.
A specific pin will represent a specific restaurant location. On each pin there should be an
information link.
There should be maximally 100 results displayed. The map view should have a default zoom.
The map view should include a button that, when selected, should display different filtering
options in a filtering menu.
RAT: The way results are displayed in a map.

DEP: FR6
10

ID: FR8
TITLE: Mobile application - Search result in a list view
DESC:
Search results can be viewed in a list. Each element in the list represents a specific restaurant.
Each element should include the restaurant name, telephone number, type of food, distance
according to the users position, average price, a short two-line description, a link to the
restaurants web-page and an information link.
There should be maximally 100 results displayed. If the result contains more restaurants than
what can be displayed on the screen at one time, the user should be able to scroll through them.
When searching by price the restaurants should be sorted according to the following order:
1. average price
2. distance
3. restaurant type
4. specific dish
When searching by a search option, other than price, the restaurants should be sorted according to
the following order:
1. distance
2. average price
3. restaurant type
4. specific dish
The list view should include a header with different selectable sorting options.
The list view should include a button that, when selected, should display different filtering
options in a filtering menu.
RAT: The way results should be displayed in a list.

DEP: FR6
ID: FR9
TITLE: Mobile application - Navigation to restaurant
DESC: A user should be able to select a pin on a map or an element on a list. When a selection is made,
the location of the restaurant should be sent to the mobile phones GPS-navigation program. The user
should then be navigated to the destination. When the destination is reached, a user should be able to go
back to the search page on the mobile application.
RAT: To navigate a user to a chosen restaurant.
DEP: FR7, FR8
ID: FR10
TITLE: Mobile application - Switch result view
DESC: A user should be able to switch between a map view and a list view for all search options.
11
RAT: In order for a user to switch between result views.

DEP: FR7, FR8
ID: FR11
TITLE: Mobile application - Selecting the information link
DESC: A user should be able to select the information link, which is included on all result items. The link
will direct the user to an information page, which includes a picture of the restaurant, the restaurant name,
address, phone number, e-mail address, type of food, average price, restaurant description and a menu
with name, description and price of the different dishes.
RAT: In order to show information about the restaurants.
DEP: FR7, FR8
ID: FR12
TITLE: Mobile application - Search by price
DESC: A user should be able to input a maximum and a minimum price range. The result is displayed in
a list view by default.
RAT: In order for a user to search by price.
DEP: FR8
ID: FR13
TITLE: Mobile application - Search by destination
DESC: A user should be able to input a maximum and a minimum distance, according to his/her position.
By default the minimum distance is set to 0 km and the maximum to 10 km. The user should be able to
input a higher or lower maximum distance and a higher minimum distance than set by default. The result
is displayed in a map view by default.
RAT: In order for a user to search by destination.
DEP: FR7
ID: FR14
TITLE: Accepted input for price and destination search
DESC: Integers should be accepted as input when a user searches by price or destination. If the system
receives an invalid input the user should be informed and prompted to insert an accepted input.
RAT: In order for a user to search with valid input.
DEP: FR12, FR13
ID: FR15
TITLE: Mobile application - Search by restaurant type
12
DESC: A user should be able to select a restaurant type in a given list as input. The result is displayed in a
map view by default.
RAT: In order for a user to search by restaurant type.
DEP: FR7
ID: FR16
TITLE: Mobile application - Search by specific dish
DESC: A user should be able to select a specific dish in a given list as input. The result is displayed in a
map view by default.
RAT: In order for a user to search by specific dish.
DEP: FR7
ID: FR17
TITLE: Mobile application - Free-text search
DESC: A user should be able to conduct a search by providing either restaurant name, restaurant
description, restaurant address, restaurant type or restaurant menu in the free-text search field. The result
is displayed in a map view by default.
RAT: In order for a user to search through the free-text search.
DEP: FR7
ID: FR18
TITLE: Mobile application - No match found
DESC: If no match is found the user should be informed but kept on the search page in order to get the
possibility to conduct a new search right away.
RAT: In order for user to conduct a new search if no match is found.
DEP: FR5
ID: FR19
TITLE: Mobile application - Sorting results
DESC: When viewing the results in a list, a user should be able to sort the results according to price,
distance, restaurant type, specific dish or restaurant name.
When sorting by restaurant name, specific dish or restaurant type the results should be ordered
alphabetically.
When sorting by price the results should be ordered from cheapest to most expensive.
When sorting by distance the results should be ordered from closets to furthest distance according
to the users position.
13
When the sort button for a specific search option is clicked, then the order should be reversed and ordered
in a descending matter. If the sort button is clicked again the order of the results should be reversed.
RAT: In order for a user to sort results in a list.
DEP: FR8
ID: FR20
TITLE: Mobile application - Filtering results
DESC: When viewing the results in a list or a map, a user should be able to filter the results in a filtering
menu. The filtering options include:
increasing or decreasing the maximum distance

increasing or decreasing the maximum price
choosing a restaurant type
choosing a specific dish
When filtering the results, only the existing results shall be affected and a new search query should not be
sent.
RAT: In order for a user to filter results in a list or a map.
DEP: FR7, FR8
ID: FR21
TITLE: Mobile application - Profile page
DESC: On the mobile application, a user should have a profile page. On the profile page a user can edit
his/her information, which includes the password, e-mail address and phone number. A user should also
be able to choose what language the mobile application should be set to. The different language choices
are Swedish, English, Spanish and French.
RAT: In order for a user to have a profile page on the mobile application.
DEP: FR1
3.2.2 User Class 2 - Restaurant Owner
ID: FR22
Feature: Create an account
In order to create an account
A restaurant owner
Should register on the web-portal
Scenario: Required information for registration
Given the restaurant owner wants to create an account
And the restaurant owner does not have an account
14
When the restaurant owner registers on the web-portal by providing user-name

And password
And address
And e-mail address
And phone number
Then the restaurant owner should be able to apply for verification
Scenario: Full information for registration
Given the restaurant owner wants to create an account
And the restaurant owner does not have an account
When the restaurant owner registers on the web-portal by providing user name
And password
And address
And e-mail address
And phone number
And mobile number
Then the restaurant owner should be able to apply for verification
Scenario: Confirmed registration
Given the restaurant owner has applied for verification
And has not received a confirmation e-mail after registration
When the restaurant owner receives a confirmation e-mail
Then the restaurant owner should be able to log in
ID: FR23
Feature: Restaurant owner log-in
In order to use the system
A restaurant owner
Should be logged in to the web-portal
Scenario: Successful log-in
Given the restaurant owner wants to log in
When the restaurant owner logs in with his/her account
Then the restaurant owner should be logged in as a restaurant owner
Scenario: Retrieve password
Given the restaurant owner wants to log in
And has lost the password
When the restaurant owner enters his/her email address in the Retrieve password form
And submits the form
Then the restaurant owner should receive an email containing the password
15

ID: FR24
Feature: Manage information
In order to manage information
A restaurant owner
Scenario: Show fields for managing information

Given the restaurant owner is logged in
When the restaurant owner wants to manage information
Then the restaurant owner should be able to manage information in a form
Scenario: Filling in mandatory fields
Given the restaurant owner wants to fill in the mandatory fields of the form
When the restaurant owner provides average price
And address
And e-mail address
And phone number
And restaurant name
Then the restaurant owner has filled the mandatory fields of the form
Scenario: Filling in optional fields
Given the restaurant owner of a restaurant wants to fill in optional fields in the form
When the restaurant owner provides restaurant description
And menu
And type of restaurant
And picture of restaurant
And mobile phone
Then the restaurant owner has filled in optional fields in the form
Scenario: Filling in menu field
Given the restaurant owner wants to fill in the menu field in the form
When the restaurant owner provides dish name
And dish description
And dish price
Then the restaurant owner has filled in the menu field in the form
Scenario: Adding information with mandatory fields
Given the restaurant owner has filled in the mandatory fields of the form
When the restaurant owner submits the form
Then the information about the restaurant should be added
Scenario: Adding information with mandatory and optional fields
Given the restaurant owner has filled in the mandatory fields of the form
16
And filled in one or more optional fields of the form

When the restaurant owner submits the form
Then the information about the restaurant should be added
Scenario: Deleting information
And information exists
When the restaurant owner deletes information
Then the information should be deleted
Scenario: Editing information
And information exists
When the restaurant owner edits information
Then the information should be edited
ID: FR25
Feature: Restaurant owner - Selecting preferred language on the web-portal
In order to understand the web-portal
A restaurant owner
Should be able to select a preferred language for the web-portal
Scenario: Select English as preferred language
Given the restaurant owner wants to select a preferred language
When the restaurant owner selects English as a new language
Then the web-portal will show all text in English
Scenario: Select Swedish as preferred language
When the restaurant owner selects Swedish as a new language
Then the web-portal will show all text in Swedish
Scenario: Select French as preferred language
When the restaurant owner selects French as a new language
Then the web-portal will show all text in French
Scenario: Select Spanish as preferred language
When the restaurant owner selects Spanish as a new language
Then the web-portal will show all text in Spanish
17
3.2.3 User Class 3 - Administrator

ID: FR26
Feature: Administrator log in
In order to administer the system
An administrator
Scenario: Successful log-in
Given the administrator wants to log in
When the administrator logs in with an administrator account
Then the administrator should be logged in as an administrator
ID: FR27
Feature: Verify restaurant owner
In order to allow a restaurant owner to use the system
An administrator
Should be able to verify the restaurant owner
Scenario: Verify a restaurant owner
Given the administrator is logged in
When the administrator verifies a restaurant owner
Then the restaurant owner should be able to log in
And the restaurant owner should be notified by a confirmation email
Scenario: Reject a restaurant owner
When the administrator rejects a restaurant owner
Then the restaurant owner should not be able to log in
And the restaurant owner should be notified by a rejection email
ID: FR28
Feature: Manage restaurant types
In order to have a list of restaurant types
An administrator
Should be able to manage the restaurant types
Scenario: Add a new restaurant type
When the administrator creates a new restaurant type
Then the new restaurant type should be added to the list of restaurant types
18
Scenario: Editing an existing restaurant type

When the administrator edits an existing restaurant type
Then the restaurant type should be updated in the list of restaurant types
Scenario: Delete a restaurant type
When the administrator deletes a restaurant type
Then the deleted restaurant type should be removed from the list of restaurant types
ID: FR29
Feature: Manage restaurant dishes
In order to have a list of dishes
An administrator
Should be able to manage the dishes
Scenario: Add a new dish
When the administrator creates a new dish
Then the new dish should be added to the list of dishes
Scenario: Editing an existing dish
When the administrator edits an existing dish
Then the dish should be updated in the list of dishes
Scenario: Delete a dish
When the administrator deletes a dish
Then the deleted dish should be removed from the list of dishes
ID: FR30
Feature: Manage restaurant information
In order to manage restaurant information
An administrator
Scenario: Add restaurant information
When the administrator adds restaurant information
Then the information should be added to the restaurant
Scenario: Delete restaurant information
19
And information about a restaurant exists

When the administrator deletes the information
Then the information about the restaurant should be deleted
Scenario: Edit restaurant information
And information about a restaurant exists
When the administrator edits the information
Then the information about the restaurant should be edited
ID: FR31
Feature: Manage users
In order to keep track of the users
An administrator
Should be able to manage the users
Scenario: Edit an existing users information
When the administrator edits an existing user
Then the user information should be updated
Scenario: Delete/Inactivate an existing user
When the administrator deletes an existing user
Then the user should be deleted
ID: FR32
Feature: Manage restaurant owners
In order to keep track of the restaurant owners
An administrator
Should be able to manage the restaurant owners
Scenario: Add a new restaurant owner
When the administrator creates a new restaurant owner
Then the new restaurant owner should be added
Scenario: Edit an existing restaurant owner
When the administrator edits an existing restaurant owner
Then the restaurant owner information should be updated
Scenario: Delete an existing restaurant owner
20
When the administrator deletes an existing restaurant owner

Then the restaurant owner should be deleted
And the restaurant information should be deleted
ID: FR33
Feature: Administrator - Selecting preferred language on the web-portal
In order to understand the web-portal
An administrator
Should be able to select a preferred language for the web-portal
Scenario: Select English as preferred language
Given the administrator wants to select a preferred language
When the administrator selects English as a new language
Then the web-portal will show all text in English
Scenario: Select Swedish as preferred language
When the administrator selects Swedish as a new language
Then the web-portal will show all text in Swedish
Scenario: Select French as preferred language
When the administrator selects French as a new language
Then the web-portal will show all text in French
Scenario: Select Spanish as preferred language
When the administrator selects Spanish as a new language
Then the web-portal will show all text in Spanish
3.3 Performance requirements

The requirements in this section provide a detailed specification of the user interaction with the software
and measurements placed on the system performance.
3.3.1 Prominent search feature
ID: QR1
TITLE: Prominent search feature
DESC: The search feature should be prominent and easy to find for the user.
RAT: In order to for a user to find the search feature easily.
DEP: none
21
3.3.2 Usage of the search feature

ID: QR2
TITLE: Usage of the search feature
DESC: The different search options should be evident, simple and easy to understand.
RAT: In order to for a user to perform a search easily.
DEP: none
3.3.3 Usage of the result in the list view
ID: QR3
TITLE: Usage of the result in the list view
DESC: The results displayed in the list view should be user friendly and easy to understand. Selecting an
element in the result list should only take one click.
RAT: In order to for a user to use the list view easily.
DEP: none
3.3.4 Usage of the result in the map view
ID: QR4
TITLE: Usage of the result in the map view
DESC: The results displayed in the map view should be user friendly and easy to understand. Selecting a
pin on the map should only take one click.
RAT: In order to for a user to use the map view easily.
DEP: none
3.3.5 Usage of the information link
ID: QR5
TITLE: Usage of the information link
DESC: The information link should be prominent and it should be evident that it is a usable link.
Selecting the information link should only take one click.
RAT: In order to for a user to use the information link easily.
DEP: none
3.3.6 Response time
ID: QR6
TAG: ResponseTime
GIST: The fastness of the search
SCALE: The response time of a search
METER: Measurements obtained from 1000 searches during testing.
MUST: No more than 2 seconds 100% of the time.
WISH: No more than 1 second 100% of the time.
22
3.3.7 System dependability

ID: QR8
TAG: SystemDependability
GIST: The fault tolerance of the system.
SCALE: If the system loses the connection to the Internet or to the GPS device or the system gets some
strange input, the user should be informed.
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: 100% of the time.
3.4 Design constraints

This section includes the design constraints on the software caused by the hardware.
3.4.1 Hard drive space
ID: QR10
TAG: HardDriveSpace
GIST: Hard drive space.
SCALE: The applications need of hard drive space.
METER: MB.
MUST: No more than 20 MB.
PLAN: No more than 15 MB.
WISH: No more than 10 MB.
MB: DEFINED: Megabyte
3.4.2 Application memory usage
ID: QR11
TAG: ApplicationMemoryUsage
GIST: The amount of Operate System memory occupied by the application.
SCALE: MB.
METER: Observations done from the performance log during testing
MUST: No more than 20 MB.
PLAN: No more than 16 MB
WISH: No more than 10 MB
Operate System: DEFINED: The mobile Operate System which the application is running on.
MB: DEFINED: Megabyte.
3.5 Software system attributes

The requirements in this section specify the required reliability, availability, security and maintainability
of the software system.
3.5.1 Reliability
ID: QR9
TAG: SystemReliability
23
GIST: The reliability of the system.

SCALE: The reliability that the system gives the right result on a search.
METER: Measurements obtained from 1000 searches during testing.
MUST: More than 98% of the searches.
PLAN: More than 99% of the searches.
WISH: 100% of the searches.
3.5.2 Availability
ID: QR7
TAG: SystemAvailability
GIST: The availability of the system when it is used.
SCALE: The average system availability (not considering network failing).
METER: Measurements obtained from 1000 hours of usage during testing.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.
ID: QR22
TITLE: Internet Connection
DESC: The application should be connected to the Internet.
RAT: In order for the application to communicate with the database.
DEP: none
ID: QR23
TITLE: GPS Connection
DESC: The application should be connected to the GPS device.
RAT: In order for the application to get the users location, the map and to calculate the distance.
DEP: none
3.5.3 Security
ID: QR12
TAG: CommunicationSecurity
GIST: Security of the communication between the system and server.
SCALE: The messages should be encrypted for log-in communications, so others cannot get user-name
and password from those messages.
METER: Attempts to get user-name and password through obtained messages on 1000 log-in session
during testing.
MUST: 100% of the Communication Messages in the communication of a log-in session should be
encrypted.
Communication Messages: Defined: Every exchanged of information between client and server.
ID: QR13
TAG: RestaurantOwnerLoginAccountSecurity
GIST: Security of accounts.
24
SCALE: If a restaurant owner tries to log in to the web portal with a non-existing account then the
restaurant owner should not be logged in. The restaurant owner should be notified about log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
ID: QR14
TAG: AdminLoginAccountSecurity
GIST: Security of accounts.
SCALE: If an admin tries to log in to the web portal with a non-existing account then the admin should
not be logged in. The admin should be notified about log-in failure.
METER: 1000 attempts to log-in with a non-existing user account during testing.
ID: QR15
TAG: RestaurantOwnerAccountSecurity
GIST: Security of restaurant owners accounts.
SCALE: A restaurant owner and IP address should not be able to log-in for a certain time period after
three times of failed log-in attempts.
METER: 1000 attempts to log-in during the lock period after user account has been locked because of
failed log-in attempts of three times.
MUST: The locking period should be half an hour, and during that period the log-in function is disabled.
ID: QR16
TAG: AdminAccountSecurity
GIST: Security of admin accounts.
SCALE: An admin and IP address should not be able to log-in to the web portal for a certain time period
after three times of failed log-in attempts.
METER: 1000 attempts to log-in during the lock period after user account has been locked because of
failed log-in attempts of three times.
MUST: The locking period should be half an hour, and during that period the log-in function is disabled.
ID: QR17
TAG: UserCreateAccountSecurity
GIST: The security of creating account for users of the system.
SCALE: If a user wants to create an account and the desired user name is occupied, the user should be
asked to choose a different user name.
METER: Measurements obtained on 1000 hours of usage during testing.
ID: QR18
TAG: RestaurantOwnerCreateAccountSecurity
GIST: The security of creating account for restaurant owners of the system.
SCALE: If a restaurant owner wants to create an account and the desired user name is occupied, the
restaurant owner should be asked to choose a different user name.
METER: Measurements obtained on 1000 hours of usage during testing.
25
3.5.4 Maintainability
ID: QR19
TITLE: Application extendibility
DESC: The application should be easy to extend. The code should be written in a way that it favors
implementation of new functions.
RAT: In order for future functions to be implemented easily to the application.
DEP: none
ID: QR21
TITLE: Application testability
DESC: Test environments should be built for the application to allow testing of the applications different
functions.
RAT: In order to test the application.
DEP: none
3.5.5 Portability
ID: QR20
TITLE: Application portability
DESC: The application should be portable with iOS and Android.
RAT: The adaptable platform for the application to run on.
DEP: none
26
4. Prioritization and Release Plan

In order to get a view of how to divide the requirements into different releases and what requirements
should be included in which release, a prioritization of the requirements is needed. This section discusses
the choice of prioritization methods and gives a suggestion of how the release plan for these requirements
could look like.
4.1 Choice of prioritization method

When prioritizing the requirements the ten most important ones were picked out first. This was done with
a simple 1 to 10 ranking method, with one being not important and ten very important. Based on
the elicitation meetings, and the perceived ideas of what was important to the different stakeholders, a
number was set for each requirement. The numbers were then summed up for each requirement and the
ten with the highest score were chosen to be prioritized with the cost value approach. The results, which
are red-marked, can be seen in Appendix I and as shown, it turned out to be five functional requirements
and five quality requirements. These requirements were then prioritized according to the cost value
approach and the results can be viewed under Appendix II.
The remaining requirements were prioritized according to the Five-Way Priority Scheme as shown in
Appendix III. This method was chosen since it gives the different stakeholders the same importance and
has an enough wide range for determining which requirement is more important than the other [3].
However, in this prioritization process, the development team was not included as a stakeholder since the
different features were not considered to be as important to them as for the other stakeholders.
Other methods for prioritization, such as the hundred-dollar test and the yes-no vote, were also
considered. The hundred-dollar test is quite similar to the five-way priority scheme, since it also gives a
wide range for ranking the requirements. However, it is more easily misused since someone could save all
their money and put them on a requirement that they think is very important [3]. Others might not agree
that this requirement is important but it might still get the most votes since one person cared about it [3].
The yes-no vote method might be fairly simple to carry out, however the range is too narrow. For
instance, if two requirements are not very important it would be hard to determine which of those
requirements that is more important than the other [3].
In conclusion, weighing the disadvantages and advantages of these methods against each other lead us to
choose the five-way priority scheme.
4.2 Release Plan

The requirements were divided into three releases based on the prioritization and their dependencies. The
three different releases were assembled so that each would work as a fully functional application.
In the first release the requirements that build up the foundation of the application were included, together
with the most highly prioritized requirements and their dependencies.
27
The second release also includes important requirements. However, these requirements are not vital for a
functional application. They are more suited to act as additional features that can contribute to making the
software product more attractive.
The third release includes the requirements that can be afforded to discard if the project gets delayed or
overruns the budget.
For further details about the release plan, see Appendix IV.
28
Appendix I: Selection for Cost-Value Approach

Table 2 Select of ten most important requirements
Requirement ID Magnus Elmira Faegheh Niclas Farhan Sean Sarah Total

FR1
47
FR2
28
FR3
44
FR4
39
FR5
41
FR6
10
10
10
10
66
FR7
10
10
10
10
64
FR8
10
10
10
10
64
FR9
51
FR10
39
FR11
31
FR12
40
FR13
47
FR14
34
FR15
41
FR16
39
FR17
28
FR18
36
FR19
35
FR20
40
FR21
34
FR22
47
29
FR23
43
FR24
10
10
10
58
FR25
28
FR26
45
FR27
55
FR28
41
FR29
40
FR30
29
FR31
10
50
FR32
47
FR33
27
QR1
49
QR2
44
QR3
43
QR4
45
QR5
35
QR6
10
56
QR7
57
QR8
49
QR9
10
57
QR10
27
QR11
28
QR12
55
QR13
40
QR14
47
30
QR15
46
QR16
53
QR17
38
QR18
42
QR19
49
QR20
45
QR21
45
QR22
54
QR23
49
31
Appendix II: Prioritization Result of 10 selected Requirements Using

Cost-Value Approach
Table 3 10 most important requirements
Requirement ID Title
Requirement Type
FR6
Mobile application - Search
Function
FR7
Mobile application - Search result in a map view Function
FR8
Mobile application - Search result in a list view
Function
FR24
Restaurant owner manages information
Function
FR27
Administrator verifies restaurant owner
Function
QR6
System response time
Quality
QR7
System Availability
Quality
QR9
System Reliability
Quality
QR12
Communication Security
Quality
QR22
Internet Connection
Quality
Table 4 Value
Value FR6 FR7 FR8 FR24 FR27 QR6 QR7 QR9 QR12 QR22
FR6
1/3
1/5
1/3
1/3
FR7
1/5
1/5
1/3
1/3
1/3
FR8
1/7
1/3
1/6
1/4
1/4
1/5
FR24
1/7
1/5
1/4
1/3
1/5
1/5
1/3
FR27
1/6
1/5
1/9
1/5
1/5
1/7
QR6
32
QR7
1/3
1/3
QR9
1/3
1/3
1/3
QR12 1/5
1/5
1/2
QR22 1/7
1/5
1/3
1/4
1/2
1/8
1/7
1/5
1/9
Table 5 Cost
COST FR6 FR7 FR8 FR24 FR27 QR6 QR7 QR9 QR12 QR22
FR6
1/5
1/2
1/7
1/3
1/5
1/3
FR7
1/5
1/5
1/3
1/5
FR8
1/9
1/5
1/6
1/5
FR24
1/3
1/7
1/3
1/3
1/5
FR27
1/5
1/3
1/5
1/3
1/7
1/6
1/7
1/6
QR6
QR7
1/2
1/3
QR9
1/2
1/2
QR12
1/3
1/5
1/3
1/3
1/3
QR22
1/7
1/5
1/2
1/9
1/7
1/5
1/5
33
Figure 9 Result of AHP method
Figure 10 The value distribution and estimated cost
34
Table 6 - The value distribution and estimated cost
FR6
Cost
Value
5,31%
13,60%
FR7
9,18%
7,12%
FR8
FR24
7,91%
4,80%
7,65%
5,93%
FR27
QR6
QR7
QR9
QR12
1,73% 22,55% 13,92% 15,43% 12,60%

4,45% 23,41% 13,78% 10,31% 15,06%
35
QR22
3,71%
1,53%
Appendix III: Five-Way Priority Scheme

Table 7 Data of five-way priority scheme prioritization
Requirement
ID
Priority by Stakeholder
User
FR1
1
1
1
1
1
1
Restaurant owner
-2
-1
-2
-2
-1
-1,6
1
1
0
-1
0
0,2
Restaurant owner
-2
-1
-2
-2
-2
-1,8
1
0
1
0
1
0,6
Restaurant owner
-2
-2
-2
-2
-2
-2
0
0
1
0
0
0,2
Restaurant owner
-2
-2
-2
-2
-2
-2
1
1
0
Restaurant owner
-2
-2
-2
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Administrator
-2
-2
-2
-2
-1
-1,8
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
Customer
1
1
1
0
0
0,6
-3
1
1
0
1
1
0,8
-2,4
0
0
0
-1
0
-0,2
-4
41
User
FR5
Customer
29
User
FR4
Administrator
-2
-2
-2
-2
-2
-2
2
2
1
1
1
1,4
-1
34
User
FR3
Customer
13
User
FR2
Administrator
-2
-2
-2
-2
-1
-1,8
Magnus
Elmira
Niclas
36
0
0
-1
Faegheh
Sarah
Average
Sum
-1
0
0,2
-2
-2
-2
1
1
1
1
1
1
Restaurant owner
1
0
0
-2
0
-0,2
1
1
1
1
0
0,8
Restaurant owner
-2
0
-2
-2
-2
-1,6
1
1
0
0
0
0,4
Restaurant owner
1
1
1
1
1
1
1
1
2
2
2
1,6
Restaurant owner
-1
0
-2
-2
-1
-1,2
1
1
Restaurant owner
-1
0
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
Customer
1
0
-2
-1
0
-0,4
-3,2
1
1
-2
1
1
0,4
-0,2
0
0
-2
0
1
-0,2
-1,8
18
User
FR13
Administrator
-2
-2
-2
-2
-2
-2
1
2
-1
1
0
0,6
-0,6
5
User
FR12
Customer
36
User
FR11
Administrator
-2
-2
-2
-2
-2
-2
8
User
FR10
-1
-1
-0,6
-4,4
42
User
FR9
-2
-2
-2
Magnus
Elmira
37
0
0
Niclas
Faegheh
Sarah
Average
Sum
2
2
2
1,6
-2
-2
-1
-1,2
1
0
1
0
0
0,4
Restaurant owner
-1
-2
-2
-2
-2
-1,8
1
1
1
1
1
1
Restaurant owner
-1
0
-2
-2
-1
-1,2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
1
1
1
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
0
1
0,8
Rank of
Req.
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
Customer
1
0
-2
0
1
0
-2,2
Restaurant owner
-1
0
-2
-2
-2
-1,4
1
0
-2
-1
1
-0,2
-2,6
Restaurant owner
-1
0
-2
-2
-1
-1,2
1
-1
-2
-1
0
-0,6
-3
35
User
FR18
Administrator
-2
-2
-2
-2
-2
-2
1
-1
1
0
0
0,2
-3,2
31
User
FR17
Customer
24
User
FR16
Administrator
-2
-2
-2
-2
-2
-2
37
User
FR15
-2
1
1
0
-1,6
17
User
FR14
-2
-2
-2
-2
Magnus
38
Restaurant owner
-2
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
2
1
1
1,4
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
1
1
1
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
2
1
1
1
1,2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
0
1
0
-1
0
0
Rank of
Req.
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
Customer
1
0
-2
-1
0
-0,4
-3,4
Restaurant owner
-2
-1
-2
-2
-2
-1,8
1
1
-2
0
0
0
-2,6
Restaurant owner
-2
-2
-2
-2
-2
-2
0
0
-1
-1
0
-0,4
-4,4
43
User
FR22
Restaurant owner
-2
-2
-2
-2
-2
-2
32
User
FR21
1
0
-1
0
0,2
-2,2
38
User
FR20
-2
-2
-2
-2
-2
25
User
FR19
-1
-2
-2
-2
-1,8
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-2
-2
Rank of
Req.
Restaurant owner
2
2
2
2
2
2
2
2
1
2
1
1,6
-0,4
6
User
Restaurant owner
39
FR23
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-2
-2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-1
-1,8
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-2
-2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-1
-2
-1
-1,6
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
2
1
2
2
2
1,8
Customer
Administrator
1
0
2
2
1
1,2
Customer
Administrator
1
0
2
2
1
1,2
Customer
1
0
-2
-1
0
-0,4
-3,4
Restaurant owner
-2
-2
-2
-2
-2
-2
1
0
1
1
1
0,8
-1,4
Restaurant owner
0
1
1
-1
0
0,2
1
1
0
1
1
0,8
0,6
2
User
FR29
Restaurant owner
1
1
1
0
1
0,8
16
User
FR28
2
1
1
1
1
1,2
-1
39
User
FR26
-2
-2
-2
-2
-2
-2
14
User
FR25
1
2
2
2
2
1,8
-2
-2
-1
-2
-1
-1,6
Rank of
Req.
Restaurant owner
0
1
1
-1
0
0,2
3
40
1
1
0
1
1
0,8
0,6
User
FR30
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-1
-2
-2
-1
-1,6
Restaurant owner
0
0
0
1
1
0,4
0
0
0
0
0
0
Restaurant owner
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
Restaurant owner
0
0
0
1
0
0,2
-2
-2
-2
-2
-2
-2
Restaurant owner
-2
-2
-2
-2
-2
-2
2
2
2
2
2
2
Restaurant owner
-2
-2
-2
-2
-2
-2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
Administrator
1
0
2
1
1
1
Customer
Administrator
0
0
0
0
0
0
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
1
1
0
0
1
0,6
-0,4
1
1
0
1
1
0,8
0
0
0
-2
-1
0
-0,6
-4,6
44
User
QR1
Customer
4
User
FR33
Administrator
1
0
2
1
1
1
1
1
0
1
1
0,8
1,2
7
User
FR32
Customer
1
User
FR31
Administrator
1
1
2
2
2
1,6
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
10
41
2
2
0
1
1
1,2
-0,8
Req.
User
QR2
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
2
2
2
2
2
2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
0
1
0,8
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
1
1
1
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
1
0
0,8
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Restaurant owner
-2
-1
-1
-1
-1
-1,2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-1
-1,8
Customer
1
1
0
-1
1
0,4
-2
Restaurant owner
-2
-1
-1
-1
-1
-1,2
1
1
0
0
0
0,4
-1,8
Restaurant owner
-1
-1
0
1
-1
-0,4
1
1
-2
-1
0
-0,2
-1,8
20
User
QR8
Administrator
-2
-2
-2
-2
-2
-2
2
2
0
1
1
1,2
-0,8
19
User
QR5
Customer
21
User
QR4
Administrator
-2
-2
-2
-2
-2
-2
11
User
QR3
Restaurant owner
-2
-2
-2
-2
-2
-2
1
1
1
1
0
0,8
42
Restaurant owner
-2
-2
-2
-2
-1
-1,8
1
0
2
0
0
0,6
-2,2
Rank of
Req.
26
User
QR10
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-1
-1
-1
-1
-1
-1
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-1
0
-1
-1
-1
-0,8
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-1
-2
-2
-2
-2
-1,8
Customer
Administrator
2
1
2
2
1
1,6
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
-1
0
-1
-1
0
-0,6
-5,6
-1
0
-1
-1
-1
-0,8
-5,6
-2
-2
-2
-2
-2
-2
Restaurant owner
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
Restaurant owner
0
0
1
0
1
0,4
2
1
2
1
1,5
-0,7
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
Rank of
Req.
2
1
2
2
1
1,6
-0,8
12
User
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
-2
-2
-2
-2
-2
-2
-2
User
QR15
Restaurant owner
-2
-2
-2
-2
Restaurant owner
2
1
2
2
1
1,6
Rank of
Req.
QR14
Customer
46
User
QR13
Administrator
-2
-2
-2
-2
-2
-2
45
User
QR11
Restaurant owner
-2
-2
-2
-2
-2
-2
43
-1
2
2
2
1
1,2
Sum
-2,4
Rank of
Req.
30
User
QR16
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-2
-2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
2
1
1
0
0
0,8
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-2
-2
-2
-2
-2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-1
-2
-2
-1
-1,6
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Restaurant owner
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
Administrator
-2
-2
-2
-2
-2
Customer
0
2
2
1
1
1,2
-2
Restaurant owner
2
1
1
0
0
0,8
0
2
2
1
1
1,2
-2
Restaurant owner
-2
-1
-2
-2
-1
-1,6
2
2
1
2
1
1,6
-3,6
40
User
QR20
Administrator
-2
-2
-2
-2
-2
-2
-1
2
2
0
0
0,6
-2,8
23
User
QR19
Customer
22
User
QR18
Administrator
0
0
1
1
0
0,4
33
User
QR17
Restaurant owner
-2
-1
-2
-2
-2
-1,8
0
0
1
1
-1
44
Restaurant owner
-2
-2
-2
-2
-1
2
2
1
1
1
Average
Sum
0,2
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
-2
-1
-2
1
-1
-1
Rank of
Req.
Magnus
Elmira
Niclas
Faegheh
Sarah
Average
Sum
1
1
1
1
1
1
Rank of
Req.
Requirement ID
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
FR30
FR28
FR29
FR32
FR11
FR22
FR31
FR9
QR13
QR1
QR2
QR14
FR1
FR23
QR23
FR26
FR13
FR12
QR4
QR5
Restaurant owner
-2
-1
-2
-2
-1
-1,6
Restaurant owner
-2
0
-2
-2
-1
-1,4
15
Table 8 Result of five-way priority scheme prioritization
Priority
1,4
-2,2
Administrator
-2
-1
-2
-2
-1
-1,6
Customer
Administrator
-2
-2
-2
-2
-2
-2
Customer
2
2
2
2
2
2
-2,2
28
User
QR23
-2
27
User
QR21
-1,8
45
1
2
1
1
1
1,2
-1,2
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
QR3
QR17
QR18
FR15
FR18
QR8
QR20
QR21
FR3
QR15
FR16
FR20
QR16
FR2
FR17
FR10
FR14
FR19
FR25
QR19
FR4
FR5
FR21
FR33
QR10
QR11
46
Appendix IV: Release Plan

Table 9 Release plan
RE:
FR1
FR2
FR3
FR4
FR5
FR6
FR7
FR8
Dependencies
Description
Motivation
Download
mobile
application
FR1
FR1, FR3
FR1
FR4
FR6, QR22,
QR23
FR6, QR22
Release
Duration
This requirement makes the

application available for users and is
therefore an important requirement to
include in the first release.
80
Download and
notify users of
new releases
The download of the new versions is

important for users to be able to
receive the future release of the
application and will therefore be
included in the first release.
User
registration
For the user to be able to use the

application, the user has to registrant.
Consequently, this requirement needs
to be met in the first release.
User Log-in
For the user to be able to use the

application, the user has to log in.
Consequently, this requirement needs
to be met in the first release.
For the user to be able to receive a

forgotten password will have to wait
to the second release. This is not vital
for the application and was therefore
not included in the first release.
The search feature is one of the most

important and vital part of the
system. It's part of the basic goal of
the program and should therefore be
The ability to show the search result

in a map view is part of the basic
goal of the program and should
therefore be included in the first
release.
The ability to show the search result

in a list view is part of the basic goal
Retrieve
Password
Search
Search result in
a map view
Search result in
a list view
47
of the program. We have decided to

put this one in the second release and
only include the map result view in
the first release.
FR9
FR10
FR11
FR12
FR7, FR8
FR7, FR8
FR7, FR8
FR8
FR13
FR7
FR14
FR12, FR13
FR15
FR16
FR17
FR7
FR7
FR6
Navigation to
restaurant
To make the first release interesting

and useful for the users, this is
Switch result
view
The switch between the result views

will be implemented after the result
list is implemented. This is not in
some way vital for the application
and can be discarded if the project
gets delayed or overruns the budget.
Selecting the
information
link
This will be added as an additional

feature in the second release to make
the application more attractive for the
users.
Search by price

feature in the third release to make
users.
Search by
destination
This is the search function that will

be included in the first release.
Accepted input
for price and
destination
search
This is a requirement that will make

the application more stable. It will be
added in the third release.
Search by
restaurant type

feature to the second release to make
users.
Search by
specific dish

users.
Free-text
search

feature to the first release to make the
application more attractive for the
48
users.
FR18
FR5
FR19
FR8
FR20
FR7, FR8
FR21
FR1
FR22
FR23
FR27
FR24
FR25
FR23, FR25
No search
match found
This is a requirement that will make

the application more stable and make
the user experience better. It is not
vital and will be added in the third
release.

users.
Filtering
results

users.
Profile page

users.
Create account
- restaurant
owner
The restaurant owner is a vital part of

the system and must be included in
the first release.
Log-in restaurant
owner
This should be included in the first

release because the restaurant owner
needs to be able to log in so hi/she
can manage the restaurant
information.
Manage info restaurant

owner
The ability for the restaurant owner

to manage the information about the
restaurant is very important, if there
is no information there is nothing to
search for.
Selecting
preferred
language on
the web-portal
- restaurant
owner

users. It is not vital for the
implemented in the third release.
Sorting results
49
FR26
FR27
FR28
FR29
FR30
FR26, FR22
FR26
FR26
FR26
Log-in - admin
This should be included in the first

release because the administrator
needs to be able to log in so she/hi
can manage the system.
Verify
restaurant
owner
It's important for the admin to be able

to verify the restaurant owners
application for registration.
Manage rest.
types administrator
The type search will be added in the

second release.
Manage rest.
dished administrator
The dish search will be added in the

second release.
Manage rest.
info administrator
The info link will be added in the

second release.
FR31
FR26
Manage users administrator
The administrator needs to be able to

handle users during the first release.
FR32
FR26
Selecting
preferred
language on
the web-portal
- administrator
The administrator needs to be able to

handle restaurant owners during the
first release.
Language
selection on
portal

users. It is not vital for the
implemented in the third release.
Prominent
search feature
This is a very high-prioritized

requirement. Consequently, this will
The ease of
usage of the
search feature
This is a very high-prioritized

requirement. Consequently, this will
FR33
QR1
QR2
FR26
50
QR3
QR4
QR5
QR6
QR7
QR8
QR9
QR10
QR11
The ease of
usage of the
result in the list
view
This is a high-prioritized
requirement. But we have decided to
put this in the second release in favor
for more vital and higher prioritized
requirements.
The ease of
usage of the
result in map
view
This is a high-prioritized
requirement. But we have decided to
put this in the second release in favor
for more vital and higher prioritized
requirements.
The ease of
usage of the
information
link
This will be considered when all the

mandatory requirements for the
system have been implemented.
System
response time
This will be considered and

continuously improved during the
whole process. We can only
discharge the requirement when all
functions are implemented.
System
availability

whole process.
QR22, QR23,
FR14, FR15,
FR16, FR17
System
dependability

System
reliability

whole process.
Application
hard drive
space usage

Application
memory usage

51

QR12
QR13
QR14
QR15
QR16
QR17
QR18
QR19
QR20
QR21
FR22
FR23
FR3
FR22
Communicatio
n security
As the system grows, and with

respect for the users this need to be
included.
Non-existing
account
security for
rest. Owners
This need to be included in the first

release to enhance the safety of the
system.
Non-existing
account
security for the
administrators
This needs to be included in the first

release to enhance the safety of the
system.
Log in security
for rest.
Owners

release to prevent illegitimate
attempts to use the restaurants
owners account.
Log in security
for
administrators
This need to be included in the first

release to prevent illegitimate
attempts to use the administrator
account.
User account
creation
security

release to resolve conflict between
users with the same name.
Restaurant
owner account
creation
security

release to resolve conflict between
restaurant owners with the same
name.
Application
extendibility

continuously improved during
development.
Application
portability

whole process.
50
Application
testability
The test environment for the system

will continuously be built as the
30
52
system expands.
QR22
QR23
Internet
connection
Internet connection is mandatory for

the application to work and is
therefore included in the first release.
GPS
connection
GPS connection is mandatory for the

application to be able to show the
result and is therefore included in the
first release.
53
Figure 11 Release plan schedule
54
Appendix V: I-star
Figure 12 SD diagram
55
Figure 13 SR diagram
56

Srs Example 2010 Group2 PDF

Uploaded by

Document Information

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

Srs Example 2010 Group2 PDF

Uploaded by

Copyright:

Available Formats

Software Requirements

Sarah Geagea 881024-4940

1.3 Definitions, acronyms, and abbreviations

Someone who interacts with the mobile phone application

A web application which present special facilities for restaurant owner

Global Positioning System

An installed software on mobile phone which could provide GPS

An installed application on mobile phone which helps user to find new

A unique, persistent identifier contained in a PLanguage statement [2]

A short, simple description of the concept contained in a PLanguage

The scale of measure used by the requirement contained in a PLanguage

The process or device used to establish location on a SCALE contained

The minimum level required to avoid failure contained in a PLanguage

The level at which good success can be claimed contained in a PLanguage

A desirable level of achievement that may not be attainable through available

The official definition of a term contained in a PLanguage statement [2]

2.1 Product perspective

Figure 1 - Block diagram

The mobile application has some restrictions about the

2.2 Product functions

2.3 User characteristics

2.5 Assumptions and dependencies

2.6 Apportioning of requirements

3.1 External interface Requirements

Figure 2 - Login page

Figure 3 Search page

Figure 4 Profile page

Figure 5 List view

Figure 6 Map view

Figure 7 Filter menu

Figure 8 Web Portal

3.1.2 Hardware interfaces

3.2 Functional requirements

3.2.1.4 Functional requirement 1.4

RAT: The way results are displayed in a map.

3.2.1.8 Functional requirement 1.8

RAT: The way results should be displayed in a list.

RAT: In order for a user to switch between result views.

increasing or decreasing the maximum distance

When the restaurant owner registers on the web-portal by providing user-name

3.2.2.3 Functional requirement 2.3

Scenario: Show fields for managing information

And filled in one or more optional fields of the form

3.2.3 User Class 3 - Administrator

Scenario: Editing an existing restaurant type

And information about a restaurant exists

When the administrator deletes an existing restaurant owner

3.3 Performance requirements

3.3.2 Usage of the search feature

3.3.7 System dependability

3.4 Design constraints

3.5 Software system attributes

GIST: The reliability of the system.

4. Prioritization and Release Plan

4.1 Choice of prioritization method

4.2 Release Plan

Appendix I: Selection for Cost-Value Approach

Requirement ID Magnus Elmira Faegheh Niclas Farhan Sean Sarah Total

Appendix II: Prioritization Result of 10 selected Requirements Using

Mobile application - Search

Mobile application - Search result in a map view Function

Mobile application - Search result in a list view

Restaurant owner manages information