Re: use case definition -- follow-up

Andrew,

Thanks for the contribution.  Attached, for your reading pleasure, is what 
GL1 now looks like, in its entirety.  I integrated your stuff (and Lynne's) 
and smoothed everything out a bit.  Related to this, the "Definitions" 
chapter now has the two definitions that I sent yesterday for review.

(All)  Please send any comments and corrections.

-Lofton.


At 05:57 PM 8/14/02 +0100, you wrote:

>On 2002.08.14 17:34 Lofton Henderson wrote:
>>Since Kirill (original author) agrees with the approach, that leaves only 
>>the question of a volunteer...
>>
>>>2.) Will someone volunteer please to draft specific replacement text -- 
>>>how to turn 0811 into 0819 from Lynne/Andrew contributions?
>>>         2a) two definitions for "Definitions" chapter
>>>         2b) any verbiage modifications for GL1
>>>         3b) any verbiage modification for any CK1.x
>>>(Friday would be a good deadline, Thursday CoB would be better.)
>
>  here's my suggested text/changes
>
>  for 2b)
>  I suggest we include Lynne's definitions #1 for Use Case. We also need to do
>  a global swap of 'Use Case' for 'User Scenario' in the existing text.
>  Change GL title to "Define Use Cases"
>
>  for 3b)
>  Apply use case <->user scenario swap to all ckpt text.
>
>  new text for ck1.2:
>
>    Checkpoint 1.2 Include User Scenarios
>
>    A User Scenario is an instance of a use case, representing a single 
> path   through the use case.  Thus, there may be a scenario for the main 
> flow   through the use case and another scenarios for each possible 
> variation of   flow through the use case (e.g., representing each 
> option). Unless otherwise
>   specified, when included in a specification a user scenario is 
> considered to be
>   informative.
>   The specification should have an extensive list of the user scenarios* that
>   the authors have in mind. Priorities MAY be assigned to user scenarios,
>   describing how important the particular scenario is for the specification.
>   User scenarios in their turn may help to asses what features are 
> missing and
>   what features are superfluous in the specification.
>
>  * I left out 'orthogonal' since we are going with the OMG definition which
>     defines them as 'atomic' - I'm assuming this to be ~the same thing.
>  -Andrew
>