1. 1 CTDay@lbl.gov - (18 April 2000) Use Case Web Page – Samba Lessons Christopher T. Day Lawrence Berkeley National Laboratory 18 April 2000

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