use cases cs 6961 – lecture 4 nathan dykman. neumont universitycs 322 - lecture 102 administration...

Use Cases

CS 6961 – Lecture 4

Nathan Dykman

Neumont University CS 322 - Lecture 10 2

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?


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.


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.


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.


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.


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.


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.


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?


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.


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


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


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.


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)


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


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.


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.)


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.


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.


Use Case Model Exampleud Use Case View

Customer

Logon to Site

Shop For Items

Retailers

«use»


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


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


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.


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)


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.


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.

use cases cs 6961 – lecture 4 nathan dykman. neumont universitycs 322 - lecture 102 administration...

Documents

system use cases

neumont universitycs

requirements usecase

use cases cs

primary use cases

basics of use cases

list of use cases

software requirements