UNIVERSITY OF TARTU INSTITUTE OF COMPUTER SCIENCE

UNIVERSITY OF TARTU INSTITUTE OF COMPUTER SCIENCE

Software Requirements Specification Foodify - Food Ordering Application

Taron Davtyan Yevhen Dorodnikov Kyrylo Lobachev Margarit Shmavonyan Vello Vaherpuu

TARTU 2018

Table of Contents Revision history 4

1.Introduction 5 1.1 Purpose 5 1.2 Scope (system context) 5 1.3 Acronyms and definitions 5 1.4 References 6

2. General Description 6 2.1 Overview of current document 6 2.2 Product perspective 6 2.3 Product functions 6 2.4 User classes and characteristics 7

2.4.1 Target user 7 2.4.2 Least important user 7 2.4.3 Use case diagram 7

2.5 Operating environment 8 2.6 Design and implementation constraints 8

2.6.1 Design 8 2.6.2 Development 9

2.7 User documentation 9 2.8 Assumptions and dependencies 9

3. Specific requirements 9 3.1 Requirement Sources 9 3.2 System Goal Model 10 3.3 Scenarios 10

3.3.1 Choosing the restaurant 10 3.3.2 Adding meals to order 11 3.3.3 Choosing pick-up time 13 3.3.4 Remove meals from the order 14 3.3.5 Paying by credit card 15

3.4 Functional requirements 16 3.4.1 Common functional requirements 16

3.4.1.1 Contact information 16 3.4.1.2 City selection 17 3.4.1.3 Restaurant filtering 17 3.4.1.4 User registering 18 3.4.1.5 History of orders 18

2

3.4.1.6 Edit contact information 19 3.4.1.7 Onboarding 19

3.4.2 Ordering 20 3.4.2.1 Restaurant selection 31 3.4.2.2 Add meals to order 31 3.4.2.3 Remove meals from order 32 3.4.2.4 Pickup time selection 32 3.4.2.5 Pay for order 33 3.4.2.6 Order tracking 33 3.4.2.7 Meal selection 34

3.4.3 Table reservation 35 3.4.3.1 View available tables 35 3.4.3.2 Book a table 35 3.4.3.3 Cancel reservation 36 3.4.3.4 Send confirmation of table reservation 36 3.4.3.5 View active reservations 37 3.4.3.6 Reservation limit 37

3.5 Non-functional requirements 38 3.5.1 Supported operating systems 38 3.5.2 Support multiple users simultaneously 38 3.5.3 Supported languages 39 3.5.4 Protection from third parties 39 3.5.5 Maintenance complexity 40 3.5.6 Shadow maintenance 40 3.5.7 System uptime 41 3.5.8 Response time 42 3.5.9 Port to windows mobile 42 3.5.10 Installation of the system 43

3.6 Prioritization & traceability 44 3.6.1 Prioritization plots 47 3.6.2 Traceability model 50 3.6.3 Traceability matrix for requirements and use cases 50 3.6.4 Traceability matrix for solution oriented requirements and use cases 51 3.6.5 Traceability matrix for solution oriented requirements and requirement model 52

3.7 Requirements hierarchy 54 3.8 Dependency models 55

3.8.1 Social model 55 3.8.2 Technical model 56

3

Revision history Name Date Reason for changes Changes Version

Initial document 14.10.2018 1.0

Reviewed document

23.10.2018 Modifications according to feedback

Organized functional requirements, added requirement hierarchy and prioritization plot.

1.1

Workshop 2 11.11.2018 2.0

Reviewed document

18.11.2018 Modifications according to Workshop 2 feedback

Non-functional requirements, Actor and goal modelling, Scenario modelling, System Goal model

2.1

Workshop 3 02.12.2018 3.0

Reviewed document

09.12.2018 Modifications according to Workshop 3 feedback

Solution-oriented Requirements, class diagram, state models, sequence diagram

3.1

Workshop 4 15.12.2018 Restructured requirements according to Workshop 3 feedback

Prototype added to product functions, model and requirements restructuring.

4.0

4

Requirements Specification

1.Introduction

1.1 Purpose This document represents detailed requirements for the “Foodify” Food ordering application. The people who will be using or reading this SRS document will be requirements engineers, developers, designers, product owner, project manager and testers.

1.2 Scope (system context) The company “Foodify” has already working web service that allows customers to order food in advance, book tables and pay up front. The company has found now that they need to offer their service through native mobile applications as well to increase customer satisfaction. Their current system already has the data about restaurants and the authentication logic for users. In current scope is the development of both iOS and Android mobile applications that connect to existing backend. Backend and web service development are out of scope. The applications will be available in Google Play Store and Apple App Store. In order to develop iOS applications the developers must have computers that run on Mac OS X. The application should comply with GDPR and all of the communication has to be sent over HTTPS.

1.3 Acronyms and definitions

Term Definition

SRS Software Requirements Specifications

GDPR General Data Protection Regulation

FR Functional Requirement

NFR Non-functional Requirement

Android Operating system for mobile phones

iOS Operating system for mobile phones

Application Refers to both iOS and Android applications if not specified otherwise.

5

Guest Here: type of actor whose information is not stored in the system

User Here: type of actor who uses the system. His information can be or not be stored in system

Registered user

Here: type of actor whose information is stored in system

1.4 References

Reference Description Last checked

https://david-smith.org/iosversionstats/

iOS version usage statistics 14.10.2018

https://developer.android.com/distribute/best-practices/develop/target-sdk

Android target requirements 14.10.2018

2. General Description

2.1 Overview of current document The document describes the application to be created, the purpose why the application is needed, the people who should work on the application, also the scope, benefits and goals of the application are defined.

2.2 Product perspective The mobile application is an extension to already existing and working system. Currently the web service and backend are communicating over JSON API. API is fully documented and should cover all the needs of the mobile application.

2.3 Product functions The main function of the application is to allow user to select restaurant, add meals to order and pay for it up front. Other functionalities include booking a table, store user information, view order history, registration and authentication. Prototype can be found in: https://www.youtube.com/watch?v=N6qbEom8u1E.

6






https://www.youtube.com/watch?v=N6qbEom8u1E

2.4 User classes and characteristics

2.4.1 Target user Age: 15 - 45 Gender: Male & Female Occupation: Student / Working Description: Impatient, value their time, probably with some time management skills, tech-savvy

2.4.2 Least important user Age: <15, > 60 Description: Don’t care about waiting times, value human service, their first need is not food rather the experience itself. Non-tech people.

2.4.3 Use case diagram A use case diagram represents user's interaction with the system. Use case diagrams display the relationship between the user and the use cases. As it is shown in the Figure 1 - Use case diagram there is one actor (User/Registered user) which engages with the system when ordering the meal. For ordering a meal, the user/registered user chooses a meal, then chooses the restaurant and finally chooses the time of picking up the meal. All the 3 actions are included in Ordering meal use case. Also user/registered user pays for the order through application.

Use Case IDs Description

UC 1.0 User/Registered user orders a meal with the help of the application

UC 1.1 User/Registered user chooses the meal

UC 1.2 User/Registered user chooses the restaurant

UC 1.3 User/Registered user chooses the time of the pickup

UC 2.0 User/Registered user pays for the order

7

Figure 1 - Use Case Diagram

2.5 Operating environment The iOS application should target iOS 11.0 and should work on every iPhone starting from iPhone 5s. This decision is based on the data provided in iOS version usage statistics. The Android application should target Android 8.0 (API 26), since this is required by Google Play Store (Android target requirements).

2.6 Design and implementation constraints

2.6.1 Design While designing the Android and iOS versions, best practices should be taken into account. Keep in mind that Android and iOS UX are acting different.

8

2.6.2 Development In order to develop iOS applications the developers must have a computer running on Mac OS X. It is recommended that developers have access to physical devices running on Android and iOS.

2.7 User documentation There is a 3 step onboarding tutorial how to use the application. This is shown for all first time users. Also there is an option for users to view the tutorial again.

2.8 Assumptions and dependencies

ID Assumption / Dependency Affected Requirements

1 Pickup time can not be in past FR-7

3. Specific requirements

3.1 Requirement Sources

ID Description

S1 The customer wants to be able to order food without standing in line or being in restorant.

S2 Stakeholder wants to gather data on customer’s orders.

S3 The customer wants to book a table remotely, without need to call to restaurant.

S4 The customer wants to manage his orders and bookings.

S5 Stakeholder wants easy-to-use and maintainable application.

S7 Stakeholder wants system to support 4 languages: english, german, estonian and russian due to variety of customer’s language preferences.

S10 System must not make user wait too long for his\her request to be processed.

9

S11 In future it is planned to support Windows Mobile platform.

S12 System data must be protected from third parties.

3.2 System Goal Model The most important goal for our customer is to get food as fast as possible and in order to achieve that, the customer has to first make an order. Currently the only way to do that is to go to the restaurant and order from there or by calling the restaurant in advance. With our application we add the possibility to order through mobile application that should be more convenient for the customers. The ordering process can be seen from Figure 2, where KAOS modelling language is used. KAOS modelling language describes three important “Why”, “How” and “How else” questions.

Figure 2 - System Goal Model

3.3 Scenarios

3.3.1 Choosing the restaurant

Use Case ID: UC1

Use Case Name: Choosing the restaurant

10

Created By: Margarit Shmavonyan

Last Updated By: Margarit Shmavonyan

Date Created: 08.11.2018 Last Updated: 18.11.2018

Version: 1.1

Actors: User / Registered User

Description The User / Registered User will see a list of the restaurants and will be able to choose a restaurant.

Trigger: -

Preconditions: -

Postconditions: The selected restaurants are added to the User / Registered User order

Normal Flow: 1. User / Registered User scrolls to the restaurant that will be added to the order

2. User / Registered chooses the restaurant 3. System shows the restaurant page 4. User / Registered User can go to next step

Alternative Flows: -

Exceptions: -

Includes: -

Priority: Medium

Frequency of Use: Once per order.

Business Rules: -

Special Requirements:

-

Assumptions: User / Registered User is connected to the internet.

Notes and Issues: 3.2.2.1 Restaurant selection

3.3.2 Adding meals to order

Use Case ID: UC2

11

Use Case Name: Adding meals to order

Created By: Vello Vaherpuu Last Updated By: Margarit Shmavonyan


Version: 1.1


Description After having selected the restaurant, User / Registered User will see a list of meals he/she can add to order.

Trigger: -

Preconditions: User / Registered User has selected a restaurant

Postconditions: The selected meals are added to User / Registered User’s order

Normal Flow: 1. User / Registered User scrolls to the meal that will be added to order

2. User / Registered User taps on [+] button (can be done multiple times)

3. The number of meals increases by the system 4. The meals are added to the order by the system 5. User / Registered User can go to the next step


Exceptions: User / Registered User wants to go to the next step without selecting any meals:

1. User / Registered User taps on “go to next step” 2. Exception modal appears

Includes: -

Priority: High

Frequency of Use: Mostly once per order

Business Rules: -


There should be a note on the top about alcohol and underage people.


Notes and Issues: 3.2.2.2 Add meals to order

12

3.3.3 Choosing pick-up time

Use Case ID: UC3

Use Case Name: Choosing the time of the pick-up

Created By: Taron Davtyan Last Updated By: Margarit Shmavonyan

Date Created: 08/11/2018 Last Updated: 18/11/2018

Version: 1.1


Description: User/registered user chooses the time of pickup.

Trigger: -

Preconditions: User / Registered User has selected the meal and the restaurant.

Postconditions: User / Registered User has chosen the time of the pickup.

Normal Flow: 1. The system automatically sets the pickup time to 1 hour later of the order time.

2. User / Registered User taps time and time picker appears. 3. User / Registered User can move to the next step.

Alternative Flows: 1. User / Registered User can check “Prepare as fast as possible” option.

2. User / Registered User can move to the next step.

Exceptions: 1. User / Registered User chooses time in past. 2. Exception modal appears.

1. User / Registered User chooses time when restaurant is

closed. 2. Exception modal appears.

Includes: -

Priority: Medium

Frequency of Use: Once per order

Business Rules: -

13


-


Notes and Issues: 3.2.2.4 Pickup time selection

3.3.4 Remove meals from the order

Use Case ID: UC4

Use Case Name: Remove meals from the order

Created By: Taron Davtyan Last Updated By: Taron Davtyan


Version: 1.0


Description: User/Registered user should be able to remove meals from the order

Trigger: -

Preconditions: User / Registered User selected the meals and the restaurant

Postconditions: User / Registered User removed the meal from the order

Normal Flow: 1. User / Registered User scrolls to the meal that will be removed from the order

2. User / Registered User taps on [-] button (Button can be pressed until no more meals are in order)

3. The meal is removed from the order by the system 4. User / Registered User can choose another meal 5. User / Registered User can go to next step


Exceptions: User / Registered User wants to go to the next step without selecting any meals:

1. User / Registered User taps on “go to next step” 2. Exception modal appears

Includes: -

Priority: High

14

Frequency of Use: Multiple time per order

Business Rules: -


-


Notes and Issues: 3.2.2.3 Remove meals from order

3.3.5 Paying by credit card

Use Case ID: UC5

Use Case Name: Paying by credit card

Created By: Margarit Shmavonyan

Last Updated By: Margarit Shmavonyan


Version: 1.0


Description: User / Registered User should be able to pay for the order with credit card.

Trigger: -

Preconditions: User / Registered User has selected the meal, the restaurant and the pickup time.

Postconditions: User / Registered User has paid with his credit card.

Normal Flow: 1. After confirming the order the User / Registered user is presented an option to pay upfront by credit card by the system

2. User / Registered user chooses the credit card option 3. User / Registered user fills in the credit card details 4. User / Registered user clicks on the “Pay” button 5. The money is transferred to the company account 6. User / Registered User can go to next step


15

Exceptions: 1. User / Registered user doesn’t fill in the details of the credit card.

2. Exception modal appears.

Includes: -

Priority: Low

Frequency of Use: Mostly once per order

Business Rules: -


-

Assumptions: User / Registered User are connected to the internet.

Notes and Issues: 3.2.2.5 Option to pay for order

3.4 Functional requirements

3.4.1 Common functional requirements

3.4.1.1 Contact information

Requirement #: 1 Requirement type: Functional

Event / use case #:

Description: User should be able to fill in contact information during registration

Rationale: Need to know who ordered and where to send invoice

Originator: Vello

Fit Criterion: The data (E-mail, Full Name, Phone number) is stored on mobile and sent to server when an order is placed

Customer Satisfaction: 4 Customer Disatisfaction: 5

Priority: High Conflicts:

Supporting Materials:

History: Created 13.10.2018 Modified 06.12.2018 - edited description

Version: 3.0

16

3.4.1.2 City selection


Event / use case #:

Description: User should be able to choose his/her current city

Rationale: Show only relevant restaurants to user

Originator: Vello

Fit Criterion: The user is presented a list of selectable Estonian cities that are currently supported


Priority: Medium Conflicts:


History: Created 13.10.2018

Version: 1.0

3.4.1.3 Restaurant filtering


Event / use case #:

Description: User should be able to search for a specific restaurant

Rationale: Speeds up the restaurant selection process

Originator: Vello

Fit Criterion: The user enters text into search field and only matching restaurants are shown to user





Version: 1.0

17

3.4.1.4 User registering


Event / use case #:

Description: Guest should be able to register in the system

Rationale: Makes customer a part of the system. Allows to keep statistics.

Originator: Yevhen

Fit Criterion: After guest launched an application, he can add himself to the system





Version: 1.0

3.4.1.5 History of orders


Event / use case #:

Description: Registered user should be able to view history of his orders

Rationale: Helps user to manage his orders. Satisfies user

Originator: Yevhen

Fit Criterion: After authorization, user can access a page with his completed orders


Priority: Low Conflicts:



Version: 1.0

18

3.4.1.6 Edit contact information


Event / use case #:

Description: Registered user should be able to edit his information

Rationale: Helps user to manage his information. Prevents user from creating new accounts. Simplifies work with statistics

Originator: Yevhen

Fit Criterion: After authorization, user can access a page where his data can be edited





Version: 1.0

3.4.1.7 Onboarding


Event / use case #:

Description: System should provide 3 step tutorial of how to make orders and book tables through the app

Rationale: Helps customer to learn of how to use the app

Originator: Yevhen

Fit Criterion: On first system launch, tutorial of how to use an app will be displayed





Version: 1.0

19

3.4.2 Ordering In our class diagram RegisteredUser class can place orders and update the contact information they provided. Restaurant class has the following functions addMeal(), deleteRestaurant(), addRestaurant() and getAvailablemeals(). In the Meal class the attribute type can be vegan, vegetarian, etc. The Order class has a relation with Restaurant, and it contains Meals and generates the Invoice. Invoice class can generate a PDF for the payment and it also has the pay() and cancel() functions.


Event / use case #:

Description: Meals should be available for people who have different preferences (vegetarian, vegan, etc)

Rationale: Need to know people’s preferences to know what meals to include in the menu

Originator: Margarit

20

Fit Criterion: The required meals are included in the menu of the restaurant.

Customer Satisfaction: 4 Customer Dissatisfaction: 5




Version: 3.0


Event / use case #:

Description: User should be able to be to generate a PDF.

Rationale: Receive payback if required.


Fit Criterion: After payment is done, user has to option to generate a PDF.





Version: 3.0


Event / use case #:

Description: User should be able to see the total sum of the ordered meals.

Rationale: Need to know total sum before payment and make changes if there is a need.

Originator: Taron

21

Fit Criterion: After selecting meals user is able to see the total sum of the order.





Version: 3.0


Event / use case #:

Description: User should be able to cancel the order.

Rationale: User can cancel his order if he changed his mind.

Originator: Taron

Fit Criterion: After the payment user is able to cancel the order.





Version: 3.0

Registered user is able to update contact information, all fields can be changed at once or one by one.

22


Event / use case #:

Description: User should be able to update their contact information.

Rationale: Helps user to have an updated information. Prevents user from creating new accounts.

Originator: Taron

Fit Criterion: After authorization, user can access a page where his/her data can be edited

23




History: Created on 06.12.2018

Version: 3.0 Restaurant lifecycle state model shows the status of the restaurant in the application whether the restaurant is open or closed. Restaurant is open when “currentTime > openFrom && currentTime < openUntil”, restaurant is closed when “currentTime > openUntil || currentTime < openFrom”. Restaurant also can be deleted by deleteRestaurant() function.

’

24


Event / use case #:

Description: User should be able to view the open and closed hours of a restaurant

Rationale: Need to make sure user knows all information required about the restaurant


Fit Criterion: During restaurant selection, restaurant open hours are shown to user





Version: 3.0

Order state model shows the status of the meal. At first the status of the order is empty. The status of the order becomes “Order with meals” in case if a new meal is added. After setting the pickup time the status of the order is changed to “Unconfirmed order”. When the order is confirmed, the status of the order is changed to “Pending Order”. Afterwards, when the order is accepted then the order is being prepared. When the order is ready, the order status becomes closed.

25


Event / use case #:

Description: User should be able to view the status of the order

Rationale: Need to know whether order is ready or not

Originator: Kyrylo

Fit Criterion: After the order is done, its status will be shown to user





Version: 3.0

26

Meal availability state model shows whether the meals the user selected is available in the restaurant or not. Meal also can be deleted by removeMealFromRestaurant() function.


Event / use case #:

Description: User should be able to see if the meal is available or unavailable.

Rationale: Need to make sure that user orders only available meals.

Originator: Taron

27

Fit Criterion: During meal selection the availability of the meal is shown to the user.





Version: 3.0 Invoice state model shows the status of the Invoice during the payment for the meal by the user. The status of the Invoices can be pending, paid and cancelled. Invoice starts at “Pending Invoice” status. When user pays for the meal the status of the Invoice changes to “Invoice paid”. User can also cancel the invoice if needed. In that case the status of the invoice is “Invoice Cancelled”.

28

Requirement #: 29 Requirement type: Event / use case #:

Description: User should be able to pay for the order

Rationale: Food will not be prepared if the payment is not confirmed.


Fit Criterion: After payment is done, the status is changed.





Version: 3.0

29

Sequence diagram

30

3.4.2.1 Restaurant selection


Event / use case #:

Description: User should be able to choose a restaurant where he/she wants to order from

Rationale: That is part of the main purpose of the app

Originator: Vello

Fit Criterion: The user is presented a list of Estonian cities that are supported by the application



Supporting Materials: Sequence diagram

History: Created 13.10.2018 Modified 09.12.2018

Version: 3.0

3.4.2.2 Add meals to order


Event / use case #:

Description: User should be able to add meals from selected restaurant to his/her order


Originator: Vello

Fit Criterion: The user presses add button and a meal is added to the order. Button can be pressed multiple times.

31





Version: 3.0

3.4.2.3 Remove meals from order


Event / use case #:

Description: User should be able to remove meals from his/her order

Rationale: User may misclick or change his / her mind during the meal selection

Originator: Vello

Fit Criterion: Some meals are already added to order. User presses remove button and a meal is removed from order. Button can be pressed until no more meals are in order.





Version: 1.0

3.4.2.4 Pickup time selection


Description: User should be able to select the order pickup time

Rationale: It will help restaurants to start preparing meals at the best time possible and users can plan their meals ahead of time.

Originator: Vello

32

Fit Criterion: Before placing an order the user is presented a pickup time selection. Later the pickup time must be present in order information.



Supporting Materials: Assumption-1, Sequence diagram


Version: 3.0

3.4.2.5 Pay for order


Event / use case #:

Description: User should be able to pay for order via different payment methods

Rationale: Saves processing time in the restaurant. Restaurants are certain that someone is coming to pick up the meal.

Originator: Vello

Fit Criterion: After confirming the order the user is presented an option to pay up front by credit card or PayPal. Choosing one of the option the user fills in the details and the money is transferred to our company account. Order id is present in the payment description.





Version: 3.0

3.4.2.6 Order tracking


33

Functional

Description: Registered user should be able to track his/her order

Rationale: Users should be more satisfied. Users know approximately when they should head out to pick up their meal.

Originator: Vello

Fit Criterion: After placing an order the user can see the current status of his/her meal.





Version: 1.0

3.4.2.7 Meal selection


Event / use case #:

Description: User should be able to view meals offered by restaurant


Originator: Vello

Fit Criterion: After selecting a restaurant the user is presented a list of available meals ready for ordering.





Version: 1.0

34

3.4.3 Table reservation

3.4.3.1 View available tables


Event / use case #:

Description: User should be able to browse through list of free tables for selected date and time slot


Originator: Yevhen

Fit Criterion: After authorization, user can access a page where his data can be edited





Version: 1.0

3.4.3.2 Book a table


Event / use case #:

Description: User should be able to book a free table on selected time slot

Rationale: That is of the main purposes of the app

Originator: Yevhen

Fit Criterion: After restorant is selected, user can access page where he can select table, date, time slot and book a table. After booking the table should be marked as reserved in the system for selected time slot.




35


Version: 1.0

3.4.3.3 Cancel reservation


Event / use case #:

Description: Registered user should be able to cancel his table reservation

Rationale: Helps user to manage his reservations by himself. Decreased amount of ignored (or skipped) by user reservations

Originator: Yevhen

Fit Criterion: After successful reservation, user can access page with his reservations and cancel reservation there





Version: 1.0

3.4.3.4 Send confirmation of table reservation


Event / use case #:

Description: System should send table reservation confirmation letter to user

Rationale: Helps user to access information about his reservation. Satisfies user

Originator: Yevhen

Fit Criterion: After tabel was booked, system sends e-mail to user with details about reservation



36



Version: 1.0

3.4.3.5 View active reservations


Event / use case #:

Description: Registered user should be able to browse through his active table reservations

Rationale: Helps to manage his reservations. Increases user’s satisfaction

Originator: Yevhen

Fit Criterion: After authorization, user can access page with list of his active reservations





Version: 1.0

3.4.3.6 Reservation limit


Event / use case #:

Description: System should restrict user from reservating more than 5 time slots at the same time

Rationale: Prevents user from reserving the whole restaurant, decreasing it’s income

Originator: Yevhen

Fit Criterion: On reservation user is alerted in case he already has 5 reservations


37




Version: 1.0

3.5 Non-functional requirements

3.5.1 Supported operating systems

Requirement #: N1 Requirement type: Portability

Event / use case #:

Description: System supports the following operating systems: Android, iOS

Rationale: As it is critical to have easy access to the system, it is vital to develop the app for devices with the highest market share

Originator: Yevhen

Fit Criterion: The system can perform all basic functions on Android and iOS.


Priority: Conflicts:

Supporting Materials: Operating environment - OS version targets

History: Created 13.10.2018 Changed description 17.11.2018

Version: 1.1

3.5.2 Support multiple users simultaneously

Requirement #: N2 Requirement type: Reliability

Event / use case #:

Description: System is able to serve at least 500 users simultaneously

Rationale: If system can not serve minimal amount of customers, it will not increase the profit

Originator: Yevhen

38

Fit Criterion: 500 customers shall be able to send request and receive response without delay.





Version: 1.0

3.5.3 Supported languages

Requirement #: N3 Requirement type: Usability

Event / use case #:

Description: System supports English, German, Estonian and Russian languages

Rationale: It will be easier for the customer to order food. It increases the customer’s satisfaction.

Originator: Yevhen

Fit Criterion: User is able to switch languages.





Version: 1.0

3.5.4 Protection from third parties

Requirement #: N4 Requirement type: Security

Event / use case #:

Description: All user's personal information is protected from access by third parties.

Rationale: According to customer’s information protection policy.

39

Originator: Yevhen

Fit Criterion: People without authority cannot access the user’s personal information.





Version: 1.0

3.5.5 Maintenance complexity

Requirement #: N5 Requirement type: Maintainability

Event / use case #:

Description: A software developer with 1 or more years of experience must be able to fix any defect that occured in the system within 1 working day.

Rationale: System’s code must be delivered from complex errors which could take a lot of time to fix

Originator: Yevhen

Fit Criterion: The system has clear structure and the code must be written according to coding standards.





Version: 1.0

3.5.6 Shadow maintenance

Requirement #: N6 Requirement type: Maintainability

Event / use case #:

40

Description: System is able to perform functions while it is under maintenance.

Rationale: Increases customer satisfaction.

Originator: Yevhen

Fit Criterion: The system has a structure that allows to make changes to separate modules(parts of the code) and is able to process user requests at the same time.





Version: 1.0

3.5.7 System uptime

Requirement #: N7 Requirement type: Reliability

Event / use case #:

Description: System is available 99.95% of time in year.

Rationale: The more system works, the more customers can be served by the system. Increases customer satisfaction.

Originator: Yevhen

Fit Criterion: System must process requests regardless of the time when they were received.





Version: 2.1

41

3.5.8 Response time

Requirement #: N8 Requirement type: Performance

Event / use case #:

Description: In average, the time spent by the system to process user requests must not exceed 1 second.

Rationale: If failed, user may be dissatisfied and go to the competitors.

Originator: Yevhen

Fit Criterion: After 1000 random requests were done, average time spent on waiting for response should not exceed 1 second.





Version: 2.1

3.5.9 Port to windows mobile

Requirement #: N9 Requirement type: Portability

Event / use case #:

Description: It is possible to port the system to Windows Mobile within less than 3 month by having a team of 4 members.

Rationale: There are plans for moving the system to Windows Mobile platform.

Originator: Yevhen

Fit Criterion: The system must be ported to Windows Mobile within 3 month or less with a team of (no more than) 4 people.




42


Version: 2.1

3.5.10 Installation of the system

Requirement #: N10 Requirement type: Usability

Event / use case #:

Description: User can install and operate the program without any kind of assistance.

Rationale: Users must be able to install the application by themselves.

Originator: Yevhen

Fit Criterion: Application successfully installed by 7 y.o. kid and 50 y.o. granny.





Version: 1.0

43

3.6 Prioritization & traceability

Req. ID

Description Value Cost Priority Origin Connected Req.

Functional Requirements

Set 1 (Common)

1 User should be able to fill in contact information

26% 12% High S2

2 User should be able to choose his/her current city

3% 6% Medium S2 [Precondition_for]: 4

4 User should be able to search for a specific restaurant

10% 5% High S1,S3 [Precondition_for]: 3

11 Guest should be able to register in the system

25% 29% Medium S2 [Satisfies]:1 [Precondition_for]: 12, 13, 9, 16, 18

12 Registered user should be able to view history of his orders

4% 15% Low S4, S2 [Precondition]: 11

13 Registered user should be able to edit his information

20% 25% Medium S2 [Precondition]: 11 [Compulsion_from]: 11

20 System should provide 3 step tutorial of how to make orders and book tables through the app

12% 8% Medium S5

Set 2 (Ordering)

3 User should be able to choose a restaurant where he/she wants to order from

8% 4% Medium S1 [Precondition]: 4 [Precondition_for]: 5

5 User should be able to add meals to his/her order (only from 1 restaurant per order)

22% 10% High S1 [Precondition]: 3, 10 [Precondition_for]: 6, 7, 8

44

6 User should be able to remove meals from his/her order

18% 10% High S1 [Precondition]: 5

7 User should be able to select the order pickup time

6% 4% Medium S1,S4 [Precondition]: 5

8 User should be able to pay for order via different payment methods

20% 46% Low S1 [Precondition]: 5

9 Registered user should be able to track his/her order


10 User should be able to view meals offered by restaurant

22% 9% High S1 [Precondition]: 5

Set 3 (Table reservation)

14 User should be able to browse through list of free tables for selected date and time slot

27% 11% High S3 [Precondition_for]: 15

15 User should be able to book a free table on selected time slot

30% 14% High S3 [Precondition]: 14 [Precondition_for]: 16,17,18,19 [Compulsion_for]: 19

16 Registered user should be able to cancel his table reservation

18% 13% Medium S3, S4 [Precondition]: 11, 15

17 System should send table reservation confirmation letter to user


18 Registered user should be able to browse through his active table reservations

11% 13% Medium S3, S4 [Precondition]: 11,15

19 System should restrict user from reservating more than 5 time slots at the

10% 23% Low S3 [Precondition]: 15 [Compulsion_from]: 15

45

same time

Non-functional requirements

N1 System supports the following operating systems: Android, iOS

S1, S3 [Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 18, 19, 20

N2 System is able to serve at least 500 users simultaneously

S1, S3, S7

[Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

N3 System supports english, german, estonian and russian languages

S7 [Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

N4 All user's personal information is protected from access by third parties.

S12 [Affects]: 1, 12, 13, 8,9, 16, 18

N5 A software developer with 1 or more years of experience must be able to fix any defect that occured in the system within 1 working day.

S8, S5

N6 System is able to perform functions while it is under maintenance.

S8, S5

N7 System is able to work 23 hours per day. S8 [Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

N8 In average, time taken by the system to process user's request must not exceed 1 second.

S10 [Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 18, 20

N9 It is possible to port the system to Windows Mobile within less than 3 month by having a team of 4 members.

S11 [Affects]: 1,2,3,4,5,6,7,8,9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

46

N10 A user can install and operate the program without assistance of any kind.

S5

3.6.1 Prioritization plots

Plot 1. Prioritization of requirements in set 1

47



48

Plot 4. Prioritization of non-functional requirements

49

3.6.2 Traceability model

Traceability relations:

● Satisfies - if artefact A is realised in the system, artefact B is realised as well ● Depends - artifact A uses artifact B ● Conflicts - artifact A contradicts artifact B

3.6.3 Traceability matrix for requirements and use cases We have chosen 8 requirements and compared them with 5 use cases we have. The result of the comparison is presented in a matrix provided below.

50

Requirement Id Scenario Id

UC1 UC2 UC3 UC4 UC5

FR-1

FR-2

FR-3 Satisfies

FR-4

FR-5 Satisfies

FR-6 Satisfies

FR-7 Satisfies

FR-8 Satisfies

3.6.4 Traceability matrix for solution oriented requirements and use cases We have chosen 12 solution oriented requirements and compared them with 5 use cases we have. The result of the comparison is presented in a matrix provided below.

Solution-oriented req.

Scenario Id

UC1 UC2 UC3 UC4 UC5

21 Depends

22

23 Satisfies

24

25

26 Satisfies Depends

27

28 Depends

51

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.rjtsrr8sdyij

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.djczo91uw619

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.813q4lbbuk8t

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.5l8tgv2a1r48

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.z3yxknbs9exk

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.vtcpym625ewr

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.fxk7n3lsk9j6

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.34axmhtazlmc

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.flfot1nuxou4

29 Satisfies

30 Depends

31

32 Satisfies

33 Satisfies

3.6.5 Traceability matrix for solution oriented requirements and requirement model We have chosen 12 solution oriented requirements and compared them with 7 models we have. The result of the comparison is presented in a matrix provided below.

Solution-oriented req.

Model

Ordering class diagram

User state model

Restaurant lifecycle state model

Ordering meals state model

Meal availability state model

Invoice state model

Sequence diagram

21 Satisfies

22 Satisfies

23 Satisfies

24 Satisfies

25 Satisfies

26 Satisfies

27 Satisfies

28 Satisfies

29 Satisfies

52

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.elv5vobh5cii

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.oasdb7ynbrje

https://docs.google.com/document/d/1_0rNrLv0j0Gi14OIIj8JwJHFHi4GZHdo9Fapue3ZWr4/edit?ts=5bc13425#heading=h.bhitcdm8hgl2

30 Satisfies

31 Satisfies

32 Satisfies

33 Satisfies

53

3.7 Requirements hierarchy

54

3.8 Dependency models In Figure 3 - Social model and FIgure 4 - Technical model i* modelling language is used. The Social Model describes the case where the application is not created yet and customers have to go to the restaurant and order food there and wait in a line if required. The actors are the Customer and the Restaurant. The restaurant carries out an activity (task dependency) by providing meals to the customer and the customer should be able to order meals (task dependency) from the restaurant. The goal of the restaurant is to make profit (goal dependency) from the customers who make orders. The softgoal of the restaurant is to have loyal customers and the customer wants the quality of the meals, service, etc to be good in the restaurant (softgoal dependency).

3.8.1 Social model

Figure 3 - Social Model

55

ID Description

SM 1.1 Restaurant makes profit by having customers who make orders

SM 1.2 Customer orders meals from restaurant

SM 1.3 Restaurant has loyal customers

SM 1.4 Restaurant provides good quality for customers

SM 1.5 Restaurant provides meals to customers

3.8.2 Technical model Technical model shows the connection between actors through the system. In Figure 4 - Technical Model there are three actors: Foodify application, Customer and Restaurant. Figure 4 - Technical Model shows that Foodify depends on the customer to make profit (goal dependency) and Foodify depends on the customer to get orders (task dependency). Furthermore, there is a dependency between the customer and the restaurant as the restaurant provides meal to the customer (task dependency) and the Customer wants good quality from Restaurant and the Restaurant wants to have loyal customers (softgoal dependency). Also, the Restaurant depends on the Foodify to sell more meals (goal dependency).

Figure 4 - Technical Model

56

ID Description

TM 1.1 Customer orders meals through Foodify application

TM 1.2 Customer brings profit to Foodify

TM 2.1 Restaurant provides meals to customer

TM 2.2 Restaurant has loyal customers

SM 1.4/ TM 2.3

Restaurant provides good quality (meals, good service,etc) for customers

SM 1.5/ TM 3.1

Restaurant sells more meals through Foodify application

57

UNIVERSITY OF TARTU INSTITUTE OF COMPUTER SCIENCE

Documents

Transcript of UNIVERSITY OF TARTU INSTITUTE OF COMPUTER SCIENCE