=Paper=
{{Paper
|id=Vol-2545/paper7
|storemode=property
|title=Hidden-use Case for Eliciting Quality in Use (short paper)
|pdfUrl=https://ceur-ws.org/Vol-2545/paper-07.pdf
|volume=Vol-2545
|authors=Natsuko Noda,Tomoji Kishi,Shinichi Fukuzumi
|dblpUrl=https://dblp.org/rec/conf/apsec/NodaKF19
}}
==Hidden-use Case for Eliciting Quality in Use (short paper)==
https://ceur-ws.org/Vol-2545/paper-07.pdf
Hidden-use Case for Eliciting Quality in Use
Natsuko Noda Tomoji Kishi Shin'ichi Fukuzumi
Shibaura Institute of Technology Waseda University RIKEN
Tokyo, Japan Tokyo, Japan Tokyo, Japan
nnoda@shibaura-it.ac.jp kishi@waseda.jp shin-ichi.fukuzumi@riken.jp
Abstract— Finding use cases and developing a use case specifications; that is a use case model, consists of actors and
diagram is one of the most powerful techniques for eliciting and use cases.
specifies requirements. However, the notion of use case cannot
handle the needs of indirect users correctly, because the use case The concept and the notation for the model are adopted in
only describes the direct interaction between the system and the the UML. The definition of the use case is almost same as
actors. In this short position paper, we describe our ideas about Jacobson’s. According to the specification of the UML [2],
extension of the concept of use case and use case description, to each use case specifies some behaviors that a subject (target
describe and analyze the needs of the indirect users. system) can perform in collaboration with one or more actors.
Keywords— quality in use, indirect user, use case, use case In use case models, actors may be various stakeholders;
diagram, quality model not only (narrowly defined) users, but also maintainers,
system operators, outside systems, and so on. Fig.1. shows a
I. INTRODUCTION sample of use case diagram. In this diagram, “Customer”,
Eliciting requirements is important and at the same time “Administrator”, and “Bank” are actors. “Customer” is a type
very difficult. If there is any requirement that is hidden and of ordinary user, “Administrator” and “Bank” are more
not described explicitly, appropriate software cannot be general users in broader meaning.
developed. However, digging up all requirements and
expressing them explicitly is hard.
For this task, finding use cases [1][2] and developing a use
case diagram [2] is one of the most powerful technique. A use
case is a description of an interaction sequence between actors
and a target system. It expresses a behavior of the system.
Therefore, it exposes necessary functions of the system. It
does not describe any quality requirement directly, but it
makes it easy to consider necessary quality attributes along
with the interactions indicated by it; e.g., the system must
respond in 1 msec at this step in this use case.
Quality requirements are ideally considered and organized
in reference to the quality models, which are standardized in
ISO/IEC 25010:2011 [3], one of the SQuaRE series. The
models are the product quality model and the quality in use
model. Quality in use is the quality that a stakeholder
recognize when he/she utilizes a system. The stakeholder may
be of a various type. In the SQuaRE, stakeholders include an
indirect user, who receives output, but does not interact with
the system. Fig. 1. Sample use case diagram (from [2])
To consider the needs of the indirect users, can we utilize As the definitions and this sample shows, actors may be
the concept of use cases and use case diagram? Maybe no; a various types of stakeholders. In this sense, the use case and
use case describe an “interaction” sequence between actors use case diagram of UML handle various types of
and a target system, and indirect users do not have interaction stakeholders as actors. However, these actors must interact
with the system. However, these indirect users may relate to with the system. A stakeholder who does not directly interact
an interaction occurred in a specific use case, because the with the system cannot be an actor.
indirect users receive output, which is produced only when the
system is used. Considering this situation, how about Each use case is a grouped functions that the system (the
enlarging the concept of the use case and extending the use subject in use case diagrams) provides. Therefore, use cases
case diagram? and use case diagrams are suitable to analyze and specify
functional requirements. On the other hand, non-functional
In this short position paper, we describe our ideas about requirements are not described directly by use cases. We need
extension of the concept of use case and use case description. other techniques to describe those requirements. However,
use cases help us to analyze non-functional requirements,
II. USE CASE especially quality requirements along with the use case
The notion of use cases was originally introduced by scenarios.
Jacobson [1]. According to his definition, a use case is a
special sequence of transactions in a dialogue with the system, III. STAKEHOLDERS IN QUALITY IN USE MODEL
that will be performed by a user. This kind of user is called as In SQuaRE, various types of stakeholders are taken into
an actor. Jacobson also introduced a model for requirement account; users, developers, regulators, and society. In these
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
stakeholders, users are mostly related to the quality in use • Type 2: its effect appears from the behavior of the
model. In ISO/IEC 25010:2011, the following types of users actor who received the output of the corresponding use
are considered [3]. case. For example, if the use case “ask schedule” is
executed and the actor can meet the schedule because
• Primary user: person who interacts with the system to of the exact information produced by the use case “ask
achieve the primary goals. schedule, ” an indirect user “Supervisor” of the actor
• Secondary user: person who provides support, for may meet a team schedule. However, this result cannot
example be obtained only with the result of the original use
a) content provider, system manager/administrator, case; if the actor does not meet its schedule even with
security manager; the exact information produced by the use case, the
b) maintainer, analyzer, porter, installer. supervisor may not meet a team schedule. The effect
depends on the response of the actors to the original
• Indirect user: person who receives output, but does use case.
not interact with the system.
This categorization is only from the one viewpoint. There
These users’ needs have to be considered in requirements may be other various categorization. For example;
definitions and specifications. For these processes, use cases
and use case diagrams can be utilized, as described in the • A hidden-use case that is related to the original purpose
previous section. of the original use case. “meet schedule” may be one
of this type.
Primary users can be obviously actors of use cases. Their
needs can be analyzed along with the use cases related to • A hidden-use case that is as a side effect of the original
corresponding actors. Even though functions for secondary use case. “hear sound” may be one of this type.
users sometimes tend to be left out of essential services the
• A hidden-use case that is produced as the result of the
system provides that are easily considered as use cases,
wrong usage of the original use case.
secondary users can also be actors, since they interact directly
with the system. The notion of use cases does not exclude • A hidden-use case that may be a misuse case [4].
services for these secondary users, and these services should
be considered using the notion of use cases. We don’t have to The above categorization is the only example. We have to
enlarge the notion; we utilize this for the secondary users. consider more explicit and accurate viewpoint to categorize
However, indirect users cannot be actors, because they do not hidden-use cases.
interact with the system. When we consider quality in use
related to indirect users, the concept of use case is difficult to
be used.
IV. HIDDEN-USE CASE
To tackle the issue described in the previous section, we
are trying to enlarge the concept of the use case and extending
the use case diagram.
We introduce a new concept of “hidden-use case.” A
hidden-use case describes an effect that the subject (the
system) provides to indirect users of the subject. The hidden-
use cases may include behaviors of the system and send results
of the behaviors unilaterally to the indirect users. They do not
interact with any users; if they provide any effect to indirect
users, the indirect users do not respond to the subject.
Hidden-use cases cannot exist without use cases and actors.
They appear in consequence of the execution of ordinary use
cases. For example, when the direct user of an AI assistant Fig. 2. Enhanced use case diagram with the notion of “hidden-use case”
service execute the use case “ask schedule” of the service, a
person around the direct user may hear sound from the service. Now we are trying to define the notation of the hidden-use
Here, “hear sound” is a hidden-use case of this AI assistant cases and to enhance the use case diagram. Fig. 2 shows an
service. The person around does not interact with the service, example of the enhanced use case diagram by our first draft
but the person may hear sound. And this “hear sound” hidden- notation. A dashed ellipse is a hidden-use case. Indirect users
use case never exists without the use case “ask schedule” are shown using the same symbol of actors. A hidden-use case
trigged by the direct user. is connected to indirect users with a dashed line. A type 1
Hidden-use cases may be categorized in two types; hidden-use case is connected to the original use case with a
line and is placed in the subject. A type 2 hidden-use case is
• Type 1: its effect appears only from the system. In connected to an association between the original use case and
“hear sound” hidden-use case, this effect may be an actor. The indirect user of this hidden-use case depends on
produced directly in the consequence of the use case the actor of the original use case; therefore, the indirect user is
“ask schedule.” The actor “Owner” triggers the use connected to the actor with the dependency association.
case, but the actor never works over the produced
effect of the use case, before this effect reaches to the This notion of the hidden-use case and the enhancement of
“person around.” the use case diagram with the hidden-use case may make the
usage of the system clear. It is expected that we can analyze In the workshop, we would like to discuss the issues
and specify qualities in use, especially those related to indirect related to quality in use based on our idea described in this
users. paper.
Also, we expect that this hidden-use case concept will help REFERENCES
to re-consider various qualities in use and to re-organize the [1] I. Jacobson, Object-Oriented Software Engineering: A Use Case
model of qualities in use. Driven Approach. Addison-Wesley Professional, 1992
[2] Object Management Group, OMG Unified Modeling Language (OMG
V. CONCLUSION UML) Version 2.5.1, 2017
In this short position paper, we introduce a new unique [3] International Organization for Standardization, ISO/IEC 25010:2011
notion of hidden-use case and an enhancement of use case SQuaRE -- System and Software Quality Models, 2011
diagram with this notion. This is just a first draft; we have to [4] G. Sindre and A. L. Opdahl, "Eliciting Secutiry Requirements by
consider more deeply and refine the idea. Misuse Cases", Proc. TOOLS Pacific 2000, pp 120-131, 20-23 Nov
2000.