Explore chapters and articles related to this topic
Establishing the Risk Status of the Corporate Infrastructure
Published in Dan Shoemaker, Anne Kohnke, Ken Sigler, How to Build a Cyber-Resilient Organization, 2018
Shoemaker Dan, Kohnke Anne, Sigler Ken
Use case diagrams are organized collections of scenarios that are derived from the business rules and actions taken by the various users of a system. They focus on what the system can do or its purpose within the organization. Use cases map out the actors, business activities or processes, flow of events, and post-conditions or alternative paths, and focus on the functionality of the components of a software application or system. They can be helpful ways to graphically illustrate the business requirements and who will be using the various functionalities of the software or system. In threat modeling, it is helpful to take a use case diagram and extend them to add the identified threats in which an attacker may engage. The addition of threats to a use case turns it into a misuse case diagram. An example of a misuse case diagram can be seen in Figure 3.6.
Scenario-Based Design
Published in Julie A. Jacko, The Human–Computer Interaction Handbook, 2012
Mary Beth Rosson, John M. Carroll
Scenarios have also come to play a central role in object-oriented software engineering (Alexander and Maiden 2004; Jacobson 1995; Jacobson, Booch, and Rumbaugh 1998; Rubin and Goldberg 1992; Wirfs-Brock, Wilkerson, and Wiener 1990). A use case is a scenario written from a functional point of view, enumerating all the possible user actions and system reactions that are required to meet a proposed system function (Jacobson et al. 1992). Use cases can then be analyzed with respect to their requirements for system objects and interrelationships. Wirfs-Brock (1995) describes a variant of use case analysis in which she develops a “user-system conversation”: using a two-column format, a scenario is decomposed into a linear sequence of inputs from the user and the corresponding processing and/or output generated by the system. Kaindl (2000) extends this analysis by annotating how scenario steps implement required user goals or system functions.
Smart Grid Roadmaps
Published in Clark W. Gellings, Smart Grid Planning and Implementation, 2020
A use case is a “story” that includes various “actors,” and the “path” they take to achieve a particular functional goal. By considering the actions of the actors working to achieve functional goals, a completed use case results in the documentation of multiple scenarios, each containing a sequence of steps that trace an end-to-end path. These sequential steps describe the functions that the proposed systems and processes must provide, directly leading to the requirements. The goals of the use case methodology as part of the SGRM are:Collect all requirements that will have an impact on the architecture
A supportive situation awareness model for human-autonomy teaming in collaborative driving
Published in Theoretical Issues in Ergonomics Science, 2020
Rinta Kridalukmana, Hai Yan Lu, Mohsen Naderpour
In software development, one technique that can be used to model the relation between functions is a use case diagram (see Figure 6), which was introduced by Jacobson (1993). In this technique, a use case that represents a function could have three types of relationships: a generalized relationship (GR), a normal relationship (NR) and an extended relationship (ER) (Chanda et al. 2009). A GR is intended to relate functions and their sub-functions. An NR between two use cases means that the behaviour of a use case is explicitly incorporated by another use case incorporating it (Shen and Liu 2003). When the behaviour is extended to another use case in the case of a special event, it can be described as an ER. Furthermore, an agent performing functions or sub-functions in a use case diagram is referred to as an actor, which can be either a human or non-human agent. A line is used to connect actors to functions or sub-functions.
Privacy risk in contact tracing systems
Published in Behaviour & Information Technology, 2023
Conceptual diagrams do not depict specific technologies and thus are technology-neutral, intended to apply regardless of any technology used. Conceptual diagrams are commonly used by systems analysts to understand, analyse and communicate aspects of an information system (Burton-Jones and Meso 2006; Wand and Weber 2002), including information risk (Mead et al. 2017; Spears and Parrish 2013). A use case diagram is a conceptual model that depicts how actors (i.e. participants) interact with core system functions. Figure 1 depicts a technology-neutral contact tracing system that may be manually performed and/or include a smartphone app for automating certain functions. There are ten use cases (i.e. system functions, represented as ellipses) and six unique actors in Figure 1.
Scenario-based collision detection using machine learning for highly automated driving systems
Published in Systems Science & Control Engineering, 2023
Marzana Khatun, Rolf Jung, Michael Glaß
The use case typically describes the functional scope, the desired behavior, and the functional system boundaries, including scene and scenario. A use case can consider single, double, or multiple functional scenarios. Use cases are therefore scenarios described at a more abstract level (ISO21448, 2022). The recent project (Winner et al., 2019) was considered as the basis to identify use cases. In this paper, lane changing on the highway is used as a use case for HAD systems. The use case is defined such that the ego-vehicle changes from the right to the left lane when there is another road user (vehicle) in the left lane. The ego-vehicle must take into account the corresponding parameters of the other vehicle when performing the lane change.