Software Requirements

Specification
Online Market System

K.A.Hari Hara Sankar

P.Raja Athiban
P.K.Vasanth Ramm
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

i
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 management of shopping, internet, payment, bills, and customer details is
the primary goal of the online shopping system. It controls all the data regarding
customers, products, and shopping. Since the project is entirely constructed at
the administrative end, access is solely guaranteed for the administrator.
1.2 Scope
The Online Market System(OSM) is the buying and selling, marketing, servicing,
delivery, and payment of goods, services, and information between an
interconnected firm and its prospects, customers, suppliers, and other business
partners over the internet, intranets, extranets, and other networks.

Sellers have access to a diverse choice of goods. In order to provide specialised offers,
discounts, and services, they can analyse customer purchasing trends and
preferences. Scaling a business is simple. Small traders and producers gain
legitimacy by selling on internet retail platforms like Amazon, Flipkart, etc.

E-commerce development has a tonne of promise. Today, one may purchase

goods online from stores like Flipkart and Amazon. E-range commerce's of
activities includes the interchange of digital information, technology-enabled
customer retention, accounting, supplier integration, and exchange support.
1.3 Definitions, acronyms, and abbreviations

Table 1 - Definitions

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

1
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.

Cart Adding items to the cart, update the quantity of the items and removes the
items from the cart
Registration Deals with the customer’s registration

Orders Deals with the product ordered by the customer

HTTP Hypertext Transfer Protocol

Firebase Online database for storing data

SRS Software Requirement Specification

Login Each Customers will have individual login

Search Customers can search items for their needs

Track Order Customers can track order which is placed by them

Payment Customers can choose online payment for the goods they have purchased

Profile Each customers will have individual profile

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] https://github.com/mitravinda462/SRS-Document-for-Online-Shopping-Website
[3] https://www.slideshare.net/AhsanRizwan2/srs-for-online-store
[4] https://www.geeksforgeeks.org/software-requirement-specification-srs-format/

3
1.5 Overview

This system requires upkeep of its own database. In order to provide server-side capabilities,
information or specifics about the items are saved in databases (such RDBMS, commercial online
databases like Firebase, etc.). The customer's information and the items that are dispatched to various
areas based on the addresses provided by the customers are handled by the server procedure.

One of the two modules in the application design is for clients who want to purchase items. Another is
for store owners who keep the information on the products and the clients up to date. The common
people for whom the program is to be hosted on the web and the administrator are the product's end
users.

The information about the items is highlighted and forwarded from the database for the customer (front
view) based on the choice from the menu list, and based on all these searches and transactions the
database of all the products is updated at the end of each transaction. The application is deployed on the
customer's database like RDBMS.

Products can be entered into the program through a variety of screens created for users of varying
experience levels. Several reports are generated dependent on the security policy being utilised as soon
as the authorised employee enters the pertinent data into the system.

4
 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 product is intended for someone who doesn't have time or who may not be
interested in visiting the store and dealing with a lot of formality.
The product will be a dynamic, entirely independent website. Employees must
register in order to purchase things online. The only person with the authority to
add or remove things from a certain category of objects is the admin. The Pay Pal
website facilitates debit card and credit card purchases.
The perspective includes online way of communication, business process,
services, collaboration and community

Figure 1 - Block diagram

2.2 Product functions

To use the majority of the capabilities of the programme, the customer must first register with the Online Market

5
System. The customer must provide information such as their email address, password, etc. Online shopping
applications promote some of the products for purchase after registration.

Here, the customer will be able to buy the items, and they will be added to the shopping cart.

After the confirmation of the product transaction, the customer will receive a bill.
Customers enter their debit card information to make transactions. the verification will done successfully when the
customers enters the correct details
The PayPal Application will manage the handling of debit card numbers.

Following product purchases, the PayPal Application will confirm the transaction.

The admin will update the bills to pay on the Application. The administrator can add, amend, and remove products
from a variety of product categories. Admin can also view and modify the information on bills.

6
 2.3 User characteristics
The person using this product should be fairly knowledgeable about how this
application work. He needs to be able to open online pages and comprehend all of the
functions of the website. It will be challenging for someone without computer
experience to comprehend the system. However, handling the project will be extremely
simple if you have any experience.
2.4 Constraints
Security is not a problem for this system, as the buyer claimed. There is no
requirement for a password recovery function or lockout after a certain number
of unsuccessful login attempts; the database may keep passwords in plain text. As
a result, when security is an issue, the system might not operate as intended. In
addition to the situations mentioned above, these situations also involve making
customers use "strong" passwords and not using an encrypted connection while
sending credit card information. A strong password is one that satisfies a variety
of requirements that are established to prevent users' passwords from being
readily guessed by attackers. These guidelines often include making sure the
password has a suitable number of characters.
2.5 Assumptions and dependencies
The Assumptions include:

1) The coding must be flawless.

2) The system must be simple to use for people to find it straightforward to utilize.

3) The system should be more capable and offer quick database access.

4) The system should facilitate speedy transactions and offer search functionality.

5) The online marketplace system is active 24 hours a day.

Users can access the website from any computer that has an internet connection and internet surfing
skills.

7) In order to access their online accounts and perform operations, users must have their correct
usernames and passwords.

The presumptions include:

7
1) The specific hardware and software required for the product to function are the dependencies.
2) The project will be developed and carried out in accordance with the requirements and specifications listed.

3)The product should be properly understood by the end users (admin).

4) A general report store should be included in the system.

5) The online marketplace system must have access to a database where all user information is kept.

2.6 Apportioning of requirements

According to the client, security is not an issue for this project. Therefore, it is outside the purview of this system to
encrypt personal user data, credit card data, block illegal login attempts, or address any other issue of this kind.

8
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 new user using the application can experience a welcome screen with the options to login or register
for a new user.
The registration screen will provide interfaces for the user to enter details regarding himself and to
create a new password for the user. There is also a button interface to register and authenticate using
Google's authentication mechanism.

If the user is already registered through the application, he can login from the login page using google or
the information specified by the user. On logging in, the user can see a dashboard screen, where user-
specific recommendation items are displayed and there are icons and options to navigate to different
screens of the application.

Each user has a profile page where they can edit their details and also can see past orders and method of
payment registered with the user.

The dashboard screen provides a multi-collage list view of different items available for sale and may be
of interest to the user. There is also search screen to display the search results in list view with prices
and other details. There is separate pop-up interface for sorting the results based on price, date, likes,
ratings, rate of buying etc... and filtering the result based on brand, features etc...

On clicking an item, the item description page pops up and shows the items in visual approaches with
the details of the item and a button to add the item to cart for purchase.

All the items that are favored by the user can be added to the cart and will be displayed in grid-shaped
box view in the checkout page along with the price of each item and total price for the purchase along
with tax implementations. The payment page features a visual image of the payment options specified by
the user, if the user is making first payment, then the user payment option is prompted and added to the
display. An interactive interface is designed for payment and confirmation of payment.

9
The seller interface has features to sell items that abide the rules of the organization. The page consists of an option
to upload an image and give descriptions, price and links about the product that is going to be sold to the customers.
The administrators of the application can be reached through the support page, which features an
interactive UI to create tokens which will be resolved by the customer care team. The administrators will also have
a verify page where the products that are going to be sold will be verified.
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

10
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. 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

There is a need for communication among the different parts of the system since each one is dependent
on the others. It is not important for the system how communication is achieved, and therefore, both
mobile applications and web portals are handled by the underlying operating systems.

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: An application store or similar service on a mobile phone should allow users to download the
mobile application. Free downloads should be available for the application.
RAT: To free download of the application.
DEP: None

3.2.1.2 Functional requirement 1.2

ID: FR2
TITLE: Download and notify users of new releases
DESC: Users should be able check for new/updated versions/releases of software manually when they
are released. Similar to downloading the mobile application, you will need to download the new release
through your mobile phone.
RAT: To download the latest/updated release, a user must
follow the instructions below
DEP: FR1

3.2.1.3 Functional requirement 1.3

ID: FR3
TITLE: User registration - Mobile application
DESC: Users can register through the mobile application once they have downloaded the mobile
application. In order to use the service, the user must provide a username, password, and e-mail address
and a password. There is also a feature to register using the users google account.
RAT: In order for a user to register on the mobile application.
DEP: FR1

11
3.2.1.4 Functional requirement 1.4

ID: FR4
TITLE: User log-in - Mobile application
DESC: Once a user registers, he or she should be able to log into the mobile application. Login session
will be recorded in the mobile device and the user will be able to automatically authenticated on using
the application in the future. The login is also made possible with the google account associated with the
user during registration.
RAT: In order for a user to register on the mobile application.
DEP: FR1, FR3

3.2.1.5 Functional requirement 1.5

ID: FR6
TITLE: Verification
DESC: As the user is registered and is login into his account, the user should verify his email and mobile number
to receive updates, order and payment details over different kinds of services such as mail, watsapp and messages.
DEP: FR1

3.2.1.6 Functional requirement 1.6

ID: FR6
TITLE: Password and information retrieval
DESC: The user should be able to retrieve his password and other information using a verified email
or phone number in case if the user forgot his password or need a report of the information processed
by the user.
RAT: In order for a user to retrieve his/her password and information.
DEP: FR1

3.2.1.7 Functional requirement 1.7

ID: FR7
TITLE: Dashboard
DESC: After the user is logged in to the mobile application, the landing page that is a dashboard page that shows
different products that may be of interest to the user. This page has the icons and links to all the other pages and
options available through the application.
RAT: In order for a user to navigate.
DEP: FR7

3.2.1.8 Functional requirement 1.8

ID: FR8
TITLE: Search and Search result:

 The search options can be used to search different kinds of products available in the application.
The sort option is present as an icon in the top right of the page and the filter option includes many
options and is designed with popup-based UI.

 The search options provide sorting option based on different options and filters based on:
12
 i. price

ii. Type

iii. Brand

iv. Rating

v. Specification

 The top 50 results are displayed in a scroll view and the next results can be fetched using the
fetch more option.
RAT: The search feature and display of search results.
DEP: FR8

13
3.2.1.9 Functional requirement 1.9

ID: FR9
TITLE: Item description and features
DESC:

 The results from search functions and items in the dashboard page are designed with a card shaped user
interface which shows a small description with the price and rating of the product.

 Each item card acts as a link to a page with shows the product in a visually attractive perspective.

 Multiple features must be specified in the page. These features include:

i. Detailed Description

ii. Price and offers

iii. Specifications

iv. Ratings

v. Reviews

vi. Similar Products

 There is button which performs the function of adding the product to the cart to finally purchase the
product.

RAT: The features in the item page

DEP: FR6

3.2.1.10 Functional requirement 1.10

ID: FR10
TITLE: Mobile application – Payment Features
DESC:
 The payment can be made on clicking proceed to payment from the checkout screen. The items
in the cart can bought together in the payment page.
 Different kind of methods is available for payment. There are payment using credit, debit card
and net banking. Specific API are used for banking.
 A visual representation of the payment method is displayed on the payment screen after the user
has made the first payment and different payment methods can be stored in this section.
 The payment is atomic and is secure.
DEP: FR5

3.2.1.11 Functional requirement 1.11

ID: FR11
TITLE: Billing
DESC: On payment a bill is generated with all the calculations of tax and is sent to the user through mail and a
14
confirmation is given through message through the mobile. The order is also reflected in the order section in the
profile of the user.

15
RAT: In order for a verify payment.
DEP: FR10

3.2.1.12 Functional requirement 1.12

ID: FR12
TITLE: Mobile application – Profile
DESC:
 The profile has information about the user that is recorded during the registration and also has a
unique id associated with the profile.
 The user can modify the password, email and other details associated with the profile.
 The section also has features to track the order and see the past orders made by the user using the
account.
DEP: FR4

3.2.1.13 Functional requirement 1.13

ID: FR13
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

3.2.1.14 Functional requirement 1.14

ID: FR14
TITLE: Mobile application - Search by Sellers
DESC: A user is able to search all the products that are being sold by a company or a seller. The user
should be also able to view similar products whenever the user is viewing the item of a particular seller.
The result is displayed in column wise collaged format.
RAT: In order for a user to search by selllers
DEP: FR7

3.2.1.15 Functional requirement 1.15

ID: FR15
TITLE: Input validation
DESC: Different validation features are incorporated within the application such as:
 String validation for search based on names and tags associated with the product.
 Email and phone number validation is done during registration and in the profile section.
 If custom price is used to filter the results of the search, then integer validation is performed for the
price specified.
RAT: In order to valid input and avoid errors.
DEP: FR12, FR13

16
3.2.1.16 Functional requirement 1.16

ID: FR16
TITLE: Mobile application - Search by type of the product

17
DESC: A user should be able to search based on the category of products such as fruits, vegetables etc...
The result is displayed in a map view by default.
RAT: In order for a user to search by type of
product.
DEP: FR7

3.2.1.17 Functional requirement 1.17

ID: FR17
TITLE: Mobile application - Review
DESC: The user should be able to give review on a specific product and should also be able to rate the
product which will be included with the rating of all other users to calculate the overall rating of the
product. The review by the user should be reflected to all users in the review section of that product page .
RAT: In order for a user to review and rate the product.
DEP: FR7

3.2.1.18 Functional requirement 1.18

ID: FR17
TITLE: Mobile application – tag-based search
DESC: Different tags are provided to the user from which the user can choose a tag which provide
results related to the tag. The feature will be similar to search feature and the result is displayed in a tile
view with scroll effect..
RAT: In order for a user to perform tag-based search
DEP: FR7

3.2.1.19 Functional requirement 1.19

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

3.2.1.20 Functional requirement 1.20

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 user’s position.

18
 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

3.2.1.21 Functional requirement 1.21

ID: FR20
TITLE: Mobile application – Customer tokens
DESC: When the user is facing any difficulty with buying, payment or any other features of the
application, the user can create a token about the issue which will be views and handled by the customer
care unit of the organization. The features in this option have tags which can be choose by the user to depict
the type of issue they are facing with.
RAT: In order for a user to report issues by creating tokens.
DEP: FR7, FR8

User Class 2 - Seller

3.2.1.22 Functional requirement 2.1

ID: FR21
Feature: Create an account
The seller can register for a
seller account on the
registration page.

Scenario: Required information for registration

The user has to enter information such as user name,
password, email, phone number and other details. The
seller must choose the user type as seller to continue
with a seller account. The model of the systems is
that seller is also a buyer so the seller will have a
added features included with the buyer features.

19
 Scenario: registration verification
As the seller is registered, the seller must verify his phone and email address. The seller must also provide a
valid identification proof and bank details to verify himself as a seller.

3.2.1.23 Functional requirement 2.2

ID: FR22
Feature: Restaurant owner log-in
Theusercanloginusingusernameand
passwordorgoogleauthentication.
Scenario: Successful log-in
The interface will be very similar to the buyers interface with a added feature of selling products.

Scenario: Retrieve password

In case when the seller has forgot the
password, the verified email can be used
to retrieve the password with a email
containing the password.

20
3.2.1.24 Functional requirement 2.3

ID: FR24
Feature: Sell Products
In order to sell products, the
user can go to the sell products
section.
Scenario: Filling in mandatory fields
The mandatory fields of the sell product section are:
 Product Description
 Specifications
 Price
 Product name
The information associated with the seller is also associated with the
product.

Scenario: Adding Payment Details

The seller must include the payment information to which the money from the buyer should be transfers. For
selling of consecutive items, the payment details entered in the previous items are automatically included. It is
mandatory to provide net banking feature and UPI of the account to which the money must be transferred.

Scenario: Viewing Items on sale

The seller can view all the items that are currently put on sale and all the
items sold be the seller in the past and amount of money the seller has
earned by selling a specific item and the total money earned by the user.
Scenario: Submitting item for verification
After specifying all the information about the product, the product is not directly put to sale.

21
 The product has to go through a phase of verification by the admins of the application before getting to the
customer.
Then policies of trade and selling are signed during this phase.

Scenario: Deleting Product

If the seller doesn’t want the product to
be sold to the consumer, the seller can
delete the product for sales. The
product is still reflected in past sold
products

Scenario: Editing information

Any information regarding the product
can be edited after the product has
been put to sales by the seller.
Different versions of the product such
as a new color or flavor can also be
introduced.

3.2.1.25 Functional requirement 2.4

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

Given the restaurant owner wants to select a 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

Given the restaurant owner wants to select a 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

Given the restaurant owner wants to select a preferred
language When the restaurant owner selects Spanish as a new
language Then the web-portal will show all text in Spanish

22
3.2.2 User Class 3 - Administrator

3.2.2.1 Functional requirement 3.1

ID: FR26
Feature: Administrator log in
There is no registration section
provided to the admin. The
admin must be directly
registered to the database.
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

3.2.2.2 Functional requirement 3.2

ID: FR27
Feature: Verify product
An administrator performs the role of verifying
whether the product can be put to sales in the
application.

Scenario: Verify a product

A product submitted for verification can be viewed from the admin portal
If the product meets with the demands of the consumers
The product is within the policies and agreements of the company
Such a product is verified and sent to sales
Scenario: Reject a restaurant owner
If the product is not under the courts of agreement
The seller fails to provide the mandatory information about the product
The seller is not compliant with the policies and agreement of the company
3.2.2.3 Functional requirement 3.3

ID: FR28
Feature: Handle tokens
Tokens are complaints generated by
seller and buyers regarding the
difficulties faced by them
Administrators will be able to manage tokens.
Scenario: Resolve a token
When a token is created, a person is assigned to the token
The queries provided in the token are resolved by admin
The admin gets back to the user to inform about the token

23
 Scenario: Deleting a token
When the token is not valid
When the token is a spam
When the token is in request queue for a long period of time
Scenario: Indicating past token
When a similar token is already resolved
The token is prejudice
The token is about some references and documentations
3.2.2.4 Functional requirement 3.4
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

Given the administrator is logged in
When the administrator creates a new dish
Then the new dish should be added to the list of dishes

Scenario: Editing an existing dish

Given the administrator is logged in
When the administrator edits an existing dish
Then the dish should be updated in the list of dishes

Scenario: Delete a dish

Given the administrator is logged in
When the administrator deletes a dish
Then the deleted dish should be removed from the list of dishes

3.2.2.5 Functional requirement 3.5

ID: FR30
Feature: Manage restaurant information
In order to manage restaurant information
An administrator
Should be logged in to the web-portal

Scenario: Add restaurant information

Given the administrator is logged in
When the administrator adds restaurant information
Then the information should be added to the restaurant

Scenario: Delete restaurant information

Given the administrator is logged in

24
 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

Given the administrator is logged in
And information about a restaurant exists
When the administrator edits the information
Then the information about the restaurant should be edited

3.2.2.6 Functional requirement 3.6

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 user’s information

Given the administrator is logged in
When the administrator edits an existing user
Then the user information should be updated

Scenario: Delete/Inactivate an existing user

Given the administrator is logged in
When the administrator deletes an existing user
Then the user should be deleted

3.2.2.7 Functional requirement 3.7

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

Given the administrator is logged in
When the administrator creates a new restaurant
owner Then the new restaurant owner should be added

Scenario: Edit an existing restaurant owner

Given the administrator is logged in
When the administrator edits an existing restaurant owner
Then the restaurant owner information should be updated

Scenario: Delete an existing restaurant owner

Given the administrator is logged in

25
 When the administrator deletes an existing restaurant owner
Then the restaurant owner should be deleted
And the restaurant information should be deleted

3.2.2.8 Functional requirement 3.8

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

Given the administrator wants to select a 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

Given the administrator wants to select a 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

Given the administrator wants to select a 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

26
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.

27
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 application’s 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

28
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.

29
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.
MUST: 100% of the time.

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.
MUST: 100% of the time.

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.
MUST: 100% of the time.

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.
MUST: 100% of the time.

30
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

31
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.

32
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.

33
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 9 7 5 6 6 8 6 47

FR2 3 6 4 3 4 5 3 28

FR3 4 6 8 6 7 7 6 44

FR4 6 5 3 6 7 6 6 39

FR5 6 9 3 5 7 6 5 41

FR6 8 10 10 9 9 10 10 66

FR7 10 8 10 10 8 10 8 64

FR8 10 10 10 8 8 10 8 64

FR9 6 8 5 8 9 7 8 51

FR10 3 6 7 5 6 8 4 39

FR11 3 4 3 6 5 5 5 31

FR12 4 3 7 6 6 7 7 40

FR13 4 6 9 7 7 7 7 47

FR14 4 4 3 6 6 6 5 34

FR15 4 7 7 5 6 6 6 41

FR16 4 7 5 5 6 6 6 39

FR17 4 3 4 2 5 7 3 28

FR18 6 6 3 7 4 4 6 36

FR19 5 4 5 5 4 7 5 35

FR20 5 7 6 5 6 6 5 40

FR21 5 4 4 6 5 4 6 34

FR22 6 8 6 6 8 7 6 47

34
FR23 8 7 6 5 5 6 6 43

FR24 5 10 9 10 9 5 10 58

FR25 3 5 5 4 4 3 4 28

FR26 8 5 8 6 5 7 6 45

FR27 9 9 8 7 8 6 8 55

FR28 7 7 5 5 7 5 5 41

FR29 7 7 5 5 6 5 5 40

FR30 5 2 6 3 5 4 4 29

FR31 9 10 5 8 6 4 8 50

FR32 8 7 5 8 6 5 8 47

FR33 3 4 5 4 4 3 4 27

QR1 8 7 7 7 7 6 7 49

QR2 6 6 6 7 5 7 7 44

QR3 6 8 5 6 5 7 6 43

QR4 6 8 5 6 7 7 6 45

QR5 6 6 4 5 4 5 5 35

QR6 8 9 5 7 9 10 8 56

QR7 9 8 7 9 7 8 9 57

QR8 6 7 6 8 7 8 7 49

QR9 6 9 9 9 7 7 10 57

QR10 4 4 3 3 4 6 3 27

QR11 4 6 2 3 4 6 3 28

QR12 9 9 7 8 6 8 8 55

QR13 7 5 6 7 4 5 6 40

QR14 8 5 8 9 5 5 7 47

35
QR15 7 7 7 6 6 7 6 46

QR16 8 9 8 8 6 7 7 53

QR17 6 6 5 5 5 6 5 38

QR18 6 6 5 8 5 6 6 42

QR19 6 8 7 7 7 7 7 49

QR20 7 8 6 6 7 5 6 45

QR21 8 6 4 7 7 7 6 45

QR22 8 9 9 8 8 4 8 54

QR23 7 9 8 7 7 4 7 49

36
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 5 7 7 1/3 1/5 1/3 1/3 5 7

FR7 1/5 1 3 5 6 1/5 1/3 1/3 1/3 5

FR8 1/7 1/3 1 4 5 1/6 1/4 1/4 1/5 3

FR24 1/7 1/5 1/4 1 1/3 1/5 1/5 1/3 5 4

FR27 3 1/6 1/5 3 1 1/9 1/5 1/5 1/7 2

QR6 5 5 6 5 9 1 3 3 2 8

37
QR7 3 3 4 5 5 1/3 1 3 1/3 7

QR9 3 3 4 3 5 1/3 1/3 1 1/3 5

QR12 1/5 3 5 1/5 7 1/2 3 3 1 9

QR22 1/7 1/5 1/3 1/4 1/2 1/8 1/7 1/5 1/9 1

Table 5 – Cost

COST FR6 FR7 FR8 FR24 FR27 QR6 QR7 QR9 QR12 QR22

FR6 1 1/5 1/2 3 5 1/7 1/3 1/5 1/3 7

FR7 5 1 1/5 7 3 1/5 1/3 1/5 3 5

FR8 2 5 1 3 5 1/9 1/5 1/6 1/5 7

FR24 1/3 1/7 1/3 1 3 1/3 2 1/5 3 7

FR27 1/5 1/3 1/5 1/3 1 1/7 1/6 1/7 1/6 2

QR6 7 5 9 3 7 1 3 2 3 9

QR7 3 3 5 1/2 6 1/3 1 2 3 7

QR9 5 5 6 5 7 1/2 1/2 1 3 5

QR12 3 1/3 5 1/5 1/3 6 1/3 1/3 1 5

QR22 1/7 1/5 7 7 1/2 1/9 1/7 1/5 1/5 1

38
 Figure 9 – Result of AHP method

Figure 10 – The value distribution and estimated cost

39
 Table 6 - The value distribution and estimated cost

FR6 FR7 FR8 FR24 FR27 QR6 QR7 QR9 QR12 QR22
Cost 5,31% 9,18% 7,91% 7,65% 1,73% 22,55% 13,92% 15,43% 12,60% 3,71%
Value 13,60% 7,12% 4,80% 5,93% 4,45% 23,41% 13,78% 10,31% 15,06% 1,53%

40
Appendix III: Five-Way Priority Scheme
Table 7 – Data of five-way priority scheme prioritization

Requirement
ID Priority by Stakeholder
User Restaurant owner Administrator Customer
FR1 Magnus 1 -2 -2 2
Elmira 1 -1 -2 2
Niclas 1 -2 -2 1
Faegheh 1 -2 -2 1
Sarah 1 -1 -1 1
Average 1 -1,6 -1,8 1,4
Sum -1
Rank of
Req. 13
User Restaurant owner Administrator Customer
FR2 Magnus 1 -2 -2 1
Elmira 1 -1 -2 1
Niclas 0 -2 -2 1
Faegheh -1 -2 -2 0
Sarah 0 -2 -2 0
Average 0,2 -1,8 -2 0,6
Sum -3
Rank of
Req. 34
User Restaurant owner Administrator Customer
FR3 Magnus 1 -2 -2 1
Elmira 0 -2 -2 1
Niclas 1 -2 -2 0
Faegheh 0 -2 -2 1
Sarah 1 -2 -1 1
Average 0,6 -2 -1,8 0,8
Sum -2,4
Rank of
Req. 29
User Restaurant owner Administrator Customer
FR4 Magnus 0 -2 -2 0
Elmira 0 -2 -2 0
Niclas 1 -2 -2 0
Faegheh 0 -2 -2 -1
Sarah 0 -2 -2 0
Average 0,2 -2 -2 -0,2
Sum -4
Rank of
Req. 41
User Restaurant owner Administrator Customer
FR5 Magnus 1 -2 -2 0
Elmira 1 -2 -2 0
Niclas 0 -2 -2 -1

41
 Faegheh -1 -2 -2 -1
Sarah 0 -2 -2 -1
Average 0,2 -2 -2 -0,6
Sum -4,4
Rank of
Req. 42
User Restaurant owner Administrator Customer
FR9 Magnus 1 1 -2 1
Elmira 1 0 -2 2
Niclas 1 0 -2 -1
Faegheh 1 -2 -2 1
Sarah 1 0 -2 0
Average 1 -0,2 -2 0,6
Sum -0,6
Rank of
Req. 8
User Restaurant owner Administrator Customer
FR10 Magnus 1 -2 -2 1
Elmira 1 0 -2 0
Niclas 1 -2 -2 -2
Faegheh 1 -2 -2 -1
Sarah 0 -2 -2 0
Average 0,8 -1,6 -2 -0,4
Sum -3,2
Rank of
Req. 36
User Restaurant owner Administrator Customer
FR11 Magnus 1 1 -2 1
Elmira 1 1 -2 1
Niclas 0 1 -2 -2
Faegheh 0 1 -2 1
Sarah 0 1 -2 1
Average 0,4 1 -2 0,4
Sum -0,2
Rank of
Req. 5
User Restaurant owner Administrator Customer
FR12 Magnus 1 -1 -2 0
Elmira 1 0 -2 0
Niclas 2 -2 -2 -2
Faegheh 2 -2 -2 0
Sarah 2 -1 -2 1
Average 1,6 -1,2 -2 -0,2
Sum -1,8
Rank of
Req. 18
User Restaurant owner Administrator Customer
FR13 Magnus 1 -1 -2 0
Elmira 1 0 -2 0

42
 Niclas 2 -2 -2 -2
Faegheh 2 -2 -2 1
Sarah 2 -1 -2 1
Average 1,6 -1,2 -2 0
Sum -1,6
Rank of
Req. 17
User Restaurant owner Administrator Customer
FR14 Magnus 1 -1 -2 1
Elmira 0 -2 -2 -1
Niclas 1 -2 -2 1
Faegheh 0 -2 -2 0
Sarah 0 -2 -2 0
Average 0,4 -1,8 -2 0,2
Sum -3,2
Rank of
Req. 37
User Restaurant owner Administrator Customer
FR15 Magnus 1 -1 -2 1
Elmira 1 0 -2 0
Niclas 1 -2 -2 -2
Faegheh 1 -2 -2 0
Sarah 1 -1 -2 1
Average 1 -1,2 -2 0
Sum -2,2
Rank of
Req. 24
User Restaurant owner Administrator Customer
FR16 Magnus 1 -1 -2 1
Elmira 1 0 -2 0
Niclas 1 -2 -2 -2
Faegheh 1 -2 -2 -1
Sarah 1 -2 -2 1
Average 1 -1,4 -2 -0,2
Sum -2,6
Rank of
Req. 31
User Restaurant owner Administrator Customer
FR17 Magnus 1 -1 -2 1
Elmira 1 0 -2 -1
Niclas 1 -2 -2 -2
Faegheh 0 -2 -2 -1
Sarah 1 -1 -2 0
Average 0,8 -1,2 -2 -0,6
Sum -3
Rank of
Req. 35
User Restaurant owner Administrator Customer
FR18 Magnus 2 -2 -2 1

43
 Elmira 1 -1 -2 1
Niclas 2 -2 -2 0
Faegheh 1 -2 -2 -1
Sarah 1 -2 -2 0
Average 1,4 -1,8 -2 0,2
Sum -2,2
Rank of
Req. 25
User Restaurant owner Administrator Customer
FR19 Magnus 1 -2 -2 1
Elmira 1 -2 -2 0
Niclas 1 -2 -2 -2
Faegheh 1 -2 -2 -1
Sarah 1 -2 -2 0
Average 1 -2 -2 -0,4
Sum -3,4
Rank of
Req. 38
User Restaurant owner Administrator Customer
FR20 Magnus 1 -2 -2 1
Elmira 2 -1 -2 1
Niclas 1 -2 -2 -2
Faegheh 1 -2 -2 0
Sarah 1 -2 -2 0
Average 1,2 -1,8 -2 0
Sum -2,6
Rank of
Req. 32
User Restaurant owner Administrator Customer
FR21 Magnus 0 -2 -2 0
Elmira 1 -2 -2 0
Niclas 0 -2 -2 -1
Faegheh -1 -2 -2 -1
Sarah 0 -2 -2 0
Average 0 -2 -2 -0,4
Sum -4,4
Rank of
Req. 43
User Restaurant owner Administrator Customer
FR22 Magnus -2 2 -2 2
Elmira -2 2 -2 2
Niclas -2 2 -2 1
Faegheh -2 2 -2 2
Sarah -2 2 -2 1
Average -2 2 -2 1,6
Sum -0,4
Rank of
Req. 6
User Restaurant owner Administrator Customer

44
FR23 Magnus -2 1 -2 2
Elmira -2 2 -2 1
Niclas -2 2 -2 1
Faegheh -2 2 -2 1
Sarah -2 2 -2 1
Average -2 1,8 -2 1,2
Sum -1
Rank of
Req. 14
User Restaurant owner Administrator Customer
FR25 Magnus -2 1 -2 1
Elmira -2 1 -2 0
Niclas -2 1 -2 -2
Faegheh -2 0 -2 -1
Sarah -1 1 -2 0
Average -1,8 0,8 -2 -0,4
Sum -3,4
Rank of
Req. 39
User Restaurant owner Administrator Customer
FR26 Magnus -2 -2 2 1
Elmira -2 -2 1 0
Niclas -2 -2 2 1
Faegheh -2 -2 2 1
Sarah -2 -2 2 1
Average -2 -2 1,8 0,8
Sum -1,4
Rank of
Req. 16
User Restaurant owner Administrator Customer
FR28 Magnus -2 0 1 1
Elmira -2 1 0 1
Niclas -1 1 2 0
Faegheh -2 -1 2 1
Sarah -1 0 1 1
Average -1,6 0,2 1,2 0,8
Sum 0,6
Rank of
Req. 2
User Restaurant owner Administrator Customer
FR29 Magnus -2 0 1 1
Elmira -2 1 0 1
Niclas -1 1 2 0
Faegheh -2 -1 2 1
Sarah -1 0 1 1
Average -1,6 0,2 1,2 0,8
Sum 0,6
Rank of
Req. 3

45
 User Restaurant owner Administrator Customer
FR30 Magnus -2 0 1 1
Elmira -1 0 1 1
Niclas -2 0 2 0
Faegheh -2 1 2 1
Sarah -1 1 2 1
Average -1,6 0,4 1,6 0,8
Sum 1,2
Rank of
Req. 1
User Restaurant owner Administrator Customer
FR31 Magnus 0 -2 1 1
Elmira 0 -2 0 1
Niclas 0 -2 2 0
Faegheh 0 -2 1 0
Sarah 0 -2 1 1
Average 0 -2 1 0,6
Sum -0,4
Rank of
Req. 7
User Restaurant owner Administrator Customer
FR32 Magnus -2 0 1 1
Elmira -2 0 0 1
Niclas -2 0 2 0
Faegheh -2 1 1 1
Sarah -2 0 1 1
Average -2 0,2 1 0,8
Sum 0
Rank of
Req. 4
User Restaurant owner Administrator Customer
FR33 Magnus -2 -2 0 0
Elmira -2 -2 0 0
Niclas -2 -2 0 -2
Faegheh -2 -2 0 -1
Sarah -2 -2 0 0
Average -2 -2 0 -0,6
Sum -4,6
Rank of
Req. 44
User Restaurant owner Administrator Customer
QR1 Magnus 2 -2 -2 2
Elmira 2 -2 -2 2
Niclas 2 -2 -2 0
Faegheh 2 -2 -2 1
Sarah 2 -2 -2 1
Average 2 -2 -2 1,2
Sum -0,8
Rank of 10

46
 Req.
User Restaurant owner Administrator Customer
QR2 Magnus 2 -2 -2 2
Elmira 2 -2 -2 2
Niclas 2 -2 -2 0
Faegheh 2 -2 -2 1
Sarah 2 -2 -2 1
Average 2 -2 -2 1,2
Sum -0,8
Rank of
Req. 11
User Restaurant owner Administrator Customer
QR3 Magnus 1 -2 -2 1
Elmira 1 -1 -2 1
Niclas 1 -1 -2 0
Faegheh 0 -1 -2 -1
Sarah 1 -1 -2 1
Average 0,8 -1,2 -2 0,4
Sum -2
Rank of
Req. 21
User Restaurant owner Administrator Customer
QR4 Magnus 1 -2 -2 1
Elmira 1 -1 -2 1
Niclas 1 -1 -2 0
Faegheh 1 -1 -2 0
Sarah 1 -1 -2 0
Average 1 -1,2 -2 0,4
Sum -1,8
Rank of
Req. 19
User Restaurant owner Administrator Customer
QR5 Magnus 1 -1 -2 1
Elmira 1 -1 -2 1
Niclas 1 0 -2 -2
Faegheh 1 1 -2 -1
Sarah 0 -1 -2 0
Average 0,8 -0,4 -2 -0,2
Sum -1,8
Rank of
Req. 20
User Restaurant owner Administrator Customer
QR8 Magnus 1 -2 -2 1
Elmira 1 -2 -2 0
Niclas 1 -2 -2 2
Faegheh 1 -2 -2 0
Sarah 0 -1 -1 0
Average 0,8 -1,8 -1,8 0,6
Sum -2,2

47
 Rank of
Req. 26
User Restaurant owner Administrator Customer
QR10 Magnus -1 -2 -2 -1
Elmira -1 -2 -2 0
Niclas -1 -2 -2 -1
Faegheh -1 -2 -2 -1
Sarah -1 -2 -2 0
Average -1 -2 -2 -0,6
Sum -5,6
Rank of
Req. 45
User Restaurant owner Administrator Customer
QR11 Magnus -1 -2 -2 -1
Elmira 0 -2 -2 0
Niclas -1 -2 -2 -1
Faegheh -1 -2 -2 -1
Sarah -1 -2 -1
Average -0,8 -2 -2 -0,8
Sum -5,6
Rank of
Req. 46
User Restaurant owner Administrator Customer
QR13 Magnus -2 2 -1 2
Elmira -2 1 -2 1
Niclas -2 2 -2 2
Faegheh -2 2 -2 1
Sarah -2 1 -2
Average -2 1,6 -1,8 1,5
Sum -0,7
Rank of
Req. 9
User Restaurant owner Administrator Customer
QR14 Magnus -2 -2 2 2
Elmira -2 -2 1 1
Niclas -2 -2 2 2
Faegheh -2 -2 2 2
Sarah -2 -2 1 1
Average -2 -2 1,6 1,6
Sum -0,8
Rank of
Req. 12
User Restaurant owner Administrator Customer
QR15 Magnus -2 0 -2 -1
Elmira -2 0 -2 2
Niclas -2 1 -2 2
Faegheh -2 0 -2 2
Sarah -2 1 -2 1
Average -2 0,4 -2 1,2

48
 Sum -2,4
Rank of
Req. 30
User Restaurant owner Administrator Customer
QR16 Magnus -2 -2 0 -1
Elmira -2 -1 0 2
Niclas -2 -2 1 2
Faegheh -2 -2 1 0
Sarah -2 -2 0 0
Average -2 -1,8 0,4 0,6
Sum -2,8
Rank of
Req. 33
User Restaurant owner Administrator Customer
QR17 Magnus 2 -2 -2 0
Elmira 1 -2 -2 2
Niclas 1 -2 -2 2
Faegheh 0 -2 -2 1
Sarah 0 -2 -2 1
Average 0,8 -2 -2 1,2
Sum -2
Rank of
Req. 22
User Restaurant owner Administrator Customer
QR18 Magnus -2 2 -2 0
Elmira -2 1 -2 2
Niclas -2 1 -2 2
Faegheh -2 0 -2 1
Sarah -2 0 -2 1
Average -2 0,8 -2 1,2
Sum -2
Rank of
Req. 23
User Restaurant owner Administrator Customer
QR19 Magnus -2 -2 -2 2
Elmira -1 -1 -2 2
Niclas -2 -2 -2 1
Faegheh -2 -2 -2 2
Sarah -1 -1 -2 1
Average -1,6 -1,6 -2 1,6
Sum -3,6
Rank of
Req. 40
User Restaurant owner Administrator Customer
QR20 Magnus 0 -2 -2 2
Elmira 0 -2 -2 2
Niclas 1 -2 -2 1
Faegheh 1 -2 -2 1
Sarah -1 -1 -2 1

49
 Average 0,2 -1,8 -2 1,4
Sum -2,2
Rank of
Req. 27
User Restaurant owner Administrator Customer
QR21 Magnus -2 -2 -2 2
Elmira -1 -1 -1 2
Niclas -2 -2 -2 2
Faegheh 1 -2 -2 2
Sarah -1 -1 -1 2
Average -1 -1,6 -1,6 2
Sum -2,2
Rank of
Req. 28
User Restaurant owner Administrator Customer
QR23 Magnus 1 -2 -2 1
Elmira 1 0 -2 2
Niclas 1 -2 -2 1
Faegheh 1 -2 -2 1
Sarah 1 -1 -2 1
Average 1 -1,4 -2 1,2
Sum -1,2
Rank of
Req. 15

Table 8 – Result of five-way priority scheme prioritization

Priority Requirement ID
11 FR30
12 FR28
13 FR29
14 FR32
15 FR11
16 FR22
17 FR31
18 FR9
19 QR13
20 QR1
21 QR2
22 QR14
23 FR1
24 FR23
25 QR23
26 FR26
27 FR13
28 FR12
29 QR4
30 QR5

50
31 QR3
32 QR17
33 QR18
34 FR15
35 FR18
36 QR8
37 QR20
38 QR21
39 FR3
40 QR15
41 FR16
42 FR20
43 QR16
44 FR2
45 FR17
46 FR10
47 FR14
48 FR19
49 FR25
50 QR19
51 FR4
52 FR5
53 FR21
54 FR33
55 QR10
56 QR11

51
Appendix IV: Release Plan
Table 9 – Release plan

RE: Dependencies Description Motivation Release Duration

FR1 - Download This requirement makes the

mobile application available for users and is
1 80
application therefore an important requirement to
include in the first release.

FR2 FR1 Download and The download of the new versions is

notify users of important for users to be able to
new releases receive the future release of the 1 2
application and will therefore be
included in the first release.

FR3 - User For the user to be able to use the

registration application, the user has to registrant.
1 4
Consequently, this requirement needs
to be met in the first release.

FR4 FR1, FR3 User Log-in For the user to be able to use the
application, the user has to log in.
1 2
Consequently, this requirement needs
to be met in the first release.

FR5 FR1 Retrieve For the user to be able to receive a

Password forgotten password will have to wait
to the second release. This is not vital 2 1
for the application and was therefore
not included in the first release.

FR6 FR4 Search The search feature is one of the most

important and vital part of the
system. It's part of the basic goal of 1 2
the program and should therefore be
included in the first release.

FR7 FR6, QR22, Search result in The ability to show the search result
QR23 a map view in a map view is part of the basic
goal of the program and should 1 1
therefore be included in the first
release.

FR8 FR6, QR22 Search result in The ability to show the search result
2 2
a list view in a list view is part of the basic goal

52
 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 FR7, FR8 Navigation to To make the first release interesting

restaurant and useful for the users, this is 1 2
included in the first release.

FR10 FR7, FR8 Switch result The switch between the result views
view will be implemented after the result
list is implemented. This is not in
3 1
some way vital for the application
and can be discarded if the project
gets delayed or overruns the budget.

FR11 FR7, FR8 Selecting the This will be added as an additional

information feature in the second release to make
2 1
link the application more attractive for the
users.

FR12 FR8 Search by price This will be added as an additional

feature in the third release to make
2 1
the application more attractive for the
users.

FR13 FR7 Search by This is the search function that will

1 1
destination be included in the first release.

FR14 FR12, FR13 Accepted input This is a requirement that will make
for price and the application more stable. It will be
3 1
destination added in the third release.
search

FR15 FR7 Search by This will be added as an additional

restaurant type feature to the second release to make
3 3
the application more attractive for the
users.

FR16 FR7 Search by This will be added as an additional

specific dish feature in the third release to make
3 3
the application more attractive for the
users.

FR17 FR6 Free-text This will be added as an additional

2 3
search feature to the first release to make the
application more attractive for the

53
 users.

FR18 FR5 No search This is a requirement that will make

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

FR19 FR8 Sorting results This will be added as an additional

feature to the first release to make the
2 2
application more attractive for the
users.

FR20 FR7, FR8 Filtering This will be added as an additional

results feature to the first release to make the
2 4
application more attractive for the
users.

FR21 FR1 Profile page This will be added as an additional

feature in the third release to make
3 1
the application more attractive for the
users.

FR22 - Create account The restaurant owner is a vital part of

- restaurant the system and must be included in 1 2
owner the first release.

FR23 FR27 Log-in - This should be included in the first

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

FR24 FR23, FR25 Manage info - The ability for the restaurant owner
restaurant to manage the information about the
owner restaurant is very important, if there 1 2
is no information there is nothing to
search for.

FR25 - Selecting This will be added as an additional

preferred feature in the third release to make
language on the application more attractive for the
3 3
the web-portal users. It is not vital for the
- restaurant application and will therefore be
owner implemented in the third release.

54
FR26 - Log-in - admin This should be included in the first
release because the administrator
1 2
needs to be able to log in so she/hi
can manage the system.

FR27 FR26, FR22 Verify It's important for the admin to be able
restaurant to verify the restaurant owner’s 1 2
owner application for registration.

FR28 FR26 Manage rest. The type search will be added in the
types - second release. 2 1
administrator

FR29 FR26 Manage rest. The dish search will be added in the
dished - second release. 2 1
administrator

FR30 FR26 Manage rest. The info link will be added in the
info - second release. 2 1
administrator

FR31 FR26 Manage users - The administrator needs to be able to

1 1
administrator handle users during the first release.

FR32 FR26 Selecting The administrator needs to be able to

preferred handle restaurant owners during the
language on first release. 1 1
the web-portal
- administrator

FR33 FR26 Language This will be added as an additional

selection on feature in the third release to make
portal the application more attractive for the
3 2
users. It is not vital for the
application and will therefore be
implemented in the third release.

QR1 - Prominent This is a very high-prioritized

search feature requirement. Consequently, this will 1 1
be included in the first release.

QR2 - The ease of This is a very high-prioritized

usage of the requirement. Consequently, this will 1 1
search feature be included in the first release.

55
QR3 - The ease of This is a high-prioritized
usage of the requirement. But we have decided to
result in the list put this in the second release in favor 2 1
view for more vital and higher prioritized
requirements.

QR4 - The ease of This is a high-prioritized

usage of the requirement. But we have decided to
result in map put this in the second release in favor 2 1
view for more vital and higher prioritized
requirements.

QR5 - The ease of This will be considered when all the

usage of the mandatory requirements for the
3 1
information system have been implemented.
link

QR6 - System This will be considered and

response time continuously improved during the
whole process. We can only 3 *
discharge the requirement when all
functions are implemented.

QR7 - System This will be considered and

availability continuously improved during the 1 *
whole process.

QR8 QR22, QR23, System This will be considered and

FR14, FR15, dependability continuously improved during the
FR16, FR17 whole process. We can only 3 *
discharge the requirement when all
functions are implemented.

QR9 - System This will be considered and

reliability continuously improved during the 1 *
whole process.

QR10 - Application This will be considered and

hard drive continuously improved during the
space usage whole process. We can only 3 *
discharge the requirement when all
functions are implemented.

QR11 - Application This will be considered and

continuously improved during the 3 *
memory usage
whole process. We can only

56
 discharge the requirement when all
functions are implemented.

QR12 - Communicatio As the system grows, and with

n security respect for the users this need to be 2 4
included.

QR13 FR22 Non-existing This need to be included in the first

account release to enhance the safety of the
1 3
security for system.
rest. Owners

QR14 - Non-existing This needs to be included in the first

account release to enhance the safety of the
1 3
security for the system.
administrators

QR15 FR23 Log in security This needs to be included in the first

for rest. release to prevent illegitimate
1 3
Owners attempts to use the restaurants
owners account.

QR16 - Log in security This need to be included in the first

for release to prevent illegitimate
1 2
administrators attempts to use the administrator
account.

QR17 FR3 User account This needs to be included in the first

creation release to resolve conflict between 1 2
security users with the same name.

QR18 FR22 Restaurant This needs to be included in the first

owner account release to resolve conflict between
1 2
creation restaurant owners with the same
security name.

QR19 - Application This will be considered and

extendibility continuously improved during 1 *
development.

QR20 - Application This will be considered and

portability continuously improved during the 1 50
whole process.

QR21 - Application The test environment for the system

1 30
testability will continuously be built as the

57
 system expands.

QR22 - Internet Internet connection is mandatory for

connection the application to work and is 1 *
therefore included in the first release.

QR23 - GPS GPS connection is mandatory for the

connection application to be able to show the
1 2
result and is therefore included in the
first release.

58
Figure 11 – Release plan schedule

59
Appendix V: I-star

Figure 12 – SD diagram

60
Figure 13 – SR

61