1. Use Cases CS 6961 – Lecture 4 Nathan Dykman

2. Neumont UniversityCS 322 - Lecture 102 Administration Homework 1 is due –Still reviewing the proposal, but so far, no problems. If you have questions, come talk to me. Any questions before we move onto the latest section?

3. Neumont UniversityCS 322 - Lecture 103 What we’ve covered We have discussed the basics of class in UML 2.0 –And applied them in a design exercise Now, we will be covering the basics of Use Cases –And how Use Cases can be used to document the requirements of a system.

4. Neumont UniversityCS 322 - Lecture 104 Requirements Gathering To be honest, we are not going into great depth into this topic –It is a whole area of study in CS in it’s own right. But, we should cover enough of it so that you can start writing your own use cases –For those doing a project, this will be your next assignment.

5. Neumont UniversityCS 322 - Lecture 105 Discussion What are software requirements? Have you worked with requirements before? Have you gathered your own requirements for a project? Why are requirements important to have? And so on.

6. Neumont UniversityCS 322 - Lecture 106 Software Requirements While there is a lot to be said about requirements are, I focus on the following aspect of requirements –Requirements document the functionality of a software system from the perspective of the users and stakeholders of that system. –There are many other aspects as well Non-functional requirements is an example of this.

7. Neumont UniversityCS 322 - Lecture 107 Use Cases Use Cases are a very common requirements gathering technique –Not the only one, but very popular There are many different approaches to use cases, but all have this in common: –Use cases are description of events in the system, described from the perspective of various actors in the system, that provide value to the actors in that system.

8. Neumont UniversityCS 322 - Lecture 108 Use-case Based Requirements Use-case based requirement documents are structured around the following: –Actors: The roles that are supported/required in the system –Use Cases: How those actors interact with the system, from their perspective Supplemented by the following information: –Glossary, Additional Specifications, etc.

9. Neumont UniversityCS 322 - Lecture 109 Actors Actors represent the various roles in a system. –Since these are roles, one person can play many roles, or many people can take on a role What kind of roles would there be in –A restaurant? A bank? A eCommerce System? A graphics application?

10. Neumont UniversityCS 322 - Lecture 1010 Anatomy of an Actor The actors (or roles) in the system need to be documented –Many ways to approach this. –I use the following outline on the next slide as a document template –What you use may differ from this But the content provided must be there.

11. Neumont UniversityCS 322 - Lecture 1011 Actor Outline Actor #: Actor Name Brief Description –A bit more information about this actor Actor Goals (optional) –What does the actor mainly want to do, what is their purpose in the system? Primary Use Cases –A list of use cases in which this actor is the primary actor (more on this) Secondary Use Cases (optional) –The other use cases in which this actor participates in

12. Neumont UniversityCS 322 - Lecture 1012 Use Cases All use cases contain a flow of events from the perspective of the actors –Use cases often have a principal actor(s). A principal actor(s) are those that either start a use case flow, or derive the most value from that use case. The level of use case documentation varies from project to project –Some are very formal, others very informal

13. Neumont UniversityCS 322 - Lecture 1013 Anatomy of a Use Case Like Actors, Use Cases must also be documented. –I use the following outline on the next slide as a document template –What you use may differ from this in some details But the basics must be there.

14. Neumont UniversityCS 322 - Lecture 1014 Use Case Outline Use Case #: Title Actors: –Primary Actor: Actor1 –Secondary Actors: Actor2, Actor3… Use Case Flow: –Preconditions (optional) –Main Flow 1. Step 1 2. Step 2 –Alternative Flows 2a. Alternative to Step 2 –Postconditions (optional) Minimal Success Guarantee (optional) Notes (optional)

15. Neumont UniversityCS 322 - Lecture 1015 Use Case Flows There is a real art to documenting the flow of a use case. The things to look for –An appropriate level of detail. Not too much, but not too little –Documenting important alternative flows But not documenting every single possiblity –Keeping the flow at the appropriate level of abstraction

16. Neumont UniversityCS 322 - Lecture 1016 Use Case Flows Each step in a flow should be active –It should be very clear if an actor is doing that step, or if the system is doing that step. –Each step should be concise and easy to follow. –Keep the flows simple as possible.

17. Neumont UniversityCS 322 - Lecture 1017 Use Case Flows In some cases, people use plain text to document the flow of a use cases I prefer to use an outline of numbered steps –This way, it is easy to show substeps in a outline –Also, I can show alternates to a step by adding a letter to the step (for example 2a, 4b, etc.)

18. Neumont UniversityCS 322 - Lecture 1018 Use Case Models In UML In UML, there is a Use Case Model These models only show how Actors and Use Cases relate to each other –They do not show the flow of use cases –They are not an replacement for use case documentation and text. It is best to think of use case models as a “roadmap” to a set of actors, use cases.

19. Neumont UniversityCS 322 - Lecture 1019 Use Case Models in UML In many cases, having a Use Case Model is not worth the extra effort –It is only handy if you have a fairly complex Use Case model Lots of use cases, with extension points Generalized use cases for reuse in domain- specific software Etc.

20. Neumont UniversityCS 322 - Lecture 1020 Use Case Model Example

21. Neumont UniversityCS 322 - Lecture 1021 Use Case Associations The main kind of association is between Actors and Use Cases –What actors play what part in what use cases There are also a set of dependencies between use cases –We show one in the previous examples –These are often hard to explain and not commonly used, so we won’t cover them

22. Neumont UniversityCS 322 - Lecture 1022 Use Cases and UML Models In some cases, complex use case flows can use other UML models as additional documentation –UML sequence diagrams or activity diagrams –In either case, one should consider if the use case can be split up or made simpler to avoid this complexity –Why do we try to avoid UML models here? Believe me, we don’t in most other places

23. Neumont UniversityCS 322 - Lecture 1023 Use Cases: Learn By Doing There is a lot of excellent information on writing use cases –Writing Effective Use Cases, Alistair Cockburn is one book I particularly like I encourage you all to do some research on this topic, but for now, we learn by doing.

24. Neumont UniversityCS 322 - Lecture 1024 Use Cases: Don’t Panic You will not become great use case developers overnight –If it seems easy, just trust that it is not Of course, you could be truly gifted! –Remember, at first, you are likely to consume use cases, not develop them In some cases, you may just get a design to implement (don’t be afraid to ask for the use cases, however)

25. Neumont UniversityCS 322 - Lecture 1025 Why Use Cases Matter Hopefully, you can see the basics on how Use Cases can help a project –There’s just lots of different ways to develop use cases Pick what works best for your team. –There is not one “right solution” or “right way” of use case development Again, what works best is what works best for your team.

26. Neumont UniversityCS 322 - Lecture 1026 Use Case Review Okay, hopefully you have the essence of what Use Cases are. –The rest of the time, I will reserve for Q/A. –Hint: Asking questions now may help you on your lab later.