type 【即納・国内在庫】 EAGLE イエロー EYE製 (イーグルアイ) 09

Case Study
Sizing natural language/UML requirements for Web and
Mobile applications using COSMIC FSM
1
1
2,1
Asma Sellami , Mariem Haoues , Hanêne Ben-Abdallah , Alain Abran
4
5
3
6
Arlan Lesterhuis , Charles Symons , Sylvie Trudel
1
Mir@cl Laboratory, University of Sfax, Tunisia
2
King Abdulaziz University, Jeddah, KSA
3
Ecole 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.”
1
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
2
A.
FUR - Functional User Requirements ...................................................................................... 4
C.
NFR - Non-Functional Requirements ..................................................................................... 16
D.
PRC - Project Requirements and Constraints ........................................................................ 17
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
3
A.
Level of granularity ................................................................................................................ 18
B.
Decomposition ...................................................................................................................... 19
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
2
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
3
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
Smartphone. It also allows the administrator to delete an order. During working hours,
waiters (Smartphone) and the administrator (web client) are continuously connected.
Account management: This task involves users’ management, and it enables access to
application with a username and a password.
Menu Items management: This task allows the management of item families and
classification of items into item families.
his
the
the
the
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.
4






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 andor 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
Waiter
Administrator
Global Use Cases
Logon
Maintain Order
Logon
Maintain Data
Maintain Order
Detailed Use Cases
FUR 1: Logon
FUR 2: Maintain Order
FUR 3: Logon
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
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).
5
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
6
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*/
7
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>
Actors: <Primary actor: Administrator>
Begin
8
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
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 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
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 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. */
9
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”>
/* The scenario restarts at point 1. */
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>
Actors: <Primary actor: Administrator>
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>].
AS /* Alternative Scenario */
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>].
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 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
10
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 item to be deleted>
[<Item ID>].
5. <System><DataPersist><The system deletes the selected item> [<Item ID>].
ES /* Error Scenario */
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>
Actors: <Primary actor: Administrator>
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>].
AS /* Alternative Scenario */
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
1. <Administrator><Request><The administrator selects to view the item families’
list> [<Item Families Data>].
11
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 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
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 item family to be
deleted> [<Item family ID>].
5. <System><DataPersist><The system deletes the selected item family> [<Item
family ID>].
ES /* Error Scenario */
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”>
/* The scenario restarts at point 2. */
End
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”>
/* The scenario restarts at point 2. */
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>
Actors: <Primary actor: Administrator>
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
Data>].
4. <System><Expletive><The system checks that all required data are entered
correctly>.
5. <System><DataPersist><The system adds the new place> [<Place Data>].
12
AS /* Alternative Scenario */
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>].
ES /* Error Scenario */
Begin<Place already exist, begin at Num '5' in the main scenario>
5.1 <System><Response><The system displays the message “Place already exists”>
/* The scenario restarts at point 3. */
End
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”>
/* The scenario restarts at point 1. */
End
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>
Actors: <Primary actor: Administrator>
Begin
MS /* Main Scenario */
13
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
Data>].
4. <System><Expletive><The system checks that all required data are entered
correctly>.
5. <System><DataPersist><The system adds the new table> [<Table Data>].
AS /* Alternative Scenario */
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
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 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
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 chooses the table to be deleted>
[<Table ID>].
5. <System><DataPersist><The system deletes the selected table> [<Table ID>].
ES /* Error Scenario */
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”>
/* The scenario restarts at point 1. */
End
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”>
14
/* The scenario restarts at point 1. */
End
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>
Actors: <Primary actor: Administrator>
Begin
MS /* Main Scenario */
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>].
AS /* Alternative Scenario */
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
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 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
1. <Administrator><Request><The administrator selects to view the menu items list
option> [<Menu Item Data>].
15
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><DataPersist><The system deletes the menu items > [<Menu Items
ID>].
ES /* Error Scenario */
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”>
/* The scenario restarts at point 3. */
End
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”>
/* The scenario restarts at point 2. */
End
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”>
/* The scenario restarts at point 2. */
End
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
MS /* Main Scenario */
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>].
ES /* Error Scenario */
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”>
/* The scenario restarts at point 1. */
End
16
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.
17
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.
X E
E
E X
X
Functional User
(Waiter)
E
X
Mobile
app
Web
application
W
Functional User
(Administrator)
R
Persistent
Storage
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
18
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
E
X
X
E
Web Server
Figure 5 Decomposition
19
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
FUR 1: Logon
Functional Processes
FP 1: Logon
Triggering Events
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
FP 4: 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
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 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
The waiter modifies an order
FP 35: View the List of Orders
The administrator views the list of orders
FP 36: Delete an Order
The administrator deletes an order
FUR 3: Logon
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
FUR 10:
Manage the
List of Orders
The administrator access to the logon form
The administrator adds a user
The administrator asks for the users list
The administrator asks for a user data
The administrator modifies a user data
The administrator deletes a user
The administrator adds a new item
The administrator views the items list
The administrator views the item data
The administrator modifies an item
The administrator deletes an item
The administrator adds a new item family
The administrator views the item families list
The administrator views an item family data
The administrator modifies an item family
The administrator deletes an item family
The administrator adds a place
The administrator views the places list
The administrator views a place data
The administrator modifies a place
The administrator deletes a place
The administrator adds a table
The administrator views the tables list
The administrator views a table Data
The administrator modifies a table data
The administrator deletes a table
The administrator adds a Menu Items
The administrator views the Menu Items list
The administrator views a Menu Items data
The administrator modifies a Menu Items
The administrator deletes a Menu Items
20
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
FUR 1: Logon
FUR 2:Maintain Order
FUR 3: Logon
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
FUR 10: Manage the List of Orders
Functional Processes
FP 1: Logon
FP 2: Add an Order
FP 3: Modify an Order
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
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
FP 35: View the List of Orders
FP 36: Delete an Order
21
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
FUR 1
FUR 4
Data attributes
Waiter Data
username, password,
name, phone_number,
address, userstate
Log status
userstate
Waiter ID
username, password
Administrator Data
username, password,
name, phone_number,
address, userstate
Administrator ID
username, password
Log status
userstate
Table Data
table number, place
number, state, capacity
Table ID
table number
Item family Data
item family number,
menu items number
designation
Item family ID
item family number
Waiter
FUR 3
Administrator
FUR 8
Table
FUR 6
Item family
FUR 5
Item
FUR 7
Place
FUR 2
FUR 10
Order
Item Data
item number,
item family number
designation,
image,
price,
quantity
Item ID
item number
Place Data
place number, name
Place ID
Order ID
place number
order number,
order number,
table number,
order status,
date,
time,
Order Data
Example
username: alx84
password: 123
name: Alex
phone_number: 22234567
address: Sfax, Tunisia
userstate: connected
username: Alx84
password: 123
username: adm84
password: 456
name: Bill
phone_number: 59875444
address: Sfax, Tunisia
username: adm84
password: 456
userstate: connected
table number: 1
place number: 1
state: occupied
capacity: 2
table number: 1
item family number: 1
designation: Juice
menu items number: 1
item family number: 2
designation: soda
menu items number:1
item family number: 1
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 number: 1
place number: 1
name: non-smoking
place number: 1
order number: 20
order number: 20
table number: 1
order status: active
date: 05/07/2016
time: 8:00 pm
22
Order Items
FUR 9
Menu Items ID
Menu Items
From
FUR 1 to
FUR 10
Messages
Menu Items Data
E/C message
name
order number,
item number,
quantity,
comment
menu items number
menu items number,
description
Message description
name: Alex
order number: 20
item number: 1
quantity: 3
comment: none
item number: 2
quantity: 1
comment: with ice
menu items number: 1
menu items number: 1
description: dessert
Message description:
“Orders list is empty”
23
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
Waiter
Waiter
Sub-Process Description
Enter username and
password
Provide actor data to the web
application
Receive log status
(Connected)
The mobile app log status
(Not connected)
The mobile app displays
Error/Confirmation messages
from the web application
Objects
of
interest
Data Group
Data
Movement
Type
CFP
Waiter ID
Waiter
E
1
Waiter ID
Waiter
X
1
Waiter
E
1
Waiter
E
1
Messages
X
1
Log status
(Connected)
Log status
(Not connected)
E/C Message
Total size = 5 CFP
FP 2: Add an Order
Triggering event: The waiter adds a new order
Functional
User
Waiter
Waiter
Waiter
Waiter
Waiter
Sub-Process Description
The waiter presses the
option “Add a new order”
The web application returns
the list of places
The mobile app displays the
list of places to the waiter
The waiter chooses the place
where the customer is
installed
The mobile app sends the
selected place to the web
application
The web application returns
the list of tables
The mobile app displays the
list of tables to the waiter
The waiter chooses the table
where the customer is
installed
The mobile app sends the
selected table to the web
application
Data Group
Objects of
interest
Data
Movement
Type
CFP
Order Data
Order
E
1
Place Data
Place
X
1
Place Data
Place
E
1
Place ID
Place
E
1
Place ID
Place
X
1
Table Data
Table
E
1
Table Data
Table
X
1
Table ID
Table
E
1
Table ID
Table
X
1
24
FP 2: Add an Order
Triggering event: The waiter adds a new order
Functional
User
Waiter
Waiter
Waiter
Waiter
Sub-Process Description
The web application checks
if there is any active order for
the selected table
The web application changes
the order state from active to
closed
The web application returns
the item family list
The mobile app displays the
item family list to the waiter
The waiter selects the item
family based on the items
requested by the customer
The mobile app sends the
selected item family to the
web application
The web applications returns
the list of items according to
the selected Item families
The mobile app displays the
list of items to the waiter
The waiter selects the items
required by the customer and
specify for each item the
recommended quantity and
customer's comment
The mobile app sends the
selected items, the
recommended quantities and
customer's comments to the
web application
The web application creates
the new order
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table ID
Table
E
1
Table ID
Table
X
1
Item family
E
1
Item family
X
1
Item family
ID
Item family
E
1
Item family
ID
Item family
X
1
Item Data
Item
E
1
Item Data
Item
X
1
Order Items
Order
E
1
Order Items
Order
X
1
Order Data
Order
E
1
Item family
data
Item family
data
Total size = 20 CFP
FP 3: Modify an Order
Triggering event: The Waiter modifies an order
Functional
User
Waiter
Waiter
Waiter
Sub-Process Description
The waiter presses the
option “Modify an order”
The web application returns
the list of places
The mobile app displays the
list of places to the waiter
The waiter chooses the place
where the customer is
installed
The mobile app sends the
selected place to the web
application
Data Group
Objects of
interest
Data
Movement
Type
CFP
Order Data
Order
E
1
Place Data
Place
X
1
Place Data
Place
E
1
Place ID
Place
E
1
Place ID
Place
X
1
25
FP 3: Modify an Order
Triggering event: The Waiter modifies an order
Functional
User
Waiter
Waiter
Waiter
Waiter
Waiter
Sub-Process Description
The web application returns
the list of tables
The mobile app displays the
list of tables to the waiter
The waiter chooses the table
where the customer is
installed
The mobile app sends the
selected table to the web
application
The web application retrieves
the list of items
recommended by the
customer with their quantities
and comments
The mobile app displays the
items recommended by the
customer with their quantities
and comments to the waiter
The waiter adds/deletes the
new/existing item, modifies
items' quantities or modifies
items' comments
The mobile app sends the
modified items to the web
application
The web application updates
the order data
The mobile app displays
Error/Confirmation messages
from the web application
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table Data
Table
E
1
Table Data
Table
X
1
Table ID
Table
E
1
Table ID
Table
X
1
Order Items
Order
E
1
Order Items
Order
X
1
Order Items
Order
E
1
Order Items
Order
X
1
Order Data
Order
E
1
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
Administrator
Administrator
Sub-Process Description
Data Group
Enter username and
password
The web application reads
username and password
The web application displays
Administrator
ID
Administrator
ID
E/C
Data
Movement
Type
CFP
Administrator
E
1
Administrator
R
1
Messages
X
1
Objects of
interest
26
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
Administrator
Administrator
Sub-Process Description
The administrator enters the
user data
The web application adds
the new user
the web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Waiter Data
Waiter
E
1
Waiter Data
Waiter
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
FP 6: View the Users list
Triggering event: The administrator views the users list
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
The administrator selects to
view the users list
The web application retrieves
the Users list
The web application displays
the Users list
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Waiter Data
Waiter
E
1
Waiter Data
Waiter
R
1
Waiter Data
Waiter
X
1
E/C
Message
Messages
X
1
Total size = 4 CFP
FP 7: View a User data
Triggering event: The administrator views a user data
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator selects the
desired user (Waiter)
The web application retrieve
user data from the Database
The web application displays
the data of the selected
waiter
Data Group
Objects of
interest
Data
Movement
Type
CFP
Waiter ID
Waiter
E
1
Waiter Data
Waiter
R
1
Waiter Data
Waiter
X
1
Total size = 3 CFP
FP 8: Modify User Data
Triggering event: The administrator modifies user data
Functional
User
Administrator
Sub-Process Description
The administrator modifies
waiter data that can be
changed
The web application saves
the change
Data Group
Objects of
interest
Data
Movement
Type
CFP
Waiter Data
Waiter
E
1
Waiter Data
Waiter
W
1
Total size = 2 CFP
27
FP 9: Delete a User
Triggering event: The administrator deletes a user
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator chooses
the user to be deleted
The web application deletes
the selected waiter
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Waiter ID
Waiter
E
1
Waiter ID
Waiter
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
FP10: Add an Item
Triggering event: The administrator adds a new item
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator enters the
data of the item
The web application adds the
new item
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Item Data
Item
E
1
Item Data
Item
W
1
E/C
Message
Messages
X
1
Total size = 3CFP
FP 11: View the items list
Triggering event: The administrator views the items list
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
The administrator selects to
view the items list
The web application retrieves
the items list
The web application displays
the items list
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Item Data
Item
E
1
Item Data
Item
R
1
Item Data
Item
X
1
E/C
Message
Messages
X
1
Total size = 4 CFP
FP 12: View an Item data
Triggering event: The administrator views an item data
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator selects the
desired item
The web application retrieves
the item data from the
Database
The web application displays
the data of the selected item
to the administrator
Data Group
Objects of
interest
Data
Movement
Type
CFP
Item ID
Item
E
1
Item Data
Item
R
1
Item Data
Item
X
1
Total size = 3 CFP
28
FP13: Modify an item
Triggering event: The administrator modifies an item
Functional
User
Administrator
Sub-Process Description
The administrator modifies
the desired fields (name,
price, quantity, image, etc.)
and asks the web application
to update the data of the item
The web application save the
change
Objects of
interest
Data Group
Data
Movement
Type
CFP
Item Data
Item
E
1
Item Data
Item
W
1
Total size = 2 CFP
FP14: Delete an Item
Triggering event: The administrator deletes an item
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator selects the
item to be deleted
The web application deletes
the selected item
The web application displays
Error/Confirmation messages
Objects of
interest
Data Group
Data
Movement
Type
CFP
Item ID
Item
E
1
Item ID
Item
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
FP 15: Add an item family
Triggering event: The Administrator adds a new item family
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator enters the
data of the item and
instructs the web application
to validate the addition
The web application adds
the new item family
The
web
application
displays Error/Confirmation
messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Item Family
Data
Item Family
E
1
Item Family
Data
Item Family
W
1
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
Administrator
Administrator
Administrator
Sub-Process Description
Data Group
The administrator selects to
view the item families list
The web application retrieves
the item families list
The web application displays
the item families list
The web application displays
Error/Confirmation messages
Item Family
Data
Item Family
Data
Item Family
Data
E/C
Message
Data
Movement
Type
CFP
Item Family
E
1
Item Family
R
1
Item Family
X
1
Messages
X
1
Objects of
interest
Total size = 4 CFP
29
FP17: View Item family data
Triggering event: The administrator views an item family data
Functional
User
Administrator
Administrator
Data
Movement
Type
CFP
Item Family
E
1
Item Family
Data
Item Family
R
1
Item Family
Data
Item Family
X
1
Sub-Process Description
Data Group
The administrator selects the
desired Item Family
The web application retrieves
the Item Family data from the
Database
The web application displays
the data of the selected Item
Family to the administrator
Item Family
ID
Objects of
interest
Total size = 3 CFP
FP 18: Modify an item family
Triggering event: The administrator modifies an item family
Functional
User
Administrator
Sub-Process Description
The administrator modifies
the desired fields (name,
image, color) and instructs
the web application to update
the item family data
The web application saves
the change
Data Group
Objects of
interest
Data
Movement
Type
CFP
Item family
Data
Item Family
E
1
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
Administrator
Administrator
Sub-Process Description
The administrator selects the
family items to be deleted
The web application deletes
the selected family item
The web application displays
Error/Confirmation messages
Data Group
Item family
ID
Item family
ID
E/C
Message
Data
Movement
Type
CFP
Item Family
E
1
Item Family
W
1
Messages
X
1
Objects of
interest
Total size = 3 CFP
FP 20: Add a place
Triggering event: The administrator adds a place
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator adds the
place data
The web application adds the
new place
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Place Data
Place
E
1
Place Data
Place
W
1
E/C
Messages
X
1
Total size = 3 CFP
30
FP 21: View the Places list
Triggering event: The administrator views the places list
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
The administrator selects to
view the places list
The web application retrieves
the Places list
The web application displays
the Places list
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Place Data
Place
E
1
Place Data
Place
R
1
Place Data
Place
X
1
E/C
Message
Messages
X
1
Total size = 4 CFP
FP 22: View a Place data
Triggering event: The administrator views the place data
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator selects the
desired place
The web application retrieves
the Place data from the
Database
The web application displays
the data of the selected
place to the administrator
Data Group
Objects of
interest
Data
Movement
Type
CFP
Place ID
Place
E
1
Place Data
Place
R
1
Place Data
Place
X
1
Total size = 3 CFP
FP 23: Modify a place
Triggering event: The administrator modifies a place data
Functional
User
Administrator
Sub-Process Description
The administrator modifies
the place data that can be
changed
The web application save the
change
Data Group
Objects of
interest
Data
Movement
Type
CFP
Place Data
Place
E
1
Place Data
Place
W
1
Total size = 2 CFP
FP 24: Delete a Place
Triggering event: The administrator deletes a place
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator chooses
the place to be deleted
The web application deletes
the selected place
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Place ID
Place
E
1
Place ID
Place
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
31
FP25: Add a table
Triggering event: The administrator adds a table
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator adds the
table data
The web application adds the
new table
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table Data
Table
E
1
Table Data
Table
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
FP 26: View the Tables list
Triggering event: The administrator views the tables list
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
The administrator selects to
view the tables list
The web application retrieves
the Tables list
The system displays the
Tables list
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table Data
Table
E
1
Table Data
Table
R
1
Table Data
Table
X
1
E/C
Message
Messages
X
1
Total size = 4 CFP
FP 27: View table data
Triggering event: The administrator views table data
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator selects the
desired table
The web application retrieves
the Table data from the
database
The web application displays
the data of the selected table
to the administrator
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table ID
Table
E
1
Table Data
Table
R
1
Table Data
Table
X
1
Total size = 3 CFP
FP 28: Modify table data
Triggering event: The administrator modifies table data
Functional
User
Administrator
Sub-Process Description
The administrator modifies
the table data
The web application save the
change
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table Data
Table
E
1
Table Data
Table
W
1
Total size = 2 CFP
32
FP29: Delete a table
Triggering event: The administrator deletes a table
Functional
User
Administrator
Administrator
Sub-Process Description
The administrator chooses
the table to be deleted
The web application deletes
the selected table
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Table ID
Table
E
1
Table ID
Table
W
1
E/C
Message
Messages
X
1
Total size = 3 CFP
FP 30: Add a Menu Item
Triggering event: The administrator adds a Menu Items
Functional
User
Administrator
Administrator
Sub-Process Description
Data
Group
The administrator enters the
Menu Items Data
The web application add the
new Menu Items Data
The web application displays
Error/Confirmation messages
Menu Items
Data
Menu Items
Data
E/C
Message
Data
Movement
Type
CFP
Menu Items
E
1
Menu Items
W
1
Messages
X
1
Objects of
interest
Total size = 3 CFP
FP 31: View the Menu Item list
Triggering event: The Administrator views the Menu Items list
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
Data Group
The administrator selects to
view the menu Items list
The web application retrieves
the Menu Items list
The web application displays
the Menu Items list
The web application displays
Error/Confirmation messages
Menu Items
Data
Menu Items
Data
Menu Items
Data
E/C
Message
Data
Movement
Type
CFP
Menu Items
E
1
Menu Items
R
1
Menu Items
X
1
Messages
X
1
Objects of
interest
Total size = 4 CFP
FP 32: View a Menu Item data
Triggering event: The Administrator views a Menu Items data
Functional
User
Administrator
Sub-Process Description
Data Group
The administrator selects the
desired Menu Items
The web application retrieve
the Menu Items Data
The web application displays
the Data of the selected
Menu Items to the
administrator
Menu Items
ID
Menu Items
Data
Menu Items
Data
Data
Movement
Type
CFP
Menu Items
E
1
Menu Items
R
1
Menu Items
X
1
Objects of
interest
Total size = 3 CFP
33
FP 33: Modify a Menu Item
Triggering event: The administrator modifies a Menu Items
Functional
User
Administrator
Sub-Process Description
The administrator modifies
the Menu Item Data that
can be changed
The web application saves
the change
Data
Group
Objects of
interest
Data
Movement
Type
CFP
Menu Items
Data
Menu Items
E
1
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
Administrator
Administrator
Sub-Process Description
Data Group
The administrator selects the
desired Menu Items
The web application deletes
the selected Menu Items
The web application displays
Error/Confirmation messages
Menu Items
ID
Menu Items
ID
E/C
Message
Data
Movement
Type
CFP
Menu Items
E
1
Menu Items
W
1
Messages
X
1
Objects of
interest
Total size = 3 CFP
FP 35: Manage the List of Orders
Triggering event: The administrator views the list of orders
Functional
User
Administrator
Administrator
Administrator
Sub-Process Description
The administrator selects to
view the orders list
The web application retrieves
the orders data
The web application displays
the orders list
The web application displays
Error/Confirmation messages
Data Group
Objects of
interest
Data
Movement
Type
CFP
Order Data
Order
E
1
Order Data
Order
R
1
Order Data
Order
X
1
E/C
Message
Messages
X
1
Total size = 4 CFP
FP 36: Delete an order
Triggering event: The administrator deletes an order
Functional
User
Administrator
Sub-Process Description
The administrator selects the
order to be deleted
The web application deletes
the selected order
Data Group
Objects of
interest
Data
Movement
Type
CFP
Order ID
Order
E
1
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
34
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
Action-type = Expletive
Action-type = Request
Action-type = Response
Actions-types description
An action that does not lead
to an exchange of data.
An action representing the act
of asking for something, it is
directed by an actor.
An answer or a reply sent
after a Request, it is directed
by the system.
Action-type =
DataRecovery
An action that allows the
retrieving of data.
Action-type =
DataPersist
An action allowing the
recording of data.
COSMIC concepts
CFP
Not applied
0 CFP
An Entry data movement
from the Functional user to
the software to be measured
An eXit data movement from
the software to be measured
to the Functional user
A Read data movement from
the persistent storage to the
software to be measured
A Write data movement from
the software to be measured
to the persistent storage
1 CFP
1 CFP
1 CFP
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
FUR 1: Logon
Functional
Processes
FP 1:
Logon
Sub-Process Description
Action
Type
CFP
Enter username and password
Request
1
Provide actor data to the web
application
Response
1
Receive log status (Connected)
Request
1
Request
1
Response
1
Receive log status (Not
Connected)
Display Error/Confirmation
message
FS(FP 1: Logon) = 5 CFP
FUR 2:
Maintain Order
FP 2: Add
an order
The waiter presses the option
“Add a new order”
The web application returns the
list of places
The mobile app displays the list
of places to the waiter
Request
1
Response
1
Request
1
35
FP 3:
Modify an
order
The waiter chooses the place
Request
1
where the customer is installed
The mobile app sends the
selected place to the web
Response
1
application
The web application returns the
Request
1
list of tables
The mobile app displays the list
Response
1
of tables to the waiter
The waiter chooses the table
Request
1
where the customer is installed
The mobile app sends the
selected table to the web
Response
1
application
The web application checks if
there is any active order for the
Request
1
selected table
The web application changes the
Response
1
order state from active to closed
The web application returns the
Request
1
item family list
The mobile app displays the item
Response
1
family list to the waiter
The waiter selects the item
family based on the items
Request
1
requested by the customer
The mobile app sends the
selected item family to the web
Response
1
application
The web applications returns the
list of items according to the
Request
1
selected Item families
The mobile app displays the list
Response
1
of items to the waiter
The waiter selects the items
required by the customer and
specify for each item the
Request
1
recommended quantity and
customer's comment
The mobile app sends the
selected items, the
recommended quantities and
Response
1
customer's comments to the web
application
The web application creates the
Request
1
new order
FS(FP 2: Add an order) = 20 CFP
The waiter presses the
Request
1
option “Modify an order”
The web application returns
Response
1
the list of places
The mobile app displays the
Request
1
list of places to the waiter
The waiter chooses the place
where the customer is
Request
1
installed
36
The mobile app sends the
selected place to the web
Response
1
application
The web application returns
Request
1
the list of tables
The mobile app displays the
Response
1
list of tables to the waiter
The waiter chooses the table
where the customer is
Request
1
installed
The mobile app sends the
selected table to the web
Response
1
application
The web application retrieves the
list of items recommended by the
Request
1
customer with their quantities
and comments
The mobile app displays the
items recommended by the
Response
1
customer with their quantities
and comments to the waiter
The waiter adds/deletes the
new/existing item, modifies
Request
1
items' quantities or modifies
items' comments
The mobile app sends the
Response
1
modified items to the web
application
The web application updates
Request
1
the order data
The mobile app displays
Response
1
E/C messages from the web
application
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
FUR 3: Logon
Functional
Processes
FP 4:
Logon
Sub-Process Description
Enter username and password
The web application reads
username and password
Display Error/Confirmation
message
Action
Type
CFP
Request
DataRecovery
1
Response
1
1
FS(FP 4: Logon) = 3 CFP
37
FP 5: Add
a user
FP 6: View
the Users
list
FUR 4:
Maintain User
FP 7: View
User Data
FP 9:
Delete a
User
FP 10: Add
an Item
The Administrator enters the user
data (waiter)
The web application adds the new
user
Display Error/Confirmation
message
Request
1
DataPersist
1
Response
1
FS(FP 5: Add a User) = 3 CFP
The administrator selects to
Request
1
view the users list
The web application retrieves the
Data1
Users list
Recovery
The web application displays the
Response
1
Users list
Display Error/Confirmation
Response
1
messages
FS(FP 6: View the Users list) = 4 CFP
The Administrator selects the
Request
1
desired user (Waiter)
The web application retrieves user Data1
data from the Database
Recovery
The web application displays the
Response
1
data of the selected waiter
FS(FP 7: View User Data) = 3 CFP
The Administrator modifies the
1
Request
waiter data that can be changed
The web application saves the
1
DataPersist
change
FS(FP 8: Modify User Data) = 2 CFP
The Administrator chooses the
Request
1
waiter to be deleted
The web application deletes the
DataPersist
1
selected waiter
Display Error/Confirmation
Response
1
message
FS(FP 9: Delete a User) = 3 CFP
The Administrator enters the data
of the item
Request
1
The web application adds the new
item
DataPersist
1
Display Error/Confirmation
message
Response
1
FS(FP 10: Add an Item) = 4 CFP
FUR 5:
Maintain Item
FP 11:
View the
items list
FP 12:
View an
Item data
The administrator selects to
Request
1
view the items list
The web application retrieves the
Data1
items list
Recovery
The web application displays the
Response
1
items list
Display Error/Confirmation
Response
1
messages
FS(FP 11: View the items list) = 4 CFP
The Administrator selects the
Request
1
desired item
The web application retrieves the
Item data from the Data base
DataRecovery
1
38
FP 14:
Delete an
Item
FP 15: Add
an item
family
FP 16:
View the
Item
families
list
FUR 6:
Maintain Item
family
FP 17:
View an
Item family
data
FP 19:
Delete an
item family
The web application displays the
data of the selected Item to the
Response
1
Administrator
FS(FP 12: View an Item data) = 3 CFP
The Administrator modifies the
desired fields and asks the web
Request
1
application to update the data of
the item
The web application saves the
DataPersist
1
change
FS(FP 13: Modify an Item) = 2 CFP
The Administrator selects the item
Request
1
to be deleted
The web application deletes the
DataPersist
1
selected item
Display Error/Confirmation
Response
1
message
FS(FP 14: Delete an Item) = 3 CFP
The Administrator enters the data
of the item and instructs the web Request
1
application to validate the addition
The web application adds the new
DataPersist
1
item family
Display Error/Confirmation
Response
1
message
FS(FP 15: Add an item family) = 3 CFP
The administrator selects to
Request
1
view the item families list
The web application retrieves the
Data1
item families list
Recovery
The web application displays the
Response
1
item families list
Display Error/Confirmation
Response
1
messages
FS(FP 16: View the Item families list) = 4 CFP
The Administrator selects the
Request
1
desired Item family
The web application retrieves the
Item family data
DataRecovery
1
The web application displays the
data of the selected Item family to Response
1
the Administrator
FS(FP 17: View an Item family data) = 3 CFP
The Administrator modifies the
desired fields and instructs the web
Request
1
application to update the data of
the item family
The web application saves the
DataPersist
1
change
FS(FP 18: Modify an item family) = 2 CFP
The Administrator selects the
Request
1
family items to be deleted
The web application deletes the
DataPersist
1
selected family item
Display Error/Confirmation
Response
1
message
39
FP 20: Add
a Place
FP 21:
View the
Places list
FP 22:
View a
Place data
FS(FP 19: Delete an item family) = 3 CFP
The Administrator adds the place
Request
1
data
The web application adds the new
DataPersist
1
place
Display Error/Confirmation
Response
1
message
FS(FP 20: Add a Place) = 3 CFP
The administrator selects to
Request
1
view the places list
The web application retrieves the
Data1
Places list
Recovery
The web application displays the
Response
1
Places list
Display Error/Confirmation
Response
1
messages
FS(FP 21: View the Places list) = 4 CFP
The Administrator selects the
Request
1
desired place
The web application retrieves the
Place data from the Data base
FUR 7:
Maintain
Place
FP 25: Add
a Table
FUR 8:
Maintain
Table
FP 26:
View the
Tables list
FP 27:
View table
1
The web application displays the
data of the selected Place to the
Response
1
Administrator
FS(FP 22: View a Place data) = 3 CFP
The Administrator modifies the
place data that can be changed
FP 24:
Delete a
place
DataRecovery
Request
1
The web application saves the
DataPersist
1
change
FS(FP 23: Modify a place) = 2 CFP
The Administrator chooses the
Request
1
place to be deleted
The web application deletes the
DataPersist
1
selected place
Display Error/Confirmation
Response
1
message
FS(FP 24: Delete a place) = 3 CFP
The Administrator adds the table
Request
1
data
The web application adds the new
DataPersist
1
table
Display Error/Confirmation
Response
1
message
FS(FP 25: Add a Table) = 3 CFP
The administrator selects to
Request
1
view the tables list
The web application retrieves the Data1
Tables list
Recovery
The web application displays the
Response
1
Tables list
Display Error/Confirmation
Response
1
messages
FS(FP 26: View the Tables list) = 4 CFP
The Administrator selects the
Request
1
desired table
40
data
FP 29:
Delete a
Table
FP 30: Add
a Menu
Items
FP 31:
View the
Menu
Items list
FUR 9:
Maintain
Menu Items
FP 32:
View a
Menu
Items Data
FP 33:
Modify a
Menu
Items
FP 34:
Delete a
Menu
Items
FP 35:
The web application retrieves the
Table data from the database
DataRecovery
1
The web application displays the
data of the selected table to the
Response
1
Administrator
FS(FP 27: View table data) = 3 CFP
The Administrator modifies the
Request
1
table data
The web application saves the
DataPersist
1
change
FS(FP 28: Modify table data) =2 CFP
The Administrator chooses the
Request
1
table to be deleted
The web application deletes the
DataPersist
1
selected table
Display Error/Confirmation
Response
1
message
FS(FP 29: Delete a Table) = 3 CFP
The Administrator enters the menu
Request
1
items data
The web application adds the new
DataPersist
1
menu items
Display Error/Confirmation
Response
1
message
FS(FP 30: Add an Menu Items ) = 3 CFP
The administrator selects to
Request
1
view the menu Items list
The web application retrieves the
Data1
Menu Items list
Recovery
The web application displays the
Response
1
Menu Items list
Display Error/Confirmation
Response
1
messages
FS(FP 31: View the Menu Items list) = 4 CFP
The Administrator selects the
Request
1
desired menu items
The web application retrieves the
Data1
menu items data
Recovery
The web application displays the
data of the selected menu items to Response
1
the Administrator
FS(FP 32: View Menu items Data) = 3 CFP
The Administrator modifies the
menu items data that can be
Request
1
changed
The web application saves the
DataPersist
1
change
FS(FP 33: Modify a Menu items) = 2 CFP
The Administrator selects the
Request
1
desired menu items
The web application deletes the
DataPersist
1
selected menu items
Display Error/Confirmation
Response
1
message
FS(FP 34: Delete a Menu Items) = 3 CFP
The administrator selects to
Request
1
41
View the
List of
Orders
FUR 10:
Manage the
List of Orders
FP 36:
Delete an
order data
view the orders list
The web application retrieves the
Data1
orders data
Recovery
The web application displays the
Response
1
list of orders
Display Error/Confirmation
Response
1
message
FS(FP 35: View the List of Orders) = 4 CFP
The administrator selects the order
Request
1
to be deleted
The web application deletes the
DataPersist
1
selected order
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.
42
REFERENCE
COSMIC (2015a) Guideline on Non-Functional & Project Requirements : How to consider nonfunctional 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.
43
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>] [<OutParameter>]
End
AS /* Alternative scenario */
Begin<Event, begin at Num "action number">
<NumAction> [<Pre-condition>] <Actor|System><Type: Request, DataPersist,
Expletive, Response, DataRecovery><Action Description> [<Int-Parameter>] [<OutParameter>]
The main scenario back to NUM
End
ES /* Error scenario */
Begin<Event, begin at Num "action number">
<NumAction> [<Pre-condition>] <Actor|System><Type: Request, DataPersist,
Expletive, Response, DataRecovery><Action Description> [<Int-Parameter>] [<OutParameter>]
End
End Use Case
Special requirements:<list of non-functional requirements>
44