1 CTDay@lbl.gov - (18 April 2000)

Use Case Web Page –Samba Lessons

Christopher T. Day

Lawrence Berkeley National Laboratory

18 April 2000

2 CTDay@lbl.gov - (18 April 2000)

Samba 1: “Trust Your Users”

• “User [feedback] is the most valuable quality feedback you have”

• Make Use Case Specific web page—Narrow focus but still part of full project —Examples, forms and guidelines—Online submittal process

• Set up Change Request (“Bug”) tracking that users can access—Avoid user input falling into a black hole—Progress and disposition of user input always

available

3 CTDay@lbl.gov - (18 April 2000)

Samba 2: “Current Documentation”

• In many cases, web directly accesses master copies of documents and cross-links—All requirements documents in at least HTML

and Word (will check other formats)—All change requests

• In other cases, will set up daily batch job to update web image from master—Use Case UML web—Petal form—XMI form

4 CTDay@lbl.gov - (18 April 2000)

Samba 3: “Review Submissions”

• Set up e-mail-based discussion lists—Current discussion list is dismal failure—Users can subscribe to and comment on any

requirement—Convergence of comments leads to Change

Request entered in “Bug” report system

5 CTDay@lbl.gov - (18 April 2000)

Samba 4: “Let Users Be Experts”

• Keeping the databases straight is dull, we’ll do that

• Users can provide input at any level, e.g., documents, UML graphs, etc.

• Use Case core team will do the actual integration to minimize (hopefully) technical screw-ups

6 CTDay@lbl.gov - (18 April 2000)

Samba 5: “Strict Revision Control”

• Use Cases will become a complex, valuable resource—Regular backup, of course—Regular sequence of declared consistency

points or “releases”, I.e., versions of documents, UML graphs and change requests that match and can be recovered.

7 CTDay@lbl.gov - (18 April 2000)

Samba 6: “Control Write Access”

• Initially, only Use Case Core has write access to Master database

• Regular contributors will be invited to join the Use Case Core

8 CTDay@lbl.gov - (18 April 2000)

Samba 7: Freestyle

• What makes a Use Case?—Purely external view of the (sub)system in

question, I.e., defines boundary of system—Initiated by a unique external Actor (customer

of system)—Specific value to be delivered to Initiating

Actor—Sequence of interactions between Initiating

Actor and system, and between system and Supplying Actors

9 CTDay@lbl.gov - (18 April 2000)

ATM example (sorry)

• Initiating Actor – Me• Possible things of value = distinct Use Case—Balance statement—Deposit check—Withdraw cash *

• Interactions—Insert card: Initiator/System—Choose withdrawal: Initiator/System—Specify amount: Initiator/System—Verify account: System/Bank-as-Supplier —Deliver cash: System/Initiator

10 CTDay@lbl.gov - (18 April 2000)

Use Case Refinement

• Two directions—“Refine with more detailed Use Cases”

• Suggests a move to internal view, I.e., Use Case Realizations

• More Specific• This is Analysis/Design

—“Extract Common Use Cases”• Define reusable Use Cases and restructure available

Use Cases in terms of them• Use Case “Subroutines”• Less Specific• This is still Requirements• Be very detailed to maximize information content