Spanning the Operational Space: How to Select Use Cases and Mission Threads
Definition: Use case in software engineering and systems engineering is a description of a system's behavior as it responds to a request that originates from outside that system. A use case describes "who" can do "what" with the system in question. The use case technique captures a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.
A mission scenario or mission thread is an instance type of a use case and represents a single path through the use case. Thus, you might construct a thread for the main flow through the use case and other threads for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches). Scenarios/threads may be depicted using sequence diagrams.
Keywords: behavioral requirements, functional requirements, mission description, mission execution, mission thread, operational requirements, process description, scenario, sequence diagram, software engineering, systems engineering, thread, UML, use case
MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to understand the purpose and roles of use cases and mission threads, where to employ them in an acquisition program life cycle, and the benefits and risks of using them. MITRE SEs are expected to understand when use cases and mission threads are appropriate to a situation and to develop detailed recommendations and strategies for using them. They are expected to monitor and evaluate contractor activities in using mission threads and use cases, as well as in the government's overall strategy, and recommend changes when warranted.
The use case technique captures a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.
A use case defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system that interact with the system. An actor may be a class of users, roles users can play, or other systems. A primary actor is one whose goal requires the system's assistance. A secondary actor is one from which the system needs assistance.
Mission threads are associated with one or more operational vignettes. A vignette describes the overall environment: the geography, organizational structure and mission, as well as strategies, tactics, and information on any protagonists, including their composition, strategies, tactics, and timing. Mission threads can describe tactical operations, logistical operations, support operations and maintenance, and training, test, and development operations. Mission threads serve as drivers for developing the architecture and as the basis for test cases during a verification cycle.
What They Are and When to Use Them
Use cases and mission threads are a useful mechanism for documenting an existing system's functionality or for establishing user needs for a new system. Use cases describe the system from the user's point of view and the interaction between one or more actors. (The interaction between the actor(s) and the system is represented as a sequence of simple steps.) Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events described from the point of view of the actor. One or more scenarios or threads may be generated from a use case. The aggregate of all threads documents the details of each possible way of achieving the system's goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert.
Use cases don't make much sense when dealing with simple tasks or systems. For example, there is no point in modeling a task flow of how a visitor can go to the "About us" page on a website. This is better done with site map diagrams. Use cases are primarily useful when dealing with more complex flows.
- Reflect functional requirements in an easy-to-read, easy-to-track text format.
- Represent the goal of an interaction between an actor and the system. (The goal represents a meaningful and measurable objective for the actor.)
- Record a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios).
- Record a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios).
- Are multilevel—one use case can use/extend the functionality of another.
Use cases do not:
- Specify user interface design—they specify the intent, not the action detail.
- Specify implementation detail (unless it is of particular importance to the actor for ensuring that the goal is properly met).
Use cases are used during many stages of software/system development:
- To capture systems requirements.
- To act as a springboard for the software/system design.
- To validate the design.
- For test and quality assurance to validate proper and complete implementation of the use cases.
- As an initial framework for the online help and user manual.
The use case model can be a powerful tool for controlling scope throughout a project's life cycle. Because all project participants can understand a simplified use case model, it can also serve as a framework for ongoing collaboration as well as a visual map of all agreed-on functionality. It can, therefore, be a valuable reference during later negotiations that might affect the project's scope.
Use case models can be used to:
- Document the business process.
- Illuminate possible collaborative business areas.
- Separate business processes into functional system areas. Identify possibilities of system or component reuse.
- Document requirements for system development (because they are defined in a non-implementation/easy-to-read manner).
- Categorize requirements (e.g., state of implementation, functional system).
- Rank requirements (e.g., level of importance, risk, level of interoperability).
- Publish requirements at various levels (e.g., detailed design requirements, hanger analysis requirements, document management, document creation requirements).
- Identify the effects of functional changes on implementation systems or of implementation changes on functional capabilities (because they are part of the object-oriented analysis and design process).
Best Practices and Lessons Learned
Validate use cases. Use cases are great for managing boundaries, exploring scope options, expanding scope, and controlling complexity, but it is very important that they be validated thoroughly. In reviewing use cases, ask the following questions:
- Is the use case complete? Do any details need to be added?
- Do I feel confident that the actor's goal will be properly met?
- Do I see any procedural or requirement changes that would simplify the process depicted in the use case?
- Are any goals of the actors not addressed?
- Are any actors not represented (directly or indirectly)?
Have enough use cases. When do you know you have all the use cases or enough of them for your purposes? The simple answer is you have them all when the users, sponsor, and other stakeholders cannot think of any more.
Develop use cases in a cooperative setting. Use cases can serve as a bridge between the needs of requirement analysts, designers, and system developers, but this will only happen if the use cases reflect the different views of the participants. Requirement analysts focus on client needs, interaction designers look at the operational user needs, and developers focus on the technological capabilities. If developed in a cooperative setting—and in context of budget and schedule—use cases can provide enduring utility.
Consider these common use case mistakes and pitfalls from Ellen Gottesdiener, a requirements expert and principal at EBG Consulting:
- Other important requirements representations are unused or underused.
- Use case goals are vague or lack clarity.
- Use case scope is ambiguous.
- Use case text includes nonfunctional requirements and user interface details.
- The initial use case diagrams excessively use "extends" and "includes."
- The use case shows inattention to business rule definition.
- Subject matter experts are not sufficiently involved in creating, reviewing, or verifying use cases.
- Preparation for user involvement in use case definition is insufficient.
- Too much detail appears too early in use case definition amid an expectation that it is a one-pass activity.
- You fail to validate or verify your use cases.
- You have too few use cases. You've described only a subsystem or a few duties of a few subsystems. You've missed the greater, essential application.
- You have gone too far. Your use cases represent wishful thinking well outside of the needs of the operational user. This is a form of "creeping featurism" in which you waste time on features you're not keeping and then spend more time culling the list when you realize what has happened.
- You captured the wrong use cases. You've got plenty and could do without some, but you can't do without some you've missed.
Maintain a list of ways in which the system may be parameterized. For example, vary the perceived importance of the actors, the types of input, future modes of operation, situations when good actors do bad things, and exceptional circumstances. Iterate through your use cases to see if they cover all the situations. This might help refine your use cases or discover new ones.
Examine your nonfunctional requirements (e.g., constraints) to see if your use cases can address them. You might be able to refine, add, or drop use cases based on this.
Make a semantic network diagram. Do a quick brainstorm of all the concepts and interactions and relationships from the problem domain. Decide which concepts fall within the system (will be part of the object model), which are on the boundaries (probably will become actors or usages), and which are beyond the scope of the system being modeled (do not affect the software system being built and don't show up in any of the modeling efforts).
Don't make premature assumptions about the interface. Use cases should be thought of as abstract prototypes. The interface is yet to be designed, and premature assumptions can constrain the design unnecessarily. This is particularly important if you are not going to design the interface yourself.
Don't describe the internal workings of the application/system. Use cases are tools for modeling user tasks; lots of other tools are more suitable for system modeling.
Stay focused on the business processes and not the information technology. Be clear that you and your sponsor agree on the issue or question being addressed. Focus on the users' challenges/issues. A multitude of use cases and mission threads can be pursued, but to do all of them would be unrealistic. Be sure to focus on and have objectives up front of the particular problem(s) that is being evaluated and solution(s) for that problem.
Be sure you have a firm grasp of the mission context. Thoroughly understand the end user's needs, concept of operations, and environment along with emerging threats, courses of actions, etc. (For example, don't use force-on-force techniques when perhaps anticipated future operations are insurgency oriented. Don't perform quick shock and awe in isolation when there is the potential for protracted operations.) Focus on the end users' needs and not on what an operational leader wants—keep the use cases as close to reality as possible.
Exercise due diligence by looking for other definitions on the Web and elsewhere that are similar or related. Given the paucity of existing, documented use cases or mission threads, the first lesson learned is how to find them. The second is that no one considers anyone else's work authoritative.
Consider the varying environments as a key aspect of the use case/mission thread. This includes geographical/climate environments, cultural/social environments, and even military service or agency organization environments. Remember that although we strive for cross-agency, joint, or multinational considerations, the reality is that individual departments and agencies often drive many aspects of a use case; the mission thread and these drivers need to be considered.
Understand the level of operation that is being examined. Put the particular use case in context across the full spectrum of operations.
Aim to have some form of simulated results that can feed into the use cases you're examining. Simulate the input and output from the use case to and from the integrated set of activities involved in the particular operation or aspect of the execution. Use stimulation triggers to interplay with the use case(s) or mission threads that are under closer examination.
Extend the use case/thread perspective across the full suite of systems engineering activities: architectures, development, testing, training/exercises, and experiments. These will help move you beyond simply testing the buttons of a capability to testing/exercising a capability in the context of the end users' requirements.
Solicit tools to help with use case/mission thread creation, management, and use. A variety of commercial and government tools can help capture the use case actors, scripts, and actions. There are also tools to capture the results of these activities from modeling and simulations or operator-driven exercises/experiments. Remember, it is not about the tool but about the process.
Share use cases and mission threads with others. Given the relatively wide perspective and encompassing value of use cases and mission threads across the systems engineering life cycle, there is value in employing use cases/mission threads in multiple systems engineering activities.
Don't believe that you have the greatest use cases/mission threads in the world. You probably don't, but you probably do have important pieces of the overall puzzle and value; share use cases and mission threads to increase the overall value of capabilities to the end users.
An important part of using use cases and mission threads is the results you get from architectures, testing, experiments, and exercises. Be sure to make your results very visible. Capturing and assessing the use case data and parameters take significant time. Make your analysis visible to others to use in exercises (perhaps physical exercises), models and simulations, etc. Seek out and contribute to use case/mission thread data repositories so your work can be used and reused across the systems engineering life cycle.
Remember to document. It is especially important to know who vetted your descriptions, what the scope of the analysis was, and who the user was. It is also important to provide references to any MITRE document that illuminates your work. Documentation is especially important when discussions occur later about scope.
References and Resources
Armour, F., and G. Miller, 2000, Advanced Use Case Modeling: Software Systems, Addison-Wesley Professional.
Bittner, K. and I. Spence, 2003, Use Case Modeling, Addison-Wesley Professional, pp. 2–3.
Carr, N., and T. Meehan, March 2, 2005, "Use Cases Part II: Taming Scope," A List Apart.
Cockburn, A., May 10, 2006, Use Case Fundamentals.
Cockburn, A., 2002, "Use cases, ten years later," Originally published in STQE Magazine, Mar/Apr 2002.
Cockburn, A., 2001, Writing Effective Use Cases, Addison-Wesley Longman, Boston, MA.
Denney, R., 2005, Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley Professional.
Department of Defense, May 28, 2015, DoD Instruction 5200.39, Critical Program Information (CPI) Identification and Protection Within Research, Development, Test, and Evaluation (RDT&E).
Gottesdiener, E., June 2002, "Top Ten Ways Project Teams Misuse Use Cases—and How to Correct Them, Part I: Content and Style Issues," The Rational Edge.
Jacobson, I., 1992, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley Professional.
Liddle, S., October 13, 2009, Comment on "Stakeholders for use case specifications," BYU Island, ISYS Core.
Software Engineering Institute, "Evaluating System of Systems Architectures: Mission Thread Workshop," accessed December 2009.