Case Study Sizing natural language/UML requirements for ... · 1 Case Study Sizing natural...

1

Case Study Sizing natural language/UML requirements for Web and

Mobile applications using COSMIC FSM

Asma Sellami1, Mariem Haoues

1, Hanêne Ben-Abdallah

2,1, Alain Abran

3

Arlan Lesterhuis4, Charles Symons

5, Sylvie Trudel

6

1Mir@cl Laboratory, University of Sfax, Tunisia

2King Abdulaziz University, Jeddah, KSA

3Ecole de technologie supérieure - University of Québec, Montréal, Canada

[email protected], [email protected], [email protected], [email protected]

[email protected], [email protected], [email protected]

“This case study is published by COSMIC by kind permission of the authors; it has not been formally reviewed by

the Measurement Practices Committee. Readers are invited to send any comments directly to the authors.”

mailto:[email protected]



2

Table of Contents

Table of Contents .................................................................................................................................... 2

1 Restaurant Management System Requirements ............................................................................ 3

1. 1 Context ......................................................................................................................................... 3

1. 2 Hardware Components ................................................................................................................ 3

1. 3 Software-Hardware Interactions .................................................................................................. 4

1. 4 Software Requirements ................................................................................................................ 4

A. FUR - Functional User Requirements ...................................................................................... 4

C. NFR - Non-Functional Requirements ..................................................................................... 16

D. PRC - Project Requirements and Constraints ........................................................................ 17

2 MEASUREMENT STRATEGY PHASE ................................................................................................ 18

2. 1 Measurement Purpose ............................................................................................................... 18

2. 2 Measurement Scope................................................................................................................... 18

2. 3 Identification of Functional Users .............................................................................................. 18

2. 4 Other measurement strategy parameters ................................................................................. 18

A. Level of granularity ................................................................................................................ 18

B. Decomposition ...................................................................................................................... 19

3 THE MAPPING PHASE .................................................................................................................... 20

3. 1 Identification of the Software Triggering Events ........................................................................ 20

3. 2 Identification of the functional processes .................................................................................. 21

3. 3 Identification of objects of interest, data groups, and data attributes ...................................... 22

4 THE MEASUREMENT PHASE .......................................................................................................... 24

4. 1 Functional size measured from FUR - natural language............................................................. 24

A. For Mobile app ...................................................................................................................... 24

B. For web application ............................................................................................................... 26

C. For the whole system ............................................................................................................ 35

4. 2 Functional size measured from FUR - UML textual description ................................................. 35

A. Using Action-Type.................................................................................................................. 35

REFERENCE ............................................................................................................................................ 43

APPENDIX A - Structured use case documentation format Using Action-Type .................................... 44

3

1

1 RESTAURANT MANAGEMENT SYSTEM REQUIREMENTS

1. 1 Context

This Case Study presents the measurement results of applying the COSMIC-FSM method (Version

4.0.1) to the “Restaurant Management System”. This system is composed of hardware and software

components. The software component named “Resto-Sys” includes two parts: a mobile app and a web

application.

The “Restaurant Management System” requirements are documented in a technical report of the final

project of study for the Professional Master's Degree at the University of Sfax-Tunisia (Mhadhbi 2013).

This case study is structured as follows:

Chapter 1 presents the background for the “Restaurant Management System” case study. It

provides different representations of Hardware/Software requirements. The focus of this

chapter is especially on the description of the Functional User Requirements as documented

in natural language, UML use case diagrams, and the textual descriptions of use cases using

action-type (see the explanation in Appendix A).

Chapter 2 presents the measurement strategy phase, including: measurement purpose and

scope, functional users, level of granularity and decomposition.

Chapter 3 presents the mapping phase including: triggering events, functional processes, data

groups, data attributes, and objects of interest.

Chapter 4 presents the measurement phase. The measurement results are provided in two

ways:

(i) a direct application of COSMIC-FSM method on FUR described in natural language in

section 4.1; and

(ii) an application of COSMIC-FSM method on the action-type of use case actions in section

4.2.

1. 2 Hardware Components

As shown in Figure 1, the hardware configuration of “Restaurant Management System” is composed

of:

A database server allowing a high storage capacity (the interaction with the DB Server is

outside the scope of this case).

A Web server that responds to the users (waiter and-or administrator) requests to access to

the “Resto-Sys”.

A Web Client and (a) Smartphone Client(s) allowing the users to access to the “Resto-Sys”.

Figure 1 Hardware Configuration

4

1. 3 Software-Hardware Interactions

The “Resto-Sys” is composed of two parts: a mobile app and a web application:

The “Resto-Sys” ensures communication between the Smartphone client (the waiter) and the

Web client (the administrator).

The web client maintains the database (that it is included in the DB server).

The “Resto-Sys” application includes the following functionalities:

The Smartphone client receives the waiter’s username and password.

The Web server retrieves data from the DB and provides the required data to the Smartphone

client.

The Smartphone client can maintain a customer's order (by adding or modifying an order).

The Web client receives the administrator’s username and password.

The Web server retrieves data from the DB and provides the required data to the Web client.

The Web client can maintain the required data, see the FUR in section 1.4 A

1. 4 Software Requirements

According to (COSMIC 2015), software requirements are classified into three categories: Functional

User Requirements (FUR), Non-Functional Requirements (NFR), and Project Requirements and

Constraints (PRC). FUR express “what the software shall do in terms of tasks and services”. NFR

include “any requirement for a hardware/software system or for a software product, including how it

should be developed and maintained and how it should perform in operation, except any functional

user requirement for the software”. PRC describe “how a software system project should be managed

and resourced or constraints that affect its performance”.

A. FUR - Functional User Requirements

In this section, the FUR for the “Resto-Sys” are identified. First, the FUR are described in natural

language. Then, those same FUR are modeled with UML Use Case diagrams. Each use case in a

UML Use Case diagram is next detailed in textual descriptions of use cases using action-type as

presented in Appendix A.

a. FUR expressed in natural language

The “Resto-Sys” includes the following tasks:

Order management: This task allows the waiter to add, and-or modify an order via his Smartphone. It also allows the administrator to delete an order. During working hours, the waiters (Smartphone) and the administrator (web client) are continuously connected.

Account management: This task involves users’ management, and it enables access to the application with a username and a password.

Menu Items management: This task allows the management of item families and the classification of items into item families.

The “Resto-Sys” involving Mobile app must establish the following functionalities:

FUR 1- Logon: the waiter must be logged on to the web application using his Smartphone. Each waiter has a username and a password.

FUR 2 - Maintain Order: the waiter can add and-or modify an order. He takes an order by selecting the customer’s place, the table where he is installed, and the chosen items. Each customer is installed at a table and can request a set of items such as: fruit salad, orange juice, etc.

The “Resto-Sys” involving Web application must establish the following functionalities:

FUR 3 - Logon: The administrator must be logged on to access the web application using a username and a password.

FUR4 - Maintain User: The administrator can add a user (waiter). He/she can view and-or modify a user (waiter) data. He/She can delete an existing user and-or view the users list.

5

FUR5 - Maintain Item: The administrator can add a new item by entering the necessary data for an item. He/She can also view, modify an item. He/She can delete an existing item and view the items list. Each item is classified into a single item family.

FUR6 - Maintain Item family: The administrator can add a new item family by entering the required data. He/She may also view and-or modify an item family data. He/she can delete an existing item family, and view the list of existing item families. Examples of item family: juice, salad, soda, etc.

FUR 7 - Maintain Place: The restaurant consists of a set of places defined by a limited area in the restaurant (terrace, non-smoking room, etc.). The administrator can add a new place. He/She may also view and-or modify a place data. He/She can delete an existing place, and view the list of existing places.

FUR 8 - Maintain Table: The administrator can add a new table. He/She may also view and-or modify a specific table data. He/She can delete an existing table and view the table list to know the table state (unoccupied, occupied or reserved). Each table is installed in a specific place.

FUR 9 -Maintain menu items: The administrator can add new menu items. He/she may also view and-or modify a menu items data. He/she can delete an existing menu items and view the menu items list. For example: Chinese food, dessert, etc.

FUR 10: Manage the List of Orders: The administrator can view the list of orders and may delete a customer’s order.

These functionalities will be detailed in the following sections using UML use case diagrams.

B. FUR expressed in UML Use case diagram

Identification of Actors. Users of the “Resto-Sys” are the administrator and the waiter.

Administrator: is the manager of the application. He/She can manage the entire “Resto-Sys”

and specify users’ rights. The administrator can access to the web application via his

username and his password.

Waiter: is responsible for customers' orders. He/She can access to the mobile app via his

Smartphone and using his username and his password.

Identification of Use Cases. Based on the FUR listed in section A) a., Table 1 Fout! Verwijzingsbron

niet gevonden.lists the identified Use Cases.

Table 1 Use cases Identification

Actor Global Use Cases Detailed Use Cases

Waiter Logon FUR 1: Logon

Maintain Order FUR 2: Maintain Order

Administrator

Logon FUR 3: Logon

Maintain Data

FUR 4: Maintain User

FUR 5: Maintain Item

FUR 6: Maintain Item family

FUR 7: Maintain Place

FUR 8: Maintain Table

FUR 9: Maintain Menu Items

Maintain Order FUR 10: Manage the List of Orders

The global use case diagram, as presented in Figure 2, identifies the main functionalities provided by

the system “Resto-Sys”. Thus, the administrator and the waiter must be logged on before maintaining

data and orders. Each use case identified in the global use case diagram can include one or more use

cases. As an example, the use case “Maintain Data” in the global use case diagram is detailed using

six use cases: “Maintain User”, “Maintain Item”, “Maintain Item family”, “Maintain Place”, “Maintain

Table”, and “Maintain Menu Items”. The use case “Maintain Order” for “Administrator” actor is also

detailed using “Manage the List of Orders” (Figure 3).

6

Figure 2 Global Use Case Diagram

Figure 3 Detailed Use Case Diagram for “Maintain Data” and “Maintain Order” use cases

Use Cases Textual Descriptions. Each detailed use case identified in Table 1 is represented using a use case textual description (see Appendix A). Note that a use case textual description represents a discrete unit of interaction between the system “Resto-Sys” (mobile and web applications) and its users (Waiter and Administrator).

FUR 1 Use case “Logon” mobile app

7

Name: <Logon>

Description: <This use case describes how the Waiter logs into the web application>

Actors: <Primary actor: Waiter>

Begin

MS /* Main scenario */ 1. <Waiter><Expletive><The Waiter requests for a connection to the web

application using his Smartphone> 2. <System><Expletive><The mobile app asks the Waiter to enter his username

and password> 3. <Waiter><Request><The waiter enters his username and password using his

Smartphone> [<Waiter ID>] 4. <System><Response & Request & Request ><The web application checks the

validity of username and password> [<Waiter ID>] [<Log status>] [<Log status>] /*If the username and password are valid, the waiter is connected*/

End

ES /* Error scenario */

Begin <Username and password are incorrect, begin at Num '4'> 5. <System><Response><The mobile app displays the message “the username

and the password are invalid.”> End

End use case

FUR 2: Use case “Maintain Order”

Name: <Maintain Order> Description: <This use case allows the waiter to add or modify a customer's order> Actors: <Primary actor: Waiter>

Begin

MS /* Main Scenario */ Add an Order

Begin

1. <System><Expletive><when the waiter logged on, the list of restaurant options is displayed>.

2. <Waiter><Request><The waiter presses the option “Add a new order”>[<Order Data>].

3. <System><Response & Request><The system displays the list of places> [Place Data> & <Place Data>].

4. <Waiter><Request & Response><The waiter chooses the place where the customer is installed> [<Place ID> & <Place ID>].

5. <System>< Request & Response ><The system displays the list of tables> [<Table Data> & <Table Data>].

6. <Waiter><Request& Response><The waiter chooses the table where the customer is installed> [<Table ID> & <Table ID>].

7. <System>< Request & Response><The system checks if there is any active order for the selected table and changes the order state from active to closed> [<Table ID> & <Table ID>].

8. <System><Request & Response><The system displays the list of item families> [<Item family data> & <Item family data>].

9. <Waiter><Request & Response><The waiter chooses the item families based on the items requested by the customer> [<Item family ID> & <Item family ID>].

10. <System><Request & Response><The system displays the list of items according to the selected Item families> [<Item Data> & <Item Data>].

11. <Waiter><Request & Response><The waiter selects the items requested by the customer and specify for each item the recommended quantity and customer's comment> [<Order Items>] [<Order Items>].

12. <System><Request><The system creates the new order> [<Order Data>]. End

AS /*Alternative Scenario*/

8

Modify an Order

Begin

1. <System><Expletive><when the waiter logged on, the list of restaurant options is displayed>.

2. <Waiter><Request><The waiter presses the option “Modify an order”>[<Order Data>].

3. <System><Response & Request><The system displays the list of places> [Place Data>&<Place Data>].

4. <Waiter><Request & Response><The waiter chooses the place where the customer is installed> [<Place ID>&<Place ID>].

5. <System>< Request & Response ><The system displays the list of tables > [Table Data>&<Table Data>].

6. <Waiter><Request & Response><The waiter chooses the table where the customer is installed> [<Table ID>&<Table ID>].

7. <System><Request & Response><The system displays the list of items recommended by the customer with their quantities and comments> [<Order Items>&<Order Items>].

8. <Waiter><Request & Response><The waiter adds/deletes the new/existing item, modifies items' quantities or modifies items' comments> [<Order Items>&<Order Items>].

9. <System><Request><The system updates the order data> [<Order Data>]. End

ES /* Error Scenario */ Begin<Orders list is empty, begin at Num '2' in the alternative scenario>

2.1 <System><Response><The system displays the message “Orders list is empty”> /* The scenario restarts at point 1. */ End

End use case

FUR 3: Use case “Logon” web application

Name: <Logon>

Description: <This use case describes how the Administrator logs into the system>

Actors: <Primary actor: Administrator>

Begin

MS /* Main scenario */ 1. <Administrator><Expletive><The Administrator requests for a connection to the

system> 2. <System><Expletive><The system asks the Administrator to enter his username

and password> 3. <Administrator><Request><The Administrator introduces his username and

password> [<Administrator ID>] 4. <System><DataRecovery><The system checks the validity of username and

password> [<Administrator ID>] /*If the username and password are valid, the Administrator is connected*/

End

ES /* Error scenario */

Begin <Username and password are incorrect, begin at Num '4'> 5. <System><Response><The system displays the message “the username and

the password are invalid.”> End

End use case

FUR 4: Use case “Maintain User”

Name: <Maintain User >

Description: <This use case allows users update>


Begin

9

MS /* Main Scenario*/

Add a User

1. <Administrator><Expletive><The administrator requests to add a new user>. 2. <System><Expletive><The system displays the user form and requires the

administrator to enter the necessary data for adding a user>. 3. <Administrator><Request><The administrator enters the user data> [<Waiter

Data>]. 4. <System><Expletive><The system checks that all required data are entered

correctly>. 5. <System><DataPersist><The system adds the new user> [<Waiter Data>].

AS /* Alternative Scenario */

View User Data

1. <Administrator><Request><The administrator selects to view the list of waiters> [<Waiter Data>].

2. <System><DataRecovery><The system retrieves the list of users> [<Waiter Data>].

3. <System><Response><The system displays the list of users> [<Waiter Data>]. 4. <Administrator><Request><The administrator selects the desired user> [<Waiter

ID>]. 5. <System><DataRecovery><The system retrieves user data from the Database>

[<Waiter Data>]. 6. <System><Response><The system displays the data of the selected user>

[<Waiter Data>].

Modify User Data



3. <System><Response><The system displays the list of users> [<Waiter Data>]. 4. <Administrator><Request><The administrator chooses the user to be modified>

[<Waiter ID>]. 5. <System><DataRecovery><The system retrieves user data from Database>

[<Waiter Data>] 6. <Administrator><Response><The system displays user data> [<Waiter Data>]. 7. <Administrator><Request><The administrator modifies user data that can be

changed> [<Waiter Data>]. 8. <System><DataPersist><The system save the change> [<Waiter Data>].

Delete a User



3. <System><Response><The system displays the list of users> [<Waiter Data>]. 4. <Administrator><Request><The administrator chooses the user to be deleted>

[<Waiter ID>]. 5. <System><DataPersist><The system deletes the selected user> [<Waiter ID>].

ES /* Error Scenario */

Begin<User already exists, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “User already exists”> /* The scenario restarts at point 2. */ End

Begin<The users list is empty, begin at Num '3' in the alternative scenario 'View User Data'>

3.1<System><Response><The system displays the message “The users list is empty”>

/* The scenario restarts at point 1. */

10

End

Begin<The users list is empty, begin at Num '3' in the alternative scenario “Delete a User”>

3.1<System><Response><The system displays the message “The users list is empty”>


End

End use case

FUR 5: Use case “Maintain item”

Name: <Maintain item>

Description: <This use case allows the administrator to add, modify, view and delete an

item>


Begin

MS /* Main Scenario */

Add an Item

1. <Administrator><Expletive><The administrator asks for adding a new item>. 2. <System><Expletive><The system displays the item form and asks the

administrator to enter the necessary data for adding an item>. 3. <Administrator><Request><The administrator enters the data of the item and

instructs the system to validate the addition> [<Item Data>]. 4. <System><Expletive><The system checks that all required data are entered

correctly>. 5. <System><DataPersist><The system adds the new item> [<Item Data>].


View Item Data

1. <Administrator><Request><The administrator selects to view the items’ list> [<Item Data>].

2. <System><DataRecovery><The system retrieves the list of items> [<Item Data>].

3. <System><Response><The system displays the list of items> [<Item Data>]. 4. <Administrator><Request><The administrator selects the desired item> [<Item

ID>]. 5. <System><DataRecovery><The system retrieves the item data from the

Database> [<Item Data>]. 6. <System><Response><The system displays the selected item data> [<Item

Data>].

Modify an Item

1. <Administrator><Request><The administrator selects to view the items’ list> [<Item Data>].


3. <System><Response><The system displays the list of items> [<Item Data>]. 4. <Administrator><Request><The administrator selects the item to be modified>

[<Item ID>]. 5. <System><DataRecovery><The system retrieves the item data from the

Database> [<Item Data>]. 6. <System><Response><The system displays the data of the selected item to the

administrator> [<Item Data>]. 7. <Administrator><Request><The administrator modifies the desired fields (name,

price, quantity, image, etc.) and asks the system to update the data of the selected item> [<Item Data>].

8. <System><DataPersist><The system saves the change> [<Item Data>].

Delete an Item

11

1. <<Administrator><Request><The administrator selects to view the items’ list> [<Item Data>]


3. <System><Response><The system displays the list of items> [<Item Data>]. 4. < Administrator><Request><The administrator selects the item to be deleted>

[<Item ID>]. 5. <System><DataPersist><The system deletes the selected item> [<Item ID>].


Begin<Item already exists, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “Item already exists”> /* The scenario restarts at point 2. */ End

Begin<The items list is empty, begin at Num '2' in the alternative scenario 'View Item data'>

2.1 <System><Response><The system displays the message “The items list is empty”>

/* The scenario restarts at point 1. */ End

End use case

FUR 6: Use case “Maintain Item Family”

Name: <Maintain Item Family>

Description: <This use case allows the administrator to add, modify, view and delete an

item family>


Begin MS /* Main Scenario */

Add an Item Family

1. <Administrator><Expletive><The administrator requests for adding a new item family>.

2. <System><Expletive><The system displays the item family form and asks the administrator to enter the necessary data for adding an item family>.

3. <Administrator><Request><The administrator enters the data of the item and instructs the system to validate the addition> [<Item Family Data>].

4. <System><Expletive><The system checks that all required data are entered correctly>.

5. <System><DataPersist><The system adds the new item family> [<Item Family Data>].


View Item Family Data

1. <Administrator><Request><The administrator selects to view the item families’ list> [<Item Families Data>].

2. <System><DataRecovery><The system retrieves the item families list> [<Item Family Data>].

3. <System><Response><The system displays the item families list> [<Item Family Data>].

4. <Administrator><Request><The administrator selects the desired item family> [<Item family ID>].

5. <System><DataRecovery><The system retrieves the item family data from the Database> [<Item family Data>].

6. <System><Response><The system displays the selected Item family data to the administrator> [<Item family Data>].

Modify an Item Family


12



4. <Administrator><Request><The administrator selects the item family to be modified> [<Item family ID>].

5. <System><DataRecovery><The system retrieves the item family data from the Database> [<Item family Data>].

6. <System><Response><The system displays the modification interface> [<Item family Data>].

7. <Administrator><Request><The administrator modifies the desired fields and instructs the system to update the item family data>[<Item family Data>].

8. <System><DataPersist><The system saves the change> [<Item family Data>].

Delete an Item Family




4. <Administrator><Request><The administrator selects the item family to be deleted> [<Item family ID>].

5. <System><DataPersist><The system deletes the selected item family> [<Item family ID>].


Begin<Item Family already exists, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “Item family already exist”>


Begin<Item families list is empty, begin at Num '3' in the alternative scenario 'View Item family data>

3.1<System><Response><The system displays the message “Item families list is empty”>


End

End use case

FUR 7: Use case Maintain place

Name: <Maintain place>

Description: <This use case is used to add, view, modify and delete a place>


Begin

MS /* Main scenario */

Add a Place

1. <Administrator><Expletive><The administrator requests for adding a new place>. 2. <System><Expletive><The system displays the place form and asks the

administrator to enter the necessary data for a place>. 3. <Administrator><Request><The administrator enters the place data> [<Place


correctly>. 5. <System><DataPersist><The system adds the new place> [<Place Data>].

13


View a Place Data

1. <Administrator><Request><The administrator selects to view the places list> [<Place Data>].

2. <System><DataRecovery><The system retrieves the places list> [<Place Data>]. 3. <System><Response><The system displays the places list > [<Place Data>]. 4. <Administrator><Request><The administrator selects the desired place> [<Place

ID>]. 5. <System><DataRecovery><The system retrieves the Place data from the

Database> [<Place Data>]. 6. <System><Response><The system displays the data of the selected place to the

Administrator> [<Place Data>].

Modify a Place

1. <Administrator><Request><The administrator selects to view the places list> [<Place Data>]

2. <System><DataRecovery><The system retrieves the list of places> [<Place Data>].

3. <System><Response><The system displays the list of places> [<Place Data>]. 4. <Administrator><Request><The administrator chooses the place to be modified>

[<Place ID>]. 5. <System><DataRecovery><The system retrieves the place data from the

Database> [<Place data>]. 6. <System><Response><The system displays the data of the selected Place to

the administrator> [<Place Data>]. 7. <Administrator><Request><The administrator modifies the place data> [<Place

Data>]. 8. <System><DataPersist><The system saves the change> [<Place Data>].

Delete a Place

1. <Administrator><Request><The administrator selects to view the places list> [<Place Data>].

2. <System><DataRecovery><The system retrieves the list of places> [<place Data>].

3. <System><Response><The system displays the list of places> [<Place Data>]. 4. <Administrator><Request><The administrator chooses the place to be deleted>

[<Place ID>]. 5. <System><DataPersist><The system deletes the selected place> [<Place ID>].


Begin<Place already exist, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “Place already exists”>


Begin<Places list is empty, begin at Num '2' in the alternative scenario “View a place data”>

2.1 <System><Response><The system displays the message “Places list is empty”>


End use case

FUR 8: Use case “Maintain Table”

Name: <Maintain Table>

Description: <This use case allows the administrator to add, view, modify and delete a

table>


Begin MS /* Main Scenario */

14

Add a Table

1. <Administrator><Expletive><The administrator requests to add a new table>. 2. <System><Expletive><The system displays the table form and asks the

administrator to enter the necessary data for adding a table>. 3. <Administrator><Request><The administrator enters all the table data> [<Table


correctly>. 5. <System><DataPersist><The system adds the new table> [<Table Data>].


View Table Data

1. <Administrator><Request><The administrator selects to view the tables list> [<Table Data>].

2. <System><DataRecovery><The system retrieves the tables list> [<Table Data>]. 3. <System><Response><The system displays the tables list > [<Table Data>]. 4. <Administrator><Request><The administrator selects the desired table> [<Table

ID>]. 5. <System><DataRecovery><The system retrieves the Table Data from the

Database> [<Table ID>]. 6. <System><Response><The system displays the data of the selected table to the

administrator> [<Table Data>]. Modify Table Data


2. <System><DataRecovery><The system retrieves the tables list> [<Table Data>]. 3. <System><Response><The system displays the tables list > [<Table Data>]. 4. <Administrator><Request><The administrator chooses the table> [<Table ID>]. 5. <System><DataRecovery><The system retrieves the Table data from the Data

base> [<Table Data>]. 6. <System><Response><The system displays the data of the selected table to the

administrator> [<Table Data>]. 7. <Administrator><Request><The administrator modifies the table data> [<Table

Data>]. 8. <System><DataPersist><The system saves the change> [<Table Data>].

Delete a Table


2. <System><DataRecovery><The system retrieves the tables list> [<Table Data>]. 3. <System><Response><The system displays the tables list > [<Table Data>]. 4. <Administrator><Request><The administrator chooses the table to be deleted>

[<Table ID>]. 5. <System><DataPersist><The system deletes the selected table> [<Table ID>].


Begin<Table already exists, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “Table already exists”> /* The scenario restarts at point 3. */ End

Begin<Tables list is empty, begin at Num '3' in the alternative scenario 'View Table Data>

3.1<System><Response><The system displays the message “Tables list is empty”>


Begin<Tables list is empty, begin at Num '3' in the alternative scenario 'Delete a Table>

3.1<System><Response><The system displays the message “Tables list is empty”>

15


End use case

FUR 9: Use case “Maintain Menu Items”

Name: <Maintain Menu Items>

Description: <This use case allows the administrator to maintain a menu items>


Begin


Add a Menu Items

1. <Administrator><Expletive><The administrator requests to add a new menu items>.

2. <System><Expletive><The system displays the menu items form and asks the administrator to enter the necessary data for adding a menu items>.

3. <Administrator><Request><The administrator enters the menu items data> [<Menu Items Data>].

4. <System><Expletive><The system checks that all required data are entered correctly>.

5. <System><DataPersist><The system adds the new menu items > [<Menu Items Data>].


View a Menu Items Data

1. <Administrator><Request><The administrator selects to view the menu items list option> [<Menu Item Data>].

2. <System><DataRecovery><The system retrieves the menu items’ list> [<Menu Items Data>].

3. <System><Response><The system displays the menu items’ list > [<Menu Items Data>].

4. <Administrator><Request><The administrator selects the desired menu items> [<Menu Items ID>].

5. <System><DataRecovery><The system retrieves the menu items data from the Database> [<Menu Items ID>].

6. <System><Response><The system displays the data of the selected menu items to the administrator> [<Menu Items Data>].

Modify a Menu Items




4. <Administrator><Request><The administrator selects the desired menu items> [<Menu Items ID>].

5. <System><DataRecovery><The system retrieves the menu items data from the Database> [<Menu Items data>].

6. <System><Response><The system displays the data of the selected menu items to the administrator> [<Menu Items Data>].

7. <Administrator><Request><The administrator modifies the menu items data that can be changed> [<Menu Items Data>].

8. <System><DataPersist><The system saves the change> [<Menu Items Data>]. Delete a Menu Items


16



4. <Administrator><Request><The administrator selects the desired menu items > [<Menu Items ID>].

5. <System><DataPersist><The system deletes the menu items > [<Menu Items ID>].


Begin<Menu items already exist, begin at Num '5' in the main scenario>

5.1 <System><Response><The system displays the message “Menu items already exist”>


Begin<The Menu items list is empty, begin at Num '3' in the alternative scenario 'View Menu Items Data>

3.1<System><Response><The system displays the message “The Menu items list is empty”>


Begin<The Menu items list is empty, begin at Num '3' in the alternative scenario “Delete a Menu items”>

3.1<System><Response><The system displays the message “The Menu items list is empty”>


End use case

FUR 10: Use case “Manage the List of Orders”

Name: <Manage the List of Orders>

Description: <This use case allows to view the list of orders and delete a customer’s

order>

Actors: <Primary actor: Administrator> Begin


View the List of Orders

1. <Administrator><Request><The administrator selects to view the orders list> [<Order Data>].

2. <System><DataRecovery><The system retrieves the orders list> [<Order Data>].

3. <System><Response><The system displays the orders list> [<Order Data>]. AS /* Alternative Scenario */

Delete an Order

4. <Administrator><Request><The administrator selects the order to be deleted from the orders list> [<Order ID>].

5. <System><DataPersist><The system deletes the order> [<Order ID>].


Begin<Orders list is empty, begin at Num '3' in the main scenario>

3.1 <System><Response><The system displays the message “Orders list is empty”>


End

17

C. NFR - Non-Functional Requirements

Non-functional requirements define some quality requirements such as: performance, usability and security. The mobile app interface must be easy to use, simple and clear. Moreover, the web application must be compatible with any operating system, easy to use, understandable; with a “good response time”. It is also evident that “Resto-Sys” (including web and mobile applications) requires the presence of an internet connection.

D. PRC - Project Requirements and Constraints

The PRC address types of constraints surrounding the software development project, such as the competing demands of time, cost, and scope limitations on the project resources needed; dependencies on other projects, data storage space, etc.

18

2

2 MEASUREMENT STRATEGY PHASE

2. 1 Measurement Purpose

The purpose of the measurement is to determine the size of the “Resto-Sys” software on the basis of

its Functional User Requirements, as specified in Chapter 1 of this case study, and then estimate the

development efforts for the mobile app and the web application separately.

2. 2 Measurement Scope

The scope is all functionality as specified in the Functional User Requirements for the software as

described in section 1.4 A, the interaction with the DB Server is outside the scope. The “Resto-Sys”

software is in the application layer. The FUR specify decomposition of its software in a mobile app

component and a web application component.

2. 3 Identification of Functional Users

The human functional users of the “Resto-Sys” are the administrator and the waiter.

The Administrator: is the manager of the application. He is entitled to manage the entire

“Resto-Sys” and specify users and their individual rights.

The Waiter: is responsible for adding or modifying the customers’ orders.

Note. As the interaction with the DB Server is outside the scope of this case the DB Server is not

an actor of “Resto-Sys”, rather it is the physical implementation of the web application’s persistent

storage.

Figure 4 presents the contextual diagram for the “Resto-Sys” showing all its functional users.

Web

application

Mobile

app

Functional User

(Waiter)

Functional User

(Administrator)

E

E X

E

PersistentStorage

X

X E

X

W R

Figure 4 Contextual diagram

2. 4 Other measurement strategy parameters

A. Level of granularity

The FUR of the “Resto-Sys” are at two levels of granularity. The first level of granularity is that of the

Use Case global diagram (Figure 2). At this level, the data movements cannot be observed. For such

19

cases, a COSMIC approximation method can be applied (COSMIC 2015b). However, since each use

case identified in the first level can be detailed in the second level (such as Maintain Data which is

detailed in Figure 3), the required level to apply COSMIC is where use cases are detailed using their

textual description. More specifically, actions in a use case can be associated with the COSMIC data

movement, as their level of granularity is the standard level, the ‘functional process level of

granularity’..

B. Decomposition

Figure 5 presents the decomposition for the “Resto-Sys”. The mobile app interacts with the Web

server via eXit/Entry data movement. The web server can require data to be stored or retrieved to/from

persistent storage. Here, the architecture used to implement this system is 2-tier architecture. The two

major components are: the Mobile app and the Web Server.

Mobile App Web Server

E X

EX

Figure 5 Decomposition

20

3

3 THE MAPPING PHASE

3. 1 Identification of the Software Triggering Events

From the FUR, the following triggering events are identified. For each functional process, there is only

one triggering event (see Table 2).

Table 2 Triggering Event Identification

FUR Functional Processes Triggering Events

FUR 1: Logon FP 1: Logon The waiter access to the logon form

FUR 2: Maintain Order

FP 2: Add an Order The waiter adds a new order

FP 3: Modify an Order The waiter modifies an order

FUR 3: Logon FP 4: Logon The administrator access to the logon form


FP 5: Add a User The administrator adds a user

FP 6: View Users List The administrator asks for the users list

FP 7: View a User data The administrator asks for a user data

FP 8: Modify User Data The administrator modifies a user data

FP 9: Delete a User The administrator deletes a user


FP 10: Add an Item The administrator adds a new item

FP 11: View Items List The administrator views the items list

FP 12: View an Item Data The administrator views the item data

FP 13: Modify an Item The administrator modifies an item

FP 14: Delete an Item The administrator deletes an item

FUR 6: Maintain Item Family

FP 15: Add an Item Family The administrator adds a new item family

FP 16: View Item Families List The administrator views the item families list

FP 17: View an Item Family Data

The administrator views an item family data

FP 18: Modify an Item Family The administrator modifies an item family

FP 19: Delete an Item Family The administrator deletes an item family


FP 20: Add a Place The administrator adds a place

FP 21: View Places List The administrator views the places list

FP 22: View a Place Data The administrator views a place data

FP 23: Modify a Place The administrator modifies a place

FP 24: Delete a Place The administrator deletes a place


FP 25: Add a Table The administrator adds a table

FP 26: View Tables List The administrator views the tables list

FP 27: View a Table Data The administrator views a table Data

FP 28: Modify Table Data The administrator modifies a table data

FP 29: Delete a Table The administrator deletes a table


FP 30: Add a Menu Items The administrator adds a Menu Items

FP 31: View Menu Items List The administrator views the Menu Items list

FP 32: View a Menu Items Data The administrator views a Menu Items data

FP 33: Modify a Menu Items The administrator modifies a Menu Items

FP 34: Delete a Menu Items The administrator deletes a Menu Items

FUR 10: Manage the List of Orders

FP 35: View the List of Orders The administrator views the list of orders

FP 36: Delete an Order The administrator deletes an order

21

3. 2 Identification of the functional processes

From the FUR, the following functional processes are identified (see Table 3).

Table 3 Functional Processes Identification

FUR Functional Processes

FUR 1: Logon FP 1: Logon

FUR 2:Maintain Order FP 2: Add an Order FP 3: Modify an Order

FUR 3: Logon FP4: Logon


FP 5: Add a User FP 6: View Users List FP 7: View a User Data FP 8: Modify User Data FP 9: Delete a User


FP 10: Add an Item FP 11: View Items List FP 12: View an Item Data FP 13: Modify an Item FP 14: Delete an Item

FUR 6: Maintain Item Family

FP 15: Add an Item Family FP 16: View Item Families list FP 17: View an Item Family Data FP 18: Modify an Item Family FP 19: Delete an Item Family


FP 20: Add a Place FP 21: View a Places List FP 22: View a Place Data FP 23: Modify a Place FP 24: Delete a Place


FP 25: Add a Table

FP 26: View Tables List

FP 27: View a Table Data

FP 28: Modify Table Data

FP 29: Delete a Table


FP 30: Add a Menu Items

FP 31: View Menu Items List

FP 32: View a Menu Items Data

FP 33: Modify a Menu Items

FP 34: Delete a Menu Items

FUR 10: Manage the List of Orders FP 35: View the List of Orders

FP 36: Delete an Order

22

3. 3 Identification of objects of interest, data groups, and data attributes

From the FUR, 10 objects of interest are identified. These are listed in Table 4 with their data groups

and data attributes.

Table 4 List of Objects of Interest, Data Groups, and Data attributes

FUR Objects of Interest

Data Groups Data attributes Example

FUR 1 FUR 4

Waiter

Waiter Data username, password, name, phone_number, address, userstate

username: alx84 password: 123 name: Alex phone_number: 22234567 address: Sfax, Tunisia

Log status userstate userstate: connected

Waiter ID username, password username: Alx84 password: 123

FUR 3

Administrator

Administrator Data username, password, name, phone_number, address, userstate

username: adm84 password: 456 name: Bill phone_number: 59875444 address: Sfax, Tunisia

Administrator ID username, password username: adm84 password: 456

Log status userstate userstate: connected

FUR 8

Table Table Data

table number, place number, state, capacity

table number: 1 place number: 1 state: occupied capacity: 2

Table ID table number table number: 1

FUR 6

Item family Item family Data

item family number, menu items number designation

item family number: 1 designation: Juice menu items number: 1

item family number: 2 designation: soda menu items number:1

Item family ID item family number item family number: 1

FUR 5

Item Item Data

item number, item family number designation, image, price, quantity

item number: 1 item family number: 1 designation: orange juice image: orange.jpg price: 1 D quantity: 30

item number: 2 item family number: 2 designation: coca cola image: coca.jpg price: 2 D quantity: 100

Item ID item number item number: 1

FUR 7

Place Place Data place number, name

place number: 1 name: non-smoking

Place ID place number place number: 1

FUR 2 FUR 10

Order

Order ID order number, order number: 20

Order Data

order number, table number, order status, date, time,

order number: 20 table number: 1 order status: active date: 05/07/2016 time: 8:00 pm

23

name name: Alex

Order Items

order number, item number, quantity, comment

order number: 20 item number: 1 quantity: 3 comment: none item number: 2 quantity: 1 comment: with ice

FUR 9 Menu Items

Menu Items ID menu items number menu items number: 1

Menu Items Data menu items number, description

menu items number: 1 description: dessert

From FUR 1 to FUR 10

Messages E/C message Message description Message description: “Orders list is empty”

24

4

4 THE MEASUREMENT PHASE

4. 1 Functional size measured from FUR - natural language

A. For Mobile app

The mobile app includes the functional processes (FP1, FP2, and FP 3). In this section, we give a detailed measurement of the functional size of the mobile app.

FP1: Logon Triggering event: The waiter access to the logon form

Functional User

Sub-Process Description Data Group

Objects of

interest

Data Movement

Type

CFP

Waiter Enter username and

password Waiter ID Waiter E 1

Provide actor data to the web

application Waiter ID Waiter X 1

Receive log status

(Connected)

Log status

(Connected) Waiter E 1

The mobile app log status

(Not connected)

Log status

(Not connected) Waiter E 1

Waiter

The mobile app displays

Error/Confirmation messages

from the web application

E/C Message Messages X 1

Total size = 5 CFP

FP 2: Add an Order Triggering event: The waiter adds a new order

Functional User

Sub-Process Description Data Group Objects of

interest

Data Movement

Type

CFP

Waiter The waiter presses the

option “Add a new order” Order Data Order E 1

The web application returns

the list of places Place Data Place X 1

Waiter The mobile app displays the

list of places to the waiter Place Data Place E 1

Waiter The waiter chooses the place

where the customer is

installed

Place ID Place E 1

The mobile app sends the

selected place to the web

application

Place ID Place X 1


the list of tables Table Data Table E 1


list of tables to the waiter Table Data Table X 1

Waiter

The waiter chooses the table


installed

Table ID Table E 1


selected table to the web

application

Table ID Table X 1

25

FP 2: Add an Order Triggering event: The waiter adds a new order

Functional User


interest

Data Movement

Type

CFP

The web application checks

if there is any active order for

the selected table

Table ID Table E 1

The web application changes

the order state from active to

closed

Table ID Table X 1


the item family list

Item family

data Item family E 1


item family list to the waiter

Item family

data Item family X 1

Waiter

The waiter selects the item

family based on the items

requested by the customer

Item family

ID Item family E 1


selected item family to the

web application

Item family

ID Item family X 1

The web applications returns

the list of items according to

the selected Item families

Item Data Item E 1


list of items to the waiter Item Data Item X 1

Waiter

The waiter selects the items

required by the customer and

specify for each item the

recommended quantity and

customer's comment

Order Items Order E 1


selected items, the

recommended quantities and

customer's comments to the

web application

Order Items Order X 1

The web application creates

the new order Order Data Order E 1

Total size = 20 CFP

FP 3: Modify an Order Triggering event: The Waiter modifies an order

Functional User


interest

Data Movement

Type

CFP

Waiter The waiter presses the

option “Modify an order” Order Data Order E 1


the list of places Place Data Place X 1


list of places to the waiter Place Data Place E 1

Waiter The waiter chooses the place


installed

Place ID Place E 1



application

Place ID Place X 1

26

FP 3: Modify an Order Triggering event: The Waiter modifies an order

Functional User


interest

Data Movement

Type

CFP


the list of tables Table Data Table E 1


list of tables to the waiter Table Data Table X 1

Waiter



installed

Table ID Table E 1



application

Table ID Table X 1

The web application retrieves

the list of items

recommended by the

customer with their quantities

and comments


Waiter

The mobile app displays the

items recommended by the


and comments to the waiter


Waiter

The waiter adds/deletes the

new/existing item, modifies

items' quantities or modifies

items' comments



modified items to the web

application


The web application updates

the order data Order Data Order E 1

Waiter



from the web application

E/C

Message Messages X 1

Total size = 15 CFP

The total functional size of the mobile app is the sum of the sizes of its three functional processes (FP1, FP2, and FP3), that is:

5 CFP + 20 CFP + 15 CFP = 40 CFP

B. For web application

The web application includes 33 functional processes (from FP4 to FP 36). In this section, we give a detailed measurement of the functional size of the web application.

X

FP 4: Logon Triggering event: The administrator access to the logon form

Functional User


interest

Data Movement

Type

CFP

Administrator Enter username and

password

Administrator

ID Administrator E 1

The web application reads

username and password

Administrator

ID Administrator R 1

Administrator The web application displays E/C Messages X 1

27

Error/Confirmation

messages

Message

Total size = 3 CFP

FP 5: Add a User (Web application) Triggering event: The administrator adds a user (waiter)

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator enters the

user data Waiter Data Waiter E 1

The web application adds

the new user Waiter Data Waiter W 1

Administrator the web application displays


E/C


Total size = 3 CFP

FP 6: View the Users list Triggering event: The administrator views the users list

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator selects to

view the users list Waiter Data Waiter E 1


the Users list Waiter Data Waiter R 1

Administrator The web application displays

the Users list Waiter Data Waiter X 1



E/C


Total size = 4 CFP

FP 7: View a User data Triggering event: The administrator views a user data

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator selects the

desired user (Waiter) Waiter ID Waiter E 1

The web application retrieve

user data from the Database Waiter Data Waiter R 1

Administrator

The web application displays

the data of the selected

waiter

Waiter Data Waiter X 1

Total size = 3 CFP

FP 8: Modify User Data Triggering event: The administrator modifies user data

Functional User


interest

Data Movement

Type

CFP

Administrator

The administrator modifies

waiter data that can be

changed

Waiter Data Waiter E 1

The web application saves

the change Waiter Data Waiter W 1

Total size = 2 CFP

28

FP 9: Delete a User Triggering event: The administrator deletes a user

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator chooses

the user to be deleted Waiter ID Waiter E 1

The web application deletes

the selected waiter Waiter ID Waiter W 1



E/C


Total size = 3 CFP

FP10: Add an Item Triggering event: The administrator adds a new item

Functional User


interest

Data Movement

Type

CFP


data of the item Item Data Item E 1

The web application adds the

new item Item Data Item W 1



E/C


Total size = 3CFP

FP 11: View the items list Triggering event: The administrator views the items list

Functional User


interest

Data Movement

Type

CFP


view the items list Item Data Item E 1


the items list Item Data Item R 1


the items list Item Data Item X 1



E/C


Total size = 4 CFP

FP 12: View an Item data Triggering event: The administrator views an item data

Functional User


interest

Data Movement

Type

CFP


desired item Item ID Item E 1


the item data from the

Database

Item Data Item R 1

Administrator


the data of the selected item

to the administrator

Item Data Item X 1

Total size = 3 CFP

29

FP13: Modify an item

Triggering event: The administrator modifies an item

Functional User


interest

Data Movement

Type

CFP

Administrator


the desired fields (name,

price, quantity, image, etc.)

and asks the web application

to update the data of the item

Item Data Item E 1

The web application save the

change Item Data Item W 1

Total size = 2 CFP

FP14: Delete an Item Triggering event: The administrator deletes an item

Functional User


interest

Data Movement

Type

CFP


item to be deleted Item ID Item E 1


the selected item Item ID Item W 1



E/C


Total size = 3 CFP

FP 15: Add an item family Triggering event: The Administrator adds a new item family

Functional User


interest

Data Movement

Type

CFP

Administrator

The administrator enters the

data of the item and

instructs the web application

to validate the addition

Item Family

Data Item Family E 1

The web application adds

the new item family

Item Family

Data Item Family W 1

Administrator

The web application

displays Error/Confirmation

messages

E/C Message Messages X 1

Total size = 3 CFP

FP 16: View the Item families list Triggering event: The administrator views the item families list

Functional User


interest

Data Movement

Type

CFP


view the item families list

Item Family



the item families list

Item Family

Data Item Family R 1


the item families list

Item Family

Data Item Family X 1



E/C


Total size = 4 CFP

30

FP17: View Item family data Triggering event: The administrator views an item family data

Functional User


interest

Data Movement

Type

CFP


desired Item Family

Item Family

ID Item Family E 1


the Item Family data from the

Database

Item Family

Data Item Family R 1

Administrator


the data of the selected Item

Family to the administrator

Item Family

Data Item Family X 1

Total size = 3 CFP

FP 18: Modify an item family Triggering event: The administrator modifies an item family

Functional User


interest

Data Movement

Type

CFP

Administrator


the desired fields (name,

image, color) and instructs

the web application to update

the item family data

Item family



the change

Item family

Data Item Family W 1

Total size = 2 CFP

FP 19: Delete an item family Triggering event: The administrator deletes an item family

Functional User


interest

Data Movement

Type

CFP


family items to be deleted

Item family

ID Item Family E 1


the selected family item

Item family

ID Item Family W 1



E/C


Total size = 3 CFP

FP 20: Add a place Triggering event: The administrator adds a place

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator adds the

place data Place Data Place E 1


new place Place Data Place W 1


Error/Confirmation messages E/C Messages X 1

Total size = 3 CFP

31

FP 21: View the Places list Triggering event: The administrator views the places list

Functional User


interest

Data Movement

Type CFP


view the places list Place Data Place E 1


the Places list Place Data Place R 1


the Places list Place Data Place X 1



E/C


Total size = 4 CFP

FP 22: View a Place data Triggering event: The administrator views the place data

Functional User


interest

Data Movement

Type

CFP


desired place Place ID Place E 1


the Place data from the

Database

Place Data Place R 1

Administrator


the data of the selected

place to the administrator

Place Data Place X 1

Total size = 3 CFP

FP 23: Modify a place Triggering event: The administrator modifies a place data

Functional User


interest

Data Movement

Type

CFP

Administrator


the place data that can be

changed

Place Data Place E 1


change Place Data Place W 1

Total size = 2 CFP

FP 24: Delete a Place Triggering event: The administrator deletes a place

Functional User


interest

Data Movement

Type

CFP


the place to be deleted Place ID Place E 1


the selected place Place ID Place W 1



E/C


Total size = 3 CFP

32

FP25: Add a table Triggering event: The administrator adds a table

Functional User


interest

Data Movement

Type CFP

Administrator The administrator adds the

table data Table Data Table E 1


new table Table Data Table W 1



E/C


Total size = 3 CFP

FP 26: View the Tables list Triggering event: The administrator views the tables list

Functional User


interest

Data Movement

Type

CFP


view the tables list Table Data Table E 1


the Tables list Table Data Table R 1

Administrator The system displays the

Tables list Table Data Table X 1



E/C


Total size = 4 CFP

FP 27: View table data Triggering event: The administrator views table data

Functional User


interest

Data Movement

Type

CFP


desired table Table ID Table E 1


the Table data from the

database

Table Data Table R 1

Administrator


the data of the selected table

to the administrator

Table Data Table X 1

Total size = 3 CFP

FP 28: Modify table data Triggering event: The administrator modifies table data

Functional User


interest

Data Movement

Type

CFP

Administrator The administrator modifies

the table data Table Data Table E 1


change Table Data Table W 1

Total size = 2 CFP

33

FP29: Delete a table Triggering event: The administrator deletes a table

Functional User


interest

Data Movement

Type CFP


the table to be deleted Table ID Table E 1


the selected table Table ID Table W 1



E/C


Total size = 3 CFP

FP 30: Add a Menu Item Triggering event: The administrator adds a Menu Items

Functional User

Sub-Process Description Data

Group

Objects of interest

Data Movement

Type

CFP


Menu Items Data

Menu Items

Data Menu Items E 1

The web application add the

new Menu Items Data

Menu Items

Data Menu Items W 1



E/C


Total size = 3 CFP

FP 31: View the Menu Item list Triggering event: The Administrator views the Menu Items list

Functional User


interest

Data Movement

Type

CFP


view the menu Items list

Menu Items

Data Menu Items E 1


the Menu Items list

Menu Items

Data Menu Items R 1


the Menu Items list

Menu Items

Data Menu Items X 1



E/C


Total size = 4 CFP

FP 32: View a Menu Item data Triggering event: The Administrator views a Menu Items data

Functional User


interest

Data Movement

Type CFP


desired Menu Items

Menu Items

ID Menu Items E 1

The web application retrieve

the Menu Items Data

Menu Items

Data Menu Items R 1


the Data of the selected

Menu Items to the

administrator

Menu Items

Data Menu Items X 1

Total size = 3 CFP

34

FP 33: Modify a Menu Item Triggering event: The administrator modifies a Menu Items

Functional User

Sub-Process Description Data

Group Objects of

interest

Data Movement

Type CFP

Administrator


the Menu Item Data that

can be changed

Menu Items

Data Menu Items E 1


the change

Menu Items

Data Menu Items W 1

Total size = 2 CFP

FP 34: Delete a Menu Item Triggering event: The administrator deletes a Menu Items

Functional User


interest

Data Movement

Type

CFP


desired Menu Items

Menu Items

ID Menu Items E 1


the selected Menu Items

Menu Items

ID Menu Items W 1



E/C


Total size = 3 CFP

FP 35: Manage the List of Orders Triggering event: The administrator views the list of orders

Functional

User Sub-Process Description Data Group

Objects of

interest

Data

Movement

Type CFP


view the orders list Order Data Order E 1


the orders data Order Data Order R 1


the orders list Order Data Order X 1



E/C


Total size = 4 CFP

FP 36: Delete an order Triggering event: The administrator deletes an order

Functional

User Sub-Process Description Data Group

Objects of

interest

Data

Movement

Type CFP


order to be deleted Order ID Order E 1


the selected order Order ID Order W 1

Total size = 2 CFP

The total functional size of the web application is the sum of the sizes of its 33 functional processes, that is:

3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP+ 3 CFP + 3 CFP + 4 CFP + 3 CFP +2 CFP + 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP + 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP + 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP+ 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP + 3 CFP + 4 CFP + 2 CFP = 99 CFP

35

C. For the whole system

The total size of “Resto-Sys” is then equal to the sum of functional sizes of mobile and web applications (40 CFP + 99 CFP) = 139 CFP.

4. 2 Functional size measured from FUR - UML textual description

A. Using Action-Type

Table 5 presents the mapping of action-type in use case description with COSMIC data movements.

Table 5 Equivalence between action-type in use case description and COSMIC concepts in

terms of Data movements

Actions-types in Use case description

Actions-types description COSMIC concepts CFP

Action-type = Expletive An action that does not lead

to an exchange of data. Not applied 0 CFP

Action-type = Request

An action representing the act

of asking for something, it is

directed by an actor.

An Entry data movement

from the Functional user to

the software to be measured

1 CFP

Action-type = Response

An answer or a reply sent

after a Request, it is directed

by the system.

An eXit data movement from


to the Functional user

1 CFP

Action-type =

DataRecovery

An action that allows the

retrieving of data.

A Read data movement from

the persistent storage to the

software to be measured

1 CFP

Action-type =

DataPersist

An action allowing the

recording of data.

A Write data movement from


to the persistent storage

1 CFP

a. For mobile app

Table 6 presents the measurement results of the functional size of the mobile app based on the Action-Type.

Table 6 Measurement Results-Using Action-Type (mobile app)

Functional User

Requirements

Functional Processes

Sub-Process Description Action Type CFP

FUR 1: Logon FP 1: Logon

Enter username and password Request 1

Provide actor data to the web application

Response 1

Receive log status (Connected) Request 1

Receive log status (Not Connected)

Request 1

Display Error/Confirmation message

Response 1

FS(FP 1: Logon) = 5 CFP

FUR 2: Maintain Order

FP 2: Add an order

The waiter presses the option

“Add a new order” Request 1

The web application returns the

list of places Response 1

The mobile app displays the list

of places to the waiter Request 1

36

The waiter chooses the place

where the customer is installed Request 1



application

Response 1


list of tables Request 1


of tables to the waiter Response 1


where the customer is installed Request 1



application

Response 1

The web application checks if

there is any active order for the

selected table

Request 1

The web application changes the

order state from active to closed Response 1


item family list Request 1

The mobile app displays the item

family list to the waiter Response 1

The waiter selects the item

family based on the items

requested by the customer

Request 1


selected item family to the web

application

Response 1

The web applications returns the

list of items according to the

selected Item families

Request 1


of items to the waiter Response 1

The waiter selects the items

required by the customer and

specify for each item the

recommended quantity and

customer's comment

Request 1


selected items, the

recommended quantities and

customer's comments to the web

application

Response 1

The web application creates the

new order Request 1

FS(FP 2: Add an order) = 20 CFP

FP 3: Modify an order

The waiter presses the

option “Modify an order” Request 1


the list of places Response 1


list of places to the waiter Request 1

The waiter chooses the place


installed

Request 1

37



application

Response 1


the list of tables Request 1


list of tables to the waiter Response 1



installed

Request 1



application

Response 1

The web application retrieves the

list of items recommended by the


and comments

Request 1


items recommended by the


and comments to the waiter

Response 1

The waiter adds/deletes the

new/existing item, modifies

items' quantities or modifies

items' comments

Request 1


modified items to the web

application

Response 1

The web application updates

the order data Request 1


E/C messages from the web

application

Response 1

FS(FP 3: Modify an order) = 15 CFP

The total functional size of the mobile app is the sum of the sizes of its three functional processes (FP1, FP2, and FP3), that is:

5 CFP + 20 CFP + 15 CFP = 40 CFP

b. For web application

The following Table 7 presents the measurement results of the functional size of the web application based on the Action-Type.

Table 7 Measurement Results-Using Action-Type (web application)

Functional User

Requirements

Functional Processes

Sub-Process Description Action Type

CFP

FUR 3: Logon

FP 4: Logon

Enter username and password Request 1

The web application reads

username and password

Data-

Recovery 1

Display Error/Confirmation

message Response 1

FS(FP 4: Logon) = 3 CFP

38


FP 5: Add a user

The Administrator enters the user

data (waiter) Request 1

The web application adds the new

user DataPersist 1


Response 1

FS(FP 5: Add a User) = 3 CFP

FP 6: View the Users list

The administrator selects to

view the users list Request 1


Users list

Data-

Recovery 1

The web application displays the

Users list Response 1


messages Response 1

FS(FP 6: View the Users list) = 4 CFP

FP 7: View User Data

The Administrator selects the

desired user (Waiter) Request 1

The web application retrieves user

data from the Database

Data-

Recovery 1


data of the selected waiter Response 1

FS(FP 7: View User Data) = 3 CFP

The Administrator modifies the

waiter data that can be changed Request

1

The web application saves the change

DataPersist 1

FS(FP 8: Modify User Data) = 2 CFP

FP 9: Delete a User

The Administrator chooses the

waiter to be deleted Request 1

The web application deletes the

selected waiter DataPersist 1


Response 1

FS(FP 9: Delete a User) = 3 CFP


FP 10: Add an Item

The Administrator enters the data

of the item Request 1


item DataPersist 1


Response 1

FS(FP 10: Add an Item) = 4 CFP

FP 11: View the items list


view the items list Request 1


items list

Data-

Recovery 1


items list Response 1


messages Response 1

FS(FP 11: View the items list) = 4 CFP

FP 12: View an Item data


desired item Request 1


Item data from the Data base

Data-

Recovery 1

39


data of the selected Item to the

Administrator

Response 1

FS(FP 12: View an Item data) = 3 CFP


desired fields and asks the web

application to update the data of

the item

Request 1

The web application saves the

change DataPersist 1

FS(FP 13: Modify an Item) = 2 CFP

FP 14: Delete an Item

The Administrator selects the item

to be deleted Request 1


selected item DataPersist 1


Response 1

FS(FP 14: Delete an Item) = 3 CFP

FUR 6: Maintain Item family

FP 15: Add an item family

The Administrator enters the data

of the item and instructs the web

application to validate the addition

Request 1


item family DataPersist 1


Response 1

FS(FP 15: Add an item family) = 3 CFP

FP 16: View the Item families list


view the item families list Request 1


item families list

Data-

Recovery 1


item families list Response 1


messages Response 1

FS(FP 16: View the Item families list) = 4 CFP

FP 17: View an Item family data


desired Item family Request 1


Item family data Data-

Recovery 1


data of the selected Item family to

the Administrator

Response 1

FS(FP 17: View an Item family data) = 3 CFP


desired fields and instructs the web

application to update the data of

the item family

Request 1


DataPersist 1

FS(FP 18: Modify an item family) = 2 CFP

FP 19: Delete an item family


family items to be deleted Request 1


selected family item DataPersist 1


Response 1

40

FS(FP 19: Delete an item family) = 3 CFP


FP 20: Add a Place

The Administrator adds the place

data Request 1


place DataPersist 1


Response 1

FS(FP 20: Add a Place) = 3 CFP

FP 21: View the Places list


view the places list Request 1


Places list

Data-

Recovery 1


Places list Response 1


messages Response 1

FS(FP 21: View the Places list) = 4 CFP

FP 22: View a Place data


desired place Request 1


Place data from the Data base

Data-

Recovery 1


data of the selected Place to the

Administrator

Response 1

FS(FP 22: View a Place data) = 3 CFP


place data that can be changed Request 1


DataPersist 1

FS(FP 23: Modify a place) = 2 CFP

FP 24: Delete a place


place to be deleted Request 1


selected place DataPersist 1


Response 1

FS(FP 24: Delete a place) = 3 CFP


FP 25: Add a Table

The Administrator adds the table

data Request 1


table DataPersist 1


Response 1

FS(FP 25: Add a Table) = 3 CFP

FP 26: View the Tables list


view the tables list Request 1


Tables list

Data-

Recovery 1


Tables list Response 1


messages Response 1

FS(FP 26: View the Tables list) = 4 CFP

FP 27: View table


desired table Request 1

41

data The web application retrieves the

Table data from the database

Data-

Recovery 1


data of the selected table to the

Administrator

Response 1

FS(FP 27: View table data) = 3 CFP


table data Request 1



FS(FP 28: Modify table data) =2 CFP

FP 29: Delete a Table


table to be deleted Request 1


selected table DataPersist 1


message Response 1

FS(FP 29: Delete a Table) = 3 CFP

FP 30: Add a Menu Items

The Administrator enters the menu

items data Request 1



menu items DataPersist 1


message Response 1

FS(FP 30: Add an Menu Items ) = 3 CFP

FP 31: View the Menu Items list


view the menu Items list Request 1


Menu Items list

Data-

Recovery 1


Menu Items list Response 1


messages Response 1

FS(FP 31: View the Menu Items list) = 4 CFP

FP 32: View a Menu Items Data


desired menu items Request 1


menu items data

Data-

Recovery 1


data of the selected menu items to

the Administrator

Response 1

FS(FP 32: View Menu items Data) = 3 CFP

FP 33: Modify a Menu Items


menu items data that can be

changed

Request 1



FS(FP 33: Modify a Menu items) = 2 CFP

FP 34: Delete a Menu Items


desired menu items Request 1


selected menu items DataPersist 1


message Response 1

FS(FP 34: Delete a Menu Items) = 3 CFP

FP 35: The administrator selects to Request 1

42

View the List of Orders

view the orders list

FUR 10: Manage the List of Orders


orders data

Data-

Recovery 1


list of orders Response 1


message Response 1

FS(FP 35: View the List of Orders) = 4 CFP

FP 36: Delete an order data

The administrator selects the order

to be deleted Request 1


selected order DataPersist 1

FS(FP 36: View an order data)= 2 CFP

The total functional size of the web application is the sum of the sizes of its 33 functional processes, that is:

3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP+ 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP+ 3 CFP + 3 CFP +4 CFP + 3 CFP + 2 CFP + 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP + 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP+ 3 CFP + 3 CFP + 4 CFP + 3 CFP + 2 CFP + 3 CFP + 4 CFP + 2 CFP = 99 CFP

The total size of “Resto-Sys” is then equal to the sum of functional sizes of mobile and web applications (40 CFP + 99 CFP) = 139 CFP, which is the same functional size as measured by referring to the documented FUR in natural language.

43

REFERENCE

COSMIC (2015a) Guideline on Non-Functional & Project Requirements : How to consider non-

functional and project requirements in software project performance measurement,

benchmarking and estimating.

COSMIC (2015b) Guideline for Early or Rapid COSMIC Functional Size Measurement by using

approximation approaches.

Haoues M, Sellami A, Ben-Abdallah H (2016) Functional Change Impact Analysis in Use Cases: An

Approach based on COSMIC Functional Size Measurement.

Mhadhbi S (2013) Conception et Développement d’un Système de Gestion Restaurant Mobile.

44

APPENDIX A - STRUCTURED USE CASE DOCUMENTATION FORMAT USING

ACTION-TYPE

Many individual proposals of textual descriptions are available to assist in documenting a Use Case

(UC). We proposed an extension of the UC textual description with the “Type” of an action which can

be: “Request”, “DataPersist”, “DataRecovery”, “Expletive”, or “Response” (Haoues et al. 2016). A

“Request” corresponds to an action representing the act of asking for something, it is directed by an

actor. A “Response” corresponds to an answer or a reply sent after a Request, it is directed by the

system. A “DataPersist” action corresponds to an action allowing the recording of data. An “Expletive”

action is used to get an action started but does not lead to an exchange of data.“DataRecovery” action

allows the retrieving of data.

The following documentation of a use case is provided in (Haoues et al. 2016).

Number:<unique ID assigned to a use case>

Name:<unique name assigned to a use case>

Level:<level of use case description>

Description:<a summary of use case purpose>

Actors:<Primary actor: actor that initiates the use case>

<Secondary actor: actor that participate within the use case>

Pre-condition:<a list of conditions that must be true to initialize the use case>

Post-condition (success):<state of the system if goal is achieved>

Post-condition (failure):<state of the system if goal is abandoned>

Relationship

[Include:<use cases in relation with this use case by "include">,Extend:<use cases

in relation with this use case by "extend">, Super use case:<list of subordinate use

cases of this use case>, Sub use case: <list of all use cases that specialize this use

case>]

Begin

MS /* Main scenario */

<Steps of the scenario from trigger to goal>

Begin

<NumAction> [<Pre-condition>] <Actor|System><Type: Request, DataPersist,

Expletive, Response, DataRecovery><Action Description> [<Int-Parameter>] [<Out-

Parameter>]

End

AS /* Alternative scenario */

Begin<Event, begin at Num "action number">



Parameter>]

The main scenario back to NUM

End ES /* Error scenario */

Begin<Event, begin at Num "action number">



Parameter>]

End

End Use Case

Special requirements:<list of non-functional requirements>

Case Study Sizing natural language/UML requirements for ... · 1 Case Study Sizing natural...

Documents

Transcript of Case Study Sizing natural language/UML requirements for ... · 1 Case Study Sizing natural...