C# ПІДРУЧНИКИ / Addison Wesley - Writing Effective Use Cases

Chapter 11. Use Case Formats

Page 139 - Conclusion about formats

For detailed functional requirements

Scope: Acura

Level: User goal

Context of use: Primary actor:

Stakeholders & Interests: Minimal Guarantees: Success Guarantees: Preconditions:

Triggers:

Main Success Scenario:

1. ...

2. ...

Extensions:

1a. ...

1a1. ...

Frequency of occurrence: Open Issues: ...

Use this template when your purpose is to collect behavioral requirements using all of the features of fully dressed use cases. This could be for a larger or critical cost project, fixed-price bid, a geographically distributed team, at the start of an increment when it is time to expand and examine the sizing use cases drafted earlier, or because it is your culture to do so

The system under design may be anything, the actors and goals, similarly anything. I used Acura and user-goal level in this sample template.

11.4 Conclusion about formats

All of the above different formats for a use case express approximately the same basic information. The recommendations and guidelines of this book apply to each format. Therefore, do not fuss too much about which format you are obliged to use on your project, but select one that the writers and the readers can all be comfortable with.

Chapter 11. Use Case Formats

Conclusion about formats - Page 140

PART 2

FREQUENTLY

ASKED

QUESTIONS

141

Chapter 12. When are we done?

-Page 142

12.WHEN ARE WE

DONE?

You are "done" when

•You have named all the primary actors and all the user goals with respect to the system.

•You can captured every trigger condition to the system either as a use case trigger or an extension condition.

•You have written all the user-goal use cases, along with the summary and subfunction use cases needed to support them.

•Each use case is clearly enough written that

-the sponsors agree they will be able to tell whether or not it is actually delivered.

-the users agree that is what they want or can accept as the system’s behavior.

-the developers agree they can actually develop that functionality.

•The sponsors agree that the use case set covers all they want (for now).

All the primary actors and their user goals defines the boundary of what the system must accomplish. Since there is no other source of this information to compare this list against, just the minds of the people who have to accept the system, you cannot know you are done with this list, you can only suspect you are done with this list. Therefore, it is worthwhile going over this list in brainstorming mode several times.

All the trigger conditions is the fine-tuning of the boundary. The system will have to react to every trigger. In the use cases, some of those triggering events will show up as use case triggers. Examples might be User puts card into slot, Customer calls to add/remove a clause to their insurance policy or User selects to install software upgrade. Other triggers are taken care of in the

scenario extensions. Examples are User hits cancel button or System detects power drop.

One way to reexamine the set of triggers to the system is to identify all the elements that have a lifecycle, and then review each of their lifecycles. Look for all the events that cause something to change its state in its lifecycle.

Summary and subfunction use cases. The summary use cases create the context for the usergoal use cases. They answer the question people often ask, "But how do all these (user-goal) use cases fit together?" I like to make sure that every use case sits inside a higher-level one, up to a single root. That root use case is only table of contents with not much storyline, but new readers

Chapter 12. When are we done?

Page 143 -

find it useful to have a single starting point from which they can start accessing every use case in the system.

Subfunction use cases support the user-goal use cases. They are only needed only are called from several by other use cases or isolate a complicated piece of behavior.

Agreement on the use cases. The use cases are only done when the both the sponsors and usage experts can read and agree with them and say that’s all they want, and the developers can read them and agree they can build a system to these specifications. That is a difficult challenge. It is the challenge of requirements writing.

On being done. Uttering the phrase Being Done manages to give an impression that one should sit down and write all the use cases, beginning to end, before starting on design tasks. I hope you are aware that this is not the case. See Chapter 17.1“Use Cases In Project Organization” on page 164 for a discussion of developing a project plan with partial release of use cases. Read Surviving Object-Oriented Projects for a longer description of incremental development. Read the article "VW-Staging" online at http://members.aol.com/acockburn/papers/vwstage.htm for a short and dedicated discussion of incremental and iterative development.

Different project teams use different strategies, depending on their situation. Some draft all the use cases right away, perhaps to prepare a bid for a fixed-price contract. These teams need to be aware that the use cases will need fine tuning over the course of the project. Other teams only draft all the actors and user goals, delaying use case elaboration until the appropriate increment. Others will create the use cases for each 6-9 months worth of work, deferring all other requirements discussion until that work is almost finished. Still others will write use cases just barely before starting on a round of work. Each of these strategies its place and its advocates.

Chapter 13. Scaling up to Many Use Cases

-Page 144

13.SCALING UP TO

MANY USE CASES

There are two ways to deal with large numbers of use cases: say less about each one, or group them into separable groups. You should use both techniques.

Say less about each one (low precision representation)

Just the use case name alone is useful. That’s why it counts as the first level of precision. The collection of use case names is an excellent working medium for manipulating the full set of use cases, particularly for estimating, planning and tracking. Put the list of use case names into a spreadsheet and use the spreadsheet’s capabilities to sort, order and summarize the various qualities of interest about the use case. See Section 1.5“Manage Your Energy” on page 29, and Chapter 17.1“Use Cases In Project Organization” on page 164.

The second level of precision is the use case brief, a 2-3 sentence summary of the use case. This also can be put into a spreadsheet or table form, and reviewed. See “A sample of use case briefs” on page 47. This is also useful for getting an overview of the system and organizing the work.

Saying less about each use case is valuable when you want to scan the full set of use cases at one time. There are times, though, when you need to collect them into separate clusters.

Create clusters of use cases

If you are working from text-based tools such as Lotus Notes or spreadsheets and word processors, you can form use case clusters using ordinary labeling techniques. If you are using UML tools, you will call them packages. There are three common and effective clustering techniques.

By actor. The most obvious way to cluster use cases is by primary actor. At some point, perhaps around 80 or 100, that loses effectiveness. You will have too many use cases per primary actors, too many primary actors, or there will be too much overlap of primary actors to use cases.

By summary use case. You will find that some sets of use cases naturally cluster by their lifecycle, or on larger projects, by their place in the lifecycle. These related use cases show up in a summary use case. If you do not write summary use cases, you may still want to cluster the use cases to create, update and delete certain kinds of information will naturally cluster. On one project. One system maintained a mock checkbook for customers. We referred to all of the checkbook altering use cases together, as "the checkbook use cases". This cluster was developed by

Chapter 13. Scaling up to Many Use Cases

Page 145 -

the same development team, and progressed together in a way that was easy for the project managers to handle.

By development team and release. Clustering use cases by which team will develop the design and release number simplifies tracking the work. It becomes natural to ask questions like, "Is the user profile cluster going to make it on time?" This clustering holds even for larger projects.

By subject area. For projects with over 100 use cases, people will automatically separate them by subject areas in their speaking. It is usually quite easy to name natural subject areas. One project used customer information, promotions, invoicing and advertising. Another used booking, routing, tracking, delivery, billing. Often there are subprojects around the different subject areas. Each subject area might contain 20-100 use cases.

Tracking 240 use cases is difficult. Tracking 15-20 clusters is quite reasonable. On a large project, I would cluster first by subject area to get 3-6 clusters of 20-100 use cases each, and then by release and development team. Depending on the number of use cases in these clusters, I would summarize work progress using clusters of related or summary use cases.

Chapter 14. Two Special Use Cases

CRUD use cases - Page 146

14. TWO SPECIAL USE

CASES

14.1 CRUD use cases

There is not yet a consensus on how to organize all those little use cases of the sort, Create a Frizzle, Retrieve a Frizzle, Update a Frizzle, Delete a Frizzle. These are known as CRUD use cases, from the Create, Retrieve, Update, Delete operations on databases. The question is, are they all part of one bigger use case, Manage Frizzles, or are they separate use cases?

In principle, they are three use cases, because each is a separate goal, possibly carried out by a different person with a different security level. However, they clutter up the use case set and can triple the number of items to track.

Opinion is split as to the best way to deal with them. Susan Lilly advocates keeping them separate in order to keep track of which primary actors have security access to the different functions. I tend to start with just one, Manage Frizzles to get the advantage of less clutter. If the writing gets complex, I break out that one part, as described in “Creating a new use case from an extension” on page 112. I track user access to system data and functions using a separate worksheets. Neither way is wrong, and I have not seen enough evidence to form a rule one way or the other.

The following is a use case written by John Collaizi and Allen Maxwell. They started writing both ways. They decided to merge the use cases into summary level Manage use case, and eventually broke out the Save sub use case to deal with the complexity. I include the use case also to show one way to fit a personal writing style with a different template. They used the Rational Unified Process use case template, and numbered the steps and extensions.

USE CASE 32: MANAGE REPORTS

1 . Br ie f D e scr ipt ion

This Use Case describes and directs operations for Creating, Saving, Deleting, Printing, exiting and Displaying Reports. This particular use case is at a very low level of precision and utilizes other use cases to meet its goal(s). These other use cases can be found in the documents listed in the “Special Requirements” Section.

1 . 1 Act or s

User (Primary)·

File System: typical PC file system or network file system with access by user. (Secondary)

Chapter 14. Two Special Use Cases

Page 147 - CRUD use cases

1 . 2 Trigge r s

User Selects operations explicitly using the Explorer interface.

1 . 3 Flow of Ev e nt s

1.3.1 Basic Flow – Open, Edit , Print , Save, and Exit report

a.User selects Report by clicking report in Explorer and selects open (open also triggered by Double clicking on a report in the Explorer).

b.System displays report to screen.

c.User sets report layout etc. using use case: “Specify Report Specs”. System displays altered report

d.Steps c and d repeat until user is satisfied e.User Exits report using use case: “Exit Report”

f.User can Save or Print report at any time after step c using use case: “Save Report” or the “Print Report” Alternate Flow listed below.

1 . 3 . 2 Alt e r na t iv e Flow s

1.3.2.1 Creat e New Report

a.User selects “Create New Report” from Explorer by right clicking and selecting option from popup menu.

System creates New Report with Default Name and sets report status for name as “unset”, status as “modified”.

b.Use case flow continues with Basic flow at step b. 1.3.2.2 Delet e Report

a.User selects Report by clicking report in Explorer and selects Delete.

b.System opens report (or makes it current if it is already open) and requests validation from user for deleting report.

c.Report is closed and resources cleaned up

d.System removes report entry from report list and report data is removed from storage medium

1.3.2.3 Print Report

a.User selects Report by clicking report in Explorer and selects Print OR user selects print option of current report (a report being edited/displayed in Basic Flow of this use case).

b.User selects printer to send report to and printing options specific to printer (print dialog etc. controlled by operating system) OR user selects to Print Report to File…

c.System loads report and formats. System sends report job to operating system or prints report to designated report file. System closes report.

1.3.2.3 Copy Report

a.User selects Report by clicking report in Explorer and selects Copy.

b.System Prompts for new report name and validates that name doesn’t exist yet c.System repeats b until user enters a valid (non-existent) name, opts to save over existing