1. Capturing Requirements with Use Cases

2. Use Case—Definition
A use case is a narrative description of a goal-oriented interaction between the system under development and an external agent
Includes the what:
User (Actor in Use Case Parlance)
Goal
Interaction
But not the how:
Excludes User Interface Detail
Excludes Implementation Concerns
A use case is sort of like a dialog script written for two actors. A use case captures the dialog between user and system in the form of user actions and system responses.
Like a game of table tennis.
Capturing requirements in the form of use cases effects a subtle shift in perspective. Use cases capture requirements in the form of interactions with an end user. When requirements are captured in terms of what the system should do it's easy for important details to be missed. When requirements are described in terms of interactions with end users missing details become obvious. Creating conceptual test cases has the same effect.
Use cases represent a model of the system because they present an abstract view of the system from a specific viewpoint. The viewpoint is that of the end user.
Use case modeling is a very simple concept with surprising value.

3. Simple Example

4. Benefits of capturing requirements with use cases
Excellent ROI
Simple and intuitive method of recording functional requirements.
Readable by end users but also detailed enough for programmers to implement and testers to write test cases.
Systematic and semi-formal representation helps ensure requirements are complete and well understood.
Probably no other requirements elicitation technique has a larger return on investment than writing use cases. Writing use cases is a simple intuitive means for capturing system requirements. Use cases are valuable because they keep system development focused on the needs of the end user. They also capture the requirements of a system in a form that is readable and understandable to the end user.
I can’t remember ever writing a use case for some feature and not getting a better understanding of the feature to be implemented—usually it’s a question about what should be done that then needs to be resolved by the customer/users.

5. Other Advantages
Expressing requirements in term of goal-oriented user interaction avoids gold plating or adding features that aren’t likely to be used.
Can be used to drive the development process. (Iteration planning, validate architecture,

6. Aspects of a use case
I can’t think of a good use case title that is not an active verb phrase. Title usually has the form <verb> <object>. This is reasonable considering a use case addresses a goal.
An actor represents an external entity that gets value from the system. Actors usually represent people by may also represent external software systems. An actor represents a coherent set of roles a person or external system takes when interacting with the system. An actor may represent several users and one user may play the role of several actors. Sometimes it's useful to distinguish between primary and secondary actors. The system exists to support the primary actors. Secondary actors may be necessary for system support. For example, a customer is a primary actor and an operator is a secondary actor. When making decisions that involve trade-offs support for primary actors should be given priority over support for secondary actors.
Most use cases consist of two parts, (1) a typical course of events (also called the happy path☺), and (2) variations on the typical course of events. The typical course of events and each variation are called scenarios. A scenario describes one path through a use case from start to finish. There may be several paths through a use case. A scenario describes one outcome. The outcome may be a success (the goal of the user was met) or a failure (the goal of the user was not met). For example, the Authenticate user use case above has two scenarios: (1) success and (2) failure.
Categories of paths:
Common or Happy path
Alternate paths
Exception or error paths

7. Another Example

8. System Under Development
UML Use Case Diagrams
Newspaper Web Site
Post article
Journalist
Reader
Authenticate user
Find and read article
<<include>>
System Under Development
Use Case
Actor
All the actors and use cases of a system make up a use case model.
The use case model defines the boundaries of the system. Actors are outside the system and use cases are within the system.
Generic Form
Example

9. Use Case Template Title: Actors: Preconditions: Postconditions:
Basic Flow / Main Success Scenario
Alternate Flow / Extensions
Open Issues
Consider adding:
Field for different types of actors such as: Primary, Supporting and Offstage
Special requirements: related non-functional requirements.

10. Example Title: Search Web with suggested key words (Google Suggest)
Actors:
Web User
Preconditions:
Web user is at the search page
Basic Flow
User begins to enter search phrase
As characters of search phrase are typed, the system responds with suggested search phrases that start with characters entered
The system enters the highest ranking suggested search phrase into the search box where the user is typing
User scrolls to desired suggested phrase
User initiates search
System responds with search results that match search phrase
Alternate Flows
2a. There are no high ranking suggested search phrases for the characters the user has entered
1. The system gives no suggested search phrases
2. The user enters the remaining characters in the search phrase and control returns to step 5 in basic flow
4a. User decides to accept suggested search phrase in search box
1. User initiates search with suggested search phrase currently in search box
4b. User finishes entering original search phrase but doesn’t want to take system’s suggestion
1. User hits backspace to erase remaining suggested characters in search box
Open Issues
1. How to decide the order or ranking of suggested search phrases.

11. A Process for Writing Use Cases
Identify actors
Identify the goals associated with each actor. Make each goal a use case.
Prioritize use cases
Elaborate use cases
Create a structured use case model (UML Diagram)

12. References Ivar Jacobson OOSE
Fowler UML Distilled gives a good summary
Larman, Applying UML with Patterns
Cockburn, Writing effective use cases and (including:

13. --------Notes--------
“A use case specifies the behavior of a subject—a system or a part of a system—it describes sequences of actions, including variants, that a subject performs to yield an observable result of value to an actor.”
“You apply use cases to capture the intended behavior of the system you are developing, without having to specify how that behavior is implemented. ”
“Use cases specify externally visible behavior; they do not dictate how that behavior will be carried out internally.”
“A use case is a description of a set of sequences of actions, including variants, that a subject performs to yield an observable result of value to an actor.”
“each sequence represents the interaction of the things outside the system (its actors) with the system itself”
interaction of actors and the system
“these use cases not only represent the desired behavior of these elements, but they can also be used as the basis of test cases for these elements as they evolve during development.”
System is described by a set of use cases
“An actor represents a coherent set of roles that users of use cases play when interacting with these use cases.”
“A use case describes w h a t a system (or a subsystem, class, or interface) does but it does not specify h o w it does”
“You can specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily. When you write this flow of events, you should include how and when the use case starts and ends, when the use case interacts with the actors and what objects are exchanged, and the basic flow and alternative flows of the behavior.”
“You can specify a use case's flow of events in a number of ways, including … text…,state machines …, activity diagrams…, and pseudocode.”
main versus alternative flows
“Each sequence is called a scenario. A scenario is a specific sequence of actions that illustrates behavior.”
“A use case captures the intended behavior of the .. you are developing,”
“An include relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base. ”
“can use state machines as yet another way to describe the behavior represented by a use case.”
“one of the diagrams in the UML for modeling the dynamic aspects of systems.”
“central to modeling the behavior of a system. Each one shows a set of use cases and actors and their relationships”
“Use cases are an excellent starting point for just about every facet of object-oriented system development, design, testing, and documentation. They describe a system’s requirements strictly from the outside looking in; they specify the value that the system delivers to users. Because use cases are your system’s functional requirement”
“Use cases are a valuable tool to help understand the functional requirements of a system. A first pass at use cases should be made early on. More detailed versions of use cases should be worked just prior to developing that use case.”
“With use cases, concentrate your energy on their text rather than on the diagram. Despite the fact that the UML has nothing to say about the use case text, it is the text that contains all the value in the technique.”
“Use cases are a means to bring those gaps in the user’s requirements to the forefront at the beginning of a project.”
“a gap or lack of understanding identified early on in a project’s development will cost far less in both time and money than a problem that is not found until the end of a project.”
“The terms shall and should have a special and exact meaning when It comes to requirements. A shall requirement must be fulfilled; if the feature that implements a shall requirement is not in the final system, then the system does not meet this requirement. A should requirement implies that the requirement is not critical to the system working but is still desirable.”
“An actor is drawn in UML notation using either a “stick man” or a stereotyped box(see “Stereotypes” in Chapter 1) and is labeled with an appropriate name,”
“The Administrator interacts with the system and is not part of the system; therefore, the Administrator is defined as an actor.”
“A use case in UML is drawn as an oval with a name that describes the interaction that it represents”
“A use case is something that provides some measurable result to the user or an external system”
“Administrator actor participates in the Create a new Blog Account use case?” communication line
“The purpose of a communication line is to show that an actor is simply involved in a use case, not to imply an information exchange in any particular direction or that the actor starts the use case. That type of information is contained within a use case’s detailed description, therefore it doesn’t make sense to apply navigation to communication lines.”
box around all of the use cases but keep the actors outside of the box. System boundary
“Preconditions What needs to happen before the use case can be executed.”
“Main Flow The place to describe each of the important steps in a use case’s normal execution.”
“Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing diagrams.”
“use case diagram to show the names of use cases and actors, and their relationships. This gives a nice context diagram of a system and its environment. It also provides a quick way to list the use cases by name.”
“use cases is that they emphasize the user goals and perspective;”
“more user-centric emphasis compared to simply asking for a list of system features.”
“use cases are the central mechanism that is recommended for their discovery and definition” (functional requirements)
“Use cases are indeed requirements (although not all requirements)”
“An actor is anything with behavior” Types: Primary, Supporting and Offstage
Formats: brief, casual, fully dressed.
“Use cases are a technique for capturing the functional requirements of a system. Use cases work by describing the typical interactions between the users of a system and the system itself, providing a narrative of how a system is used.”
“a use case is a textual description of actors’ actions”
“a use case describes an actor trying to achieve a goal by using the system”
“Write a short, textual description of how a system interacts with its surroundings while performing a function of value to one of its users, and capture how the system should behave when various things go wrong”
“Use case diagrams describe what a system does from the standpoint of an external observer. ”
“A is a sequence of steps describing an interaction between a user and a system.”
“A is a set of scenarios tied together by a common user goal.”
[Put’s user’s goals at the center]
“Linking use cases to actors’ goals is so very significant because it shifts the writer’s attention away from the function lists that most programmers worry about and puts it back on the users: What the users really want to accomplish with the software are their goals when using the software. If the software supports those goals, the software will yield the greatest business value.”
[Diagramming elements]
“Actors are simply roles that people or objects play.”
“Actor isn’t really the right term; r o l e would be much better. Apparently, there was a mistranslation from Swedish, and a c t o r is the term the use case community uses.”
“Nothing in the UML describes how you should capture the content of a use case. What the UML describes is a use case diagram, which shows how use cases relate to each other. But almost all the value of use cases lies in the content, and the diagram is of rather limited value.”
Example diagram should include actor, use case, system boundary and include example.
[Writing use cases]
‘a use case is structured into two sections: the sequence of actions when everything goes well, followed by various small sequences describing what happens when the various goals and subgoals fail.”
“The step should show the intent of the actor, not the mechanics of what the actor does. Consequently, you don’t describe the user interface in the use case. Indeed, writing the use case usually precedes designing the user interface.”
“An extension within the use case names a condition that results in different interactions from those described in the main success scenario (MSS) and states what those differences are. Start the extension by naming the step at which the condition is detected and provide a short description of the condition. Follow the condition with numbered steps in the same style as the main success scenario.”
“A complicated step in a use case can be another use case. In UML terms, we say that the first use case includes the second.”
“There’s no standard way to show an included use case in the text, but I find that underlining, which suggests a hyperlink, works very nicely”
“The amount of detail you need in a use case depends on the amount of risk in that use case.”
“Often, you need details on only a few key use cases early on; others can be fleshed out just before you implement them. You don’t have to write all the detail down; verbal communication is often very effective, particularly within an iterative cycle in which needs are quickly met by running code.”
“concentrate on the textual description of a use case; that’s where the real value of the technique lies.”
“The terms are not precise, but in general, a system use case is an interaction with the software, whereas a business use case discusses how a business responds to a customer or an event.”
“Features are a good way of chunking up a system for planning an iterative project, whereby each iteration delivers a number of features. Use cases provide a narrative of how the actors use the system.”
[Misc]
Ivar Jacobson “coined the Swedish term anvendningsfall, which roughly means “situation of usage” or “usage case.” When publishing into English, he decided “usage case” did not work in English, and wrote use case.”
Wikipedia Talk: “According to Jacobson himself the term "use case" is a literal translation of the Swedish term, and at the time he created it he wasn't very fluent in English. He has suggested that the term "usage scenario" is a more correct translation.”
“one of the most common practices for capturing functional requirements”
“The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.”
Use cases should be semi-formal. “use cases really are requirements and need a basic structure, and also
Allow people to write whatever they want when they need to. ”
“Why do we write things in the use case that are not externally visible behaviors? Why do we record that the bank checks the customer’s balance before issuing money, or that it logs the transaction at the end?”
“The Stakeholders and Interests model fills the holes in the Actors and Goals model. Every action the computer takes is tied to a stakeholder’s interest. The system will accept information, validate values against business rules, update internal state, or pass out data. Primary and supporting actors are accounted for, as well as all those stakeholders who aren’t present during the system operation.”
Those how think use cases too formal have moved to “feature lists, story cards, and task cases.”
“The authors of Extreme Programming (XP) stayed with the idea of informal scenarios not having any formal structure at all. Kent Beck created the term user story to describe these sorts of requirements. A user story consists of just a phrase or a few sentences written on an index card, announcing something the user wants to do. In XP, the user story is not used as a requirements specification, but as a marker for a future conversation. Therefore, the card only needs to record enough information so the programmers and customer know what to discuss later.”
“Larry Constantine pursued the writing of scenario descriptions to help in user interface (UI) design. He found he didn’t need to record the system’s internal processing steps or its interaction with supporting actors. He could get away with a very simple two-column structure. The left column listed what the user was trying to accomplish at each step. The right column listed the system’s responsibility. This two-column table provides enough information to let people invent a good UI design. He renamed it a task case, to avoid confusion with system specification use cases.”
“describing how the behavior differs under varying circumstances”
“scenario of behavior followed by scenarios of alternate behavior”
“Use cases are not test plans or test cases. They are missing the data values needed for test cases. However, use cases are a great input into the testing process, since they say what is supposed to happen under various conditions. Testers must still create actual test cases to match the use cases.”
“The greatest value of the use case does not lie in the main scenario, but in alternative behaviors. The main scenario may occupy a quarter to one-tenth of the total length of the use case, because there are so many alternatives to handle.”