Choosing Between a Use Case and Threads / Scenarios

By Ron Kratzke, Vitech Principal Systems Engineer

Recently we had a couple of customer questions regarding when to employ a Use Case and when to develop a Thread or a Scenario. There is no hard and fast answer to this question and much of what you should develop depends on information provided by stakeholders and/or users and individual organization system engineering process.

There are many definitions for the terms Use Case, Thread, and Scenario spread across a number of technical and academic publications.  In addition, your particular organization and system design processes probably have unique definitions, traced to a technical reference which fits your application and practice. [more]

In our training courses we look at these terms in a general context as follows. A Thread or a Scenario is used for understand system behavior under an assumed set of conditions. In particular, we limit “threads” to mean a single stimulus response behavior for the system under a given set of conditions. For example, in the Vitech training class, we examine how the Geospatial Library would behave if the product requested by the customer is in inventory. Each thread is developed under very specific conditions. (For example: when developing the thread for “Product in Inventory,” we don’t consider how we would tell a collector to get the image, because this is not needed to fulfill the conditions of the particular thread.)

A Scenario may include more than one set of stimuli, which means an added layer of complexity will be included in the behavior analysis and resultant behavior diagrams.

The Use Case takes a bit perspective on the system. A use case generally takes a “black box approach” to convey how the external actors and components interact with the system of interest. A use case is generally developed from a Concept of Operation or an Operational Concept document which has been written by the system user or stakeholder. In developing a Use Case the system engineer analyzes the Concept of Operation or Operational Concept to identify external actors (captured in the COMPONENT Class in CORE) and  subordinate behavior of the system with the external actors.  

Once identified, a use case implies a set of system requirements and functionality. We relate use cases in CORE to system design elements by relating the use case to system requirements using the elicits relation and to functions using the elaborated by relation.   

On some larger projects, particularly major acquisition programs for the Department of Defense, there is significant emphasis on Operational Scenario development. This analysis examines the system behavior under defined operational scenarios. System use cases might be determined from the operation scenario and then mapped into desired system level requirements and functions.

It is not mandatory or required that all of these artifacts (use case, thread, and scenario) be developed when designing a system. The user needs to determine what best fits the needs of the project stakeholders, provides the desired insight into top-level system design, and which items will resonate with the customer. Ultimately, whether developing and documenting use cases, threads, or scenarios, these artifacts should be related to requirements and functions in the system design architecture.

The CORE System Definition Guide provides additional discussion on development of use cases and threads. If you are looking for additional reference material on use cases, any of the recent SysML books provide a chapter on Use Case development. Additionally, many graduate level systems engineering textbooks discuss development of threads, scenarios, and use cases. An overview of thread development is also presented in A Primer for Model-Based Systems Engineering

Leave a Reply