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.