meeting -*- Outline -*-

* Other Aspects of Use Cases (Larman 6.10-6.18)

** use cases are imperfect (6.10)

------------------------------------------
      THE USE CASES AREN'T RIGHT

They will: 
 - lack critical information
 - contain wrong statements

Approaches:
 - waterfall model (try to do better)
 + iterative development
    ongoing personal communication

------------------------------------------
        Beck recommends: "User full-time on the project,
        in the project room."

** write use cases in an essential UI-free style

   Emphaisze this!

------------------------------------------
        ESSENTIAL UI FREE STYLE

"Keep the user interface out;
 focus on intent." (Cockburn)

------------------------------------------


   avoid talking about UI details, these often change.

   e.g., admistrator identifies self                    (essential)
      vs. admistrator enters account name and password  (concrete)

   concrete details may be suitable later during GUI design work.

   advantage of the essential style is that opens up avenues for
   taking advantage of new technology.  (e.g., DNA readers)

** actors (6.12)
------------------------------------------
           KINDS OF ACTORS

- primary: has goals fulfilled by system

- supporting: proivdes services or info

- offstage: has interest
    (e,g., government tax agency)

------------------------------------------

** use case diagrams (6.13, omit?)
    can be used to illustrate actors, names of use cases, and
    relationships

    See figure 6.2 on p. 71 of Larman's book
        (stick men (or <<actor>> boxes for computers) for actors,
         primary actors on left, supporting on right,
         use cases in ovals, within the system boundary.)

    This is secondary work in should not be emphasized.

    Could be drawn in conjunction with an actor-goal list,
    to summarize the system.

** comparison to feature lists (6.14)
   Use cases help place requirements in context better than a
   "laundry list" of features, so they are suggested instead.

   However, high-level system feature lists are acceptable in a vision
   document. 

** Use Cases Are Not Object-oriented (6.15)
   They can be applied to other kinds of project.

** Use cases within the UP (6.16, skip)

------------------------------------------
   USE-CASE DRIVEN DEVELOPMENT (6.16)

- use-case model records requirements

- iterative planning
  chooses use case scenarios or use cases

- use-case realizations drive design

- use-cases influence the organization
  of user manuals

------------------------------------------

    typically use cases are written in "requirements workshops" during
    various phases...

------------------------------------------
    USE-CASES AND PHASES

inception:
 - Concentrate on finding
   goals and stakeholders, system boundary
 - Most use cases identified by name
   and summarized in a short paragraph
 - Only 10% written in detail,
   to help explore risk

elaboration
 - Get feedback at end of each iteration
 - Write ~20% more use cases in detail
   at each iteration
   (focus on most important ones,
   finish with 80-90% written)
 - Most use cases not implemented
   in this phase
 
construction:
 - minor use case writing
 - deal with changes in requirements
------------------------------------------

        See p. 82 for suggestions on the requirements workshop

** case study
------------------------------------------
       CASE STUDY USE CASES (6.17)

In inception, which use cases
in the StickSync system should be:

Fully dressed:



Casual:





Brief: 



------------------------------------------
        Q: Where is the risk, or importance?   

           Fully dressed: Add File,

           Casual: Propogate File Change,

           Brief: Select PMSD, Select Synchronization Partner

           Title Only: remove file, add directory, propogate directory
           change, change file location, change directory location,
           start system, replace faulty PMSD