So you have Use Cases, Now What?

1. So you have Use Cases, Now What? • Biography - Malcolm Currie UCLA: Control Systems Engineering Ph.D. Engineering Consultant - Aerospace and Commercial: Lear Seigler, Rockwell, Hughes, Boeing, Rocketdyne, Schindler Elevator, … Missile/Aircraft guidance, navigation, and control systems; Military Systems requirements; Elevator and Security Systems control software, … Member of IEEE, GNSS, INCOSE … • Over 14 years experience in UML So You Have Use Cases – Now What?

2. Why Learn Experientially? • Every abstract idea can be learned in a concrete way. • Maria Montessori. So You Have Use Cases – Now What?

3. Develop Requirements • How many of you are knowledgeable of elicitation and development of requirements for a system? • Divide yourselves up into groups of 4 or 5 in each group with some of those experienced people in each group. So You Have Use Cases – Now What?

4. What is a Use Case? • A UC (Use Case) for a system is a description of something that the system does for an entity outside of the system • (referred to as an actor because the entity plays a role in its interaction with the system). • A UCD (Use Case Diagram) shows the UCs of the system and their communication paths with the actors • A UCD is a context diagram of a system • An important part of a UCD is the system boundary • A Use Case is much more than a UCD (Use Case Diagram) So You Have Use Cases – Now What?

5. Why have Use Cases? • Many organizations have adopted Use Cases. • Good start: but do they also build executable models of the Use Cases? • Executable models clearly define the interfaces between the system and its environment in each one of its intended uses. • Is this done functionally before allocating the functions to specific parts? So You Have Use Cases – Now What?

6. What is a Use Case – In More Detail? • A UC (Use Case) for a system is a description of something that the system does for an entity outside of the system • As such, A UC if a functional requirement – not a “requirement statement” • which is often referred to as a “requirement”. • A UCD (Use Case Diagram) shows the UCs of the system and their communication paths with the actors. • An important part of a UCD is the system boundary. So You Have Use Cases – Now What?

7. What is a Use Case Description? • A Use Case is much more than a UCD (Use Case Diagram). • The UC description includes • what the system does, • why it does it, and • the value the system provides to the (primary) actor. • The description may include a UCD • shows the context of the UC with its environment (the actors). • A Use Case has a description sufficient to build an executable model of the system at whatever level of detail is needed during phases of system development. • A Use Case describes how the system will be used • before the system exists. As such, it describes a test of a planned system. • It allows management and customers to understand what they will be building • It is a means to understand what progress is being made during development. • If an executable model is built of the system and of its environment, this model can evolve into a test harness of the system. So You Have Use Cases – Now What?

8. What might be the Use Cases for an elevator? • Let’s get a list of some of the possible Use Cases of an elevator as an example, assuming that the elevator is installed: • Startup • Describes how to apply power safely • Transport Passenger • Describes the Passenger experience from calling a car on one floor to exiting the car on a destination floor. • Respond to Emergency • Fire persons need special access to elevators that override normal Passenger services. • Can you think of any more? • We will revisit this a little later. So You Have Use Cases – Now What?

9. How do I describe the Use Case? – Elevator Example • The Use Case is a functional description of the system from a user’s viewpoint. • How would a Passenger use and elevator? • The Transport Passenger Use Case would follow a scenario such as the following: • Request a car • Monitor indications of car status until it arrives and the doors open • Enter the car and perhaps interact with the car from inside • Monitor the car doors closing • Monitor indication of the car progress to the destination floor • Monitor the car doors opening • Exit the car. • Car doors close So You Have Use Cases – Now What?

10. Is that all there is?– Elevator Example • The listed scenario is sufficient for a simple, well understood, system. • For a more complex system, we can describe the scenario in a tabular form or use other UML diagrams • Message Sequence Diagram, • Statechart, or • Activity Diagram). • In addition, we need other attributes of a Use Case • such as preconditions and post conditions. So You Have Use Cases – Now What?

11. How would I get Use Cases for a system? • How is a Use Case elicited? • To elicit the set of Use Cases for a system, ask the customer what he will do with the system. • Imagine the system exists and after he has it up and running (one of the Use Cases is to do this), what do you want to do? • Get back into your groups and compose a list of UCs for an elevator. • What are the actors? • Draw a UCD for the elevator. So You Have Use Cases – Now What?

12. What might we have for Use Cases for an elevator? • Let’s use an elevator as an example and get a list of possible Use Cases assuming the elevator is installed: • Startup • – Describes how to apply power safely • Transport Passenger • – Describes the Passenger experience from calling a car on one floor to exiting the car on a destination floor. • Respond to Emergency • – Fire persons need special access to elevators that override normal Passenger services. • Provide Software Maintenance Services • – Allow for installation and test of software upgrades. • Provide Hardware Maintenance Services • – Allow for installation and test of hardware upgrades. So You Have Use Cases – Now What?

13. Description of the Elevator Transport Passenger Use Case • Include the preconditions for the Use Case • – e.g., the elevator must be operating in the Passenger Service Mode (which is carefully defined). • Include some post-conditions for the Use Case • – e.g., the elevator doors are closed and system is waiting for another passenger request (in the Passenger Service Mode). • This Use Case description is for the Primary Scenario of the Transport Passenger Use Case • not complete – needs some more formality • What if the power fails at any of these steps? • What if a fire alarm overrides the passenger request? • These are analyzed with Secondary Scenarios • – not discussed here. So You Have Use Cases – Now What?

14. How would you use a Use Case? • Now what • after you have the Use Case described in text? • Another UML diagram that describes behavior is a SD (Sequence Diagram • or more explicitly, Message Sequence Diagram • A SD describes interactions (messages) between objects (e.g., system and actors) in time • – along vertical lifelines, • one lifeline for each object. • This is one of the other diagrams that are usually used to further describe the scenarios • - the other one is an Activity Diagram. • It is even possible to use both of these diagrams. • The SD will be described here because it is executable in many tools • an executable Activity Diagram is only recently becoming available. So You Have Use Cases – Now What?

15. How would you use a Use Case for Elevator? • The SD uses interactions between Objects • in this case a passenger and the elevator is the primary concern. • The passenger is external to the system • In UML terminology is referred to as an Actor • The passenger plays a role in the scenarios of a Use Case. • The system, at the top level, is the elevator • Later, the system can be divided into objects • that are functional (for conceptual analysis) or • physical (when a design is known) • – this is not addressed here. So You Have Use Cases – Now What?

16. How would I use a SD ({Message} Sequence Diagram)? • Each UC will usually have only one primary SD and several secondary SDs • to support alternative and exceptional behavior of the system • - not described here. • Each SD may have several depths which are nested into the base diagram • A top level SD for a UC shows the interaction of the system with its actors for a specific UC. • The interactions in a SD (or message sequence diagram) are via messages passing between the actor and the system. • The messages are arranged chronologically (without a time scale) down a vertical lifeline. • The system in each top level SD for each UC can be expanded to show the components of the system that supports that UC • either conceptual or physical components of the system that support that UC, • A top level SD for one UC should not show all levels of the components. • Any modern UML tool allows the interaction of the components to be exposed by clicking on the system object in the system SD • and recursively to each lower level of detail). So You Have Use Cases – Now What?

17. How would I use a SD? (2 of 2) • The interaction of the components of the system at the next lower level can be described on that supporting SD. • This nesting is recursive to whatever level of detail is required to describe the system behavior. • A SD can also show the states of the components along the lifeline • from a Statechart (one of the other UML behavior diagrams). • Subsequences can be shown on a SD, much like subroutines in a sequential computer program. • These two features of a SD are not discussed further herein. • Get into your groups again • Draw a primary SD for the Elevator Transport Passenger UC. • Are you making design decisions? • If so, list them. So You Have Use Cases – Now What?

18. Why did I choose a SD? • Many UML tools have executable SDs • I was using them in 1994 to reduce integration test times to hours for a several month project. This was even before UML 1.0 was released. • The desired SD can be put into a UML tool. • The system model can be entered with objects • (instances of composite classes) and executed to generate a SD. • Any differences between the executed SD and the desired SD are shown, not only from comparing the SDs, are shown in an exception report. • The stakeholders are thus assured that the desired behavior is captured in the model before any implementation begins. • A SD is easy to understand, especially by hardware people • they have always used objects in their designs, calling them blocks. • Systems engineers often do not distinguish explicitly between classes and objects. • An alternator for a car is a class, whereas an alternator for the car is an object • It is only a matter of the grammatical article that is different • a definite or indefinite article, the or a/an, respectively. • A requirements statement that does not recognize this distinction can be ambiguous. So You Have Use Cases – Now What?

19. Executable SDs communicate between stakeholders • Executable SDs are essential to communicate requirements between stakeholders • Validation is said to be building the right system. • Verification is building it right. • How do you know you are building the right system? • How will you show it? • Executable SDs (Sequence Diagrams) can demonstrate the functionality of Use Cases early in a development program to greatly increase the likelihood that the right system is built. • If you do not know enough to build an executable model, how can you possibly begin to build the real system? • Save time. Save money. Make your customer happy. • Adopt Use Cases to scope and control your project from concept to acceptance test. • Use SDs to execute /document the system functional requirements. • Use classical requirement statements to control the non-functional requirements. So You Have Use Cases – Now What?

20. Why didn’t I use SysML? • I did not use SysML because I did not need it • all of the structure and behavior elements of UML are sufficient for building executable models of systems as long as the vocabulary of UML is understood. • E.g., as mentioned above, what is an object and how does it differ from a class. So You Have Use Cases – Now What?

21. What if we had Use Cases and Primary Sequence Diagrams? • Up front Communication: • customer, management, developers, testers • And continuing Visibility of the project • Define when we are done • before beginning building anything (HW, Sw, and Test) • Executable models • Test harness of prototypes • Test Management • Test Planning – begin with the end in mind– by UC/Functionality • Pretest Simulation - reference results • Test harness – plug and play • Test Progress monitoring • visibility and known goal • calibrate and reschedule (Agile) • Prioritize development of the important functionality • Incremental development – by Use Case/ Functionality • Manage schedule – calibrate and reschedule • Faster learning of new people on program • visibility and known goal So You Have Use Cases – Now What?

22. So you have Use Cases, Now What? • Retrospective questions So You Have Use Cases – Now What?

23. Have you experienced any changes? • Does this ever happen at work? • How do you feel about Use Cases now that is different from how you felt before we started? • How do you think about Use Cases that is different from how you thought about it before we started? • What have you learned in this session? • How did you do the exercise? • i.e., what techniques did you use? • What haven't we talked about yet? • How did you come to be here? • How do you feel about being here? So You Have Use Cases – Now What?

24. What will you remember from this experience? • What did you notice about this period of time? • What is happening for you? • Was there anything that was challenging to you? • Was there anything that was fun for you? • What's the first thing you want to say about this exercise? • What's the first thought you would like to share about this experience? So You Have Use Cases – Now What?

25. What reactions or questions do you have? • What surprised you? • What would you want to repeat from the exercise? • What would you want to omit from this exercise? • What pleased (puzzled, frightened, displeased, tickled, angered, any other emotion) you about the experience? • What question do you prefer we wouldn't ask? • Do you know why you didn't want to be asked that? • What question do you want me to ask? • Do you know why you want to be asked that? • What are your future plans for this exercise? • If you had that, what would that do for you? So You Have Use Cases – Now What?

26. How might this experience be used for you in your work/life? • What makes that a problem for you? • Then what happens? • What did you see and hear? • What is it like to answer these questions? • Did this exercise go on too long, too short, or just right? • Has this ever happened to you at work? • What do you do at work when it happens? • Would you like to learn how to be different? • Would you like to learn a different way to do this? So You Have Use Cases – Now What?

27. What else did you learn about yourself? • What do you want to know about yourself? • Did the exercise suggest any ways you could do that? • How are you now interpreting the word requirement? • Did drawing allow you to process your experience fully? • Do you want to talk about it as well? • What did you learn by observing that? So You Have Use Cases – Now What?

28. Summary • Why would you want to elicit and develop functional requirements with Use Cases? • Do you recognize the value of executable models? • Can you visualize the enormous savingsin time, energy, frustration, and miscommunication that can be realized in Integration Testing alone with the proper application of Use Cases? • a major cost in most projects So You Have Use Cases – Now What?

29. Final thoughts • Expect change - and plan for it. • "Wisdom is not what comes from reading great books.When it comes to understanding life, experiential learning is the only worthwhile kind - everything else is hearsay" • Joan Erikson So You Have Use Cases – Now What?

30. Special Thanks! • Malcolm Currie • SEC_Services@Earthlink.net; 310 821-3081 • Special Thanks to SPIN Leaders, especially • Yolanda De Oro • Warren Schein • And to NGC and CSULB for Sponsoring the SoCal SPIN So You Have Use Cases – Now What?