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 of that system. In other words, 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, one may 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, operational requirements, process description, sequence diagram, software engineering, systems engineering, UML

MITRE SE Roles & Expectations: MITRE systems engineers 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 systems engineers 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.

Introduction

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 having a goal requiring the assistance of the system. 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, 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, 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 to document an existing system's functionality or to establish 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 detail 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. 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.

Use cases:

  • 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 multi-level: 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 assurance 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 a simplified use case model can be understood by all project participants, it can also serve as a framework for ongoing collaboration as well as a visual map of all agreed-upon functionality. It can, therefore, be a valuable reference during later negotiations that might affect the project's scope.

Use case models can:

  • Document the business process.
  • Illuminate possible collaborative business areas.
  • Separate business processes into functional system areas.
  • Serve as requirements documentation for system development (because they are defined in a non-implementation/easy-to-read manner).
  • Identify possibilities of system or component reuse.
  • Be used to categorize requirements (e.g., state of implementation, functional system).
  • Be used to rank requirements (e.g., level of importance, risk, level of interoperability).
  • Be used to publish requirements at various levels (e.g., detailed design requirements, hanger analysis requirements, document management, document creation requirements).
  • Be used to 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

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? Are there any details that need to be added?
  • Do I feel confident that the actor's goal is going to be properly met?
  • Are there any procedural or requirement changes I can suggest that would simplify the process depicted in the use case?
  • Are there any additional goals of the actors that are not addressed?
  • Are there any additional actors that are not represented (directly or indirectly)?

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.

Use cases can serve as a bridge between the needs of requirement analysts, designers, and system developers. But this will only happen if the different views of the participants are reflected in the use cases. 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.

Ellen Gottesdiener, a requirements expert and principal at EBG Consulting, identifies the following common use case mistakes and pitfalls:

  1. Other important requirements representations are unused or underused.
  2. Use case goals are vague or lack clarity.
  3. Use case scope is ambiguous.
  4. Use case text includes nonfunctional requirements and user interface details.
  5. The initial use case diagrams excessively use "extends" and "includes."
  6. Use case shows inattention to business rule definition.
  7. There is insufficient subject matter expert involvement in creating, reviewing, or verifying use cases.
  8. There is insufficient preparation for user involvement in use case definition.
  9. Too much detail appears too early in use case definition amid expectation that it is a one-pass activity.
  10. You fail to validate or verify your use cases.

Gottesdiener identifies three other things that can go wrong when employing use cases:

  1. 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.
  2. 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 there is a danger of wasting time on features you're not keeping and then spending more time to cull the list when you realize what has happened.
  3. 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.

Other suggestions are:

  • Maintain a list of ways the system may be parameterized (vary the perceived importance of the actors, the types of input, future modes of operation, situations when good actors do bad things, 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 non-functional 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 (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 internal workings of the application/system. Use cases are tools for modeling user tasks; there are lots of other tools more suitable for system modeling.

Lessons from the Field

Stay focused on the business processes and not the information technology. Be clear that you and your customer 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 do force-on-force now when perhaps anticipated future operations are insurgency oriented. Don't do quick shock and awe in isolation when potential is 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 particular use cases you're examining. Simulate the input and output from the particular 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 particular use case(s) or mission threads that are under closer examination.

Extend the use case/thread perspective across the full suite of system 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. There are a variety of commercial and government tools to 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 system engineering life cycle, there is value in employing use cases/mission threads in multiple system 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. A lot of time is used in capturing and assessing the use case data and parameters. 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 system 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 & Resources

  1. Armour, Frank and Granville Miller, 2000, Advanced Use Case Modeling: Software Systems, Addison-Wesley Professional.
  2. Bittner, Kurt and Ian Spence, 2002, Use Case Modeling, Addison-Wesley Professional, pp. 2-3.
  3. Carr, Norm and Tim Meehan, 2 March 2005, "Use Cases Part II: Taming Scope," A List Apart.
  4. Cockburn, Alistair, 10 May 2006, Use Case Fundamentals.
  5. Cockburn, Alistair, 2002, "Use cases, ten years later," originally published in STQE magazine, Mar/Apr 2002.
  6. Cockburn, Alistair, 2001, Writing Effective Use Cases, Addison-Wesley Longman Publishing Co., Inc., Boston, MA.
  7. Denney, Richard, 2005, Succeeding with Use Cases: Working Smart to Deliver Quality, Addison-Wesley Professional.
  8. Department of Defense, 16 July 2008, DoD Instruction 5200.39, Critical Program Information (CPI) Protection Within the Department of Defense.
  9. Gottesdiener, Ellen, June 2002, "Top Ten Ways Project Teams Misuse Use Cases—and How to Correct Them, Part I: Content and Style Issues," The Rational Edge.
  10. Jacobson, Ivan, 1992, Object-Oriented Software Engineering, Addison-Wesley Professional.
  11. Liddle, Stephen, 13 October 2009, Comment on "Stake holders for use case specifications," BYU Island, ISYS Core.
  12. "MITRE Lean Six Sigma Community of Practice, viewed December 2009.
  13. Software Engineering Institute, "Evaluating System of Systems Architectures: Mission Thread Workshop," viewed December 2009.

Publications

Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Questions?
Contact the SEG Team