Business Analysis: Working with Use Cases

Question 1

What is a use case?

Answer 1

Use cases are descriptions of how users (or actors, as we will cover later) interact with systems. Although they can be used to describe processes, they are bigger than just that one area. It has become fairly common to use the term “use case” to describe scenarios. This is, strictly speaking, incorrect. Later in the course, we will look at use case diagrams which are visual models for system functionality. But here we’re just talking about single use cases.

Question 2

How would you describe use cases?

Answer 2

Process -driven
Goal-Centric
User-focused

Question 3

For which of the following projects would use cases be an effective requirements development method?

Answer 3

The middleware project would probably not be a very good candidate for use cases. Since it sounds like there are no human actors involved, and messaging would likely be handled by data descriptions, another approach (e.g. data flow modeling) would be a better candidate. The ready-made system project, since it has already been built, would likely not require use cases either. The custom-developed e-commerce site, with all the various shopping options, would be the best candidate for use case modeling.

Question 4

Which of the following would be a good use case title?

Answer 4

Since use case titles always follow the form, [verb] + [noun phrase], “Archive an e-mail” is correct. It sounds like a mini-goal that a user would want to accomplish. “Archival of e-mails” sounds like a requirements category or system feature. “The system will…” looks like a business requirement.

Question 5

What is an actor, in the context of use cases?

Answer 5

Actors are all those people and systems involved in executing a given use case. People actors would be a subset of all actors, and users are a subset of people actors. We usually don’t talk about stakeholders of a use case, but when we do, it’s referring to anyone with an interest in the use case being executed. The majority aren’t actors.

Question 6

Why is it a bad idea to document business rules within a use case?

Answer 6

If you document 50 business rules in 200 different use case documents, it will be a nightmare to maintain. Business rules are actually quite short; nonetheless, a business rule repository or separate document is better suited for maintaining them. Modern businesses are dynamic indeed. But it is important to document business rules.

Question 7

What is the basic flow of a use case?

Answer 7

The Simplest sequence of steps take to accomplish the use case

Question 8

What is the alternative flow of a use case?

Answer 8

Alternative of achieving the goal of the use case.

Question 9

What is the exception flow of a use case?

Answer 9

A possible sequence of steps undertaken by an actor wherein the goals of the use case are not accomplished.

Question 10

Why is the basic flow sometimes called the “happy path?”

Answer 10

It’s called the “happy path.” The actors easily and directly accomplish the goal without any problems, so they’re happy at the end because nothing went wrong.

Question 11

Which of the following would be valid content for the “Notes and References” portion of a basic flow step?

Answer 11

A reference to an alternate or exception flow.
A reference to a business rule.
A note cautioning developers and testers about some intricate detail of this step.

Question 12

Give an example of an alternate flow?

Answer 12

The user accomplishes her goal of logging on to the system. Since her initial attempt failed, but she was eventually able to meet her goal, this is best modeled with an alternate flow. The first answer is a good example of something best modeled in the basic flow. Nothing goes wrong; the user accomplishes his goal. The third answer, as you’ll see in the next lecture, is best modeled using an exception flow (the goal of logging on is not met, because the system is down).

Question 13

Why do we usually have alternate flows branch out from steps where a system is the actor?

Answer 13

Because we are specifying how a system should respond to soe previous action
Because we can’t control what human actors will do.

Question 14

What is the last step of an alternate flow?

Answer 14

The last step in an alternate flow should direct the reader back to the appropriate step in the basic flow. This helps the reader have a clear idea of how the system will behave

Question 15

What are good strategies for finding possible exceptions that should be modeled as exception flows in your use cases?

Answer 15

Have developers review your draft use cases and provide input.
Look for places in your basic flow where unexpected problems might pop up.
Look for places in alternative flows where unexpected problems might pop up.

Question 16

What does the last statement of an exception flow usually do?

Answer 16

Just as the last step of alternate flows direct the reader back to a place in the basic flow, the last step of an exception flow ends the use case.

Question 17

What is a common outcome of missing an exception flow here and there?

Answer 17

Missed requirements
Poor user experience
Annoyed management

Question 18

What is the best strategy for finding use case preconditions?

Answer 18

examining the basic, alternate and exception flows (usually in that order).

Question 19

Will use cases always have at least one postcondition? Why?

Answer 19

Use cases always have a goal, and the achievement of that goal is the first precondition. Cockburn and Cunningham probably agree that postconditions are a best practice, but this has (to my knowledge) never been expressed by them together. Use cases do have exception flows where the goal is not met, true. But postconditions reflect the state of the system after the use case has been successfully executed, so this statement doesn’t apply. The last answer is false. All use cases should have preconditions.

Question 20

Give an example of a trigger?

Answer 20

The clocking ticking to a particular time – is the trigger among this list. The other answers look like preconditions or postconditions, depending on the context they’re found in. Remember that a trigger is an event. It’s something that happens at some point in time.

Question 21

Which of the following use case components is the first activity in a flowchart?

Answer 21

The trigger is usually the first activity (rectangle) in a flowchart. Alternatively, the first step of the basic flow is also acceptable. Preconditions and postconditions are states rather than activities, and they aren’t depicted in flowcharts.

Question 22

If your flowchart becomes very complicated, what is the best strategy for handling it?

Answer 22

The best approach will be to reduce the flowchart’s complexity. Complexity is harder for stakeholders to understand. Complexity also breeds defects and lower testability. Just be sure to refactor your use case as well.

Question 23

Why are swim lane flowcharts better than regular flowcharts when paired with use cases?

Answer 23

Swim lane flowcharts highlight the actors of a use case, making it more easily mappable to the use case. For this reason, we more commonly use swim lane flowcharts than regular ones.

Question 24

When should you make a use case diagram for your project?

Answer 24

Recommend creating a use case diagram whenever you have three or more use cases.

Question 25

If one use case contains another, the use case __________ the other use case.

Answer 25

The use case includes the other use case, usually as a single step in the basic flow.

Question 26

Why should you use «includes» relationships in your use cases?

Answer 26

To simplify your use case flows
To enhance the maintainability of your documentation.
To illustrate dependencies across use cases.

Question 27

Which of the following is a valid strategy for refactoring «extends» relationships out of use cases.

Answer 27

The alternate flow is the best option. The exception flow won’t work, because it indicates that the use case fails. The two use cases should be kept separate, because they will not always be executed at the same time.