Considering the Cloud Imaging scenario discussion of June 6 and the IPP
scenario discussion of June 13, as well as face to face discussions, perhaps
I have just missed the point but it seems we have wandered about in circles
(which is to say that we apparently have concluded that our first approach
was correct, which it may be). Dealing with the "Best Practices" document,
we have concluded that there need be just one scenario for each of the
imaging functions: print, scan and fax. This "Scenario" becomes basically
just a very general statement of what is involved in printing, or faxing, or
whatever; I suggest that although it may be a useful starting point, it
does not provide the usefulness of a more detailed scenario.
Further, it seems that two different approaches have been proposed about
how the "use cases" will be extracted from this single "scenario". One is
a sort of horizontal approach by which each of the basic steps of the
scenario refers to a set of use cases; for example, "Selecting a Printer" ,
"Submitting a Print Job", etc. The other, perhaps best described as
vertical approach, would be to outline sequences of how a user in a
particular situation would print, sort of a narrow scenario something like
the use cases that were first submitted.
Granted that we can use whatever terms we wish, provided that we properly
define them, I do think that in using common engineering development terms
we should not deviate too much from accepted usage. I suggest looking at
http://en.wikipedia.org/wiki/Scenario_%28computing%29 and
http://en.wikipedia.org/wiki/Use_case, or perhaps the more formal documents
referenced by these articles.
But calling it scenario or use case, I do think that one of the main
benefits of outlining a realistic start-to-end sequence (from "I want to
print something" to "I know that that something was printed and where it
was output") is that one sees (and reviewers see) interactions that might be
lost in a purely horizontal approach . What is more, people can follow a
realistic sequence and the use cases can become, as Randy suggested they
must be, more "compelling".
In short, I suggest:
1. Our terminology be not inconsistent with typical design terminology
2. We define our approach and terminology in the "Best Practices"
document
3. We be consistent in terminology and level within the "Best
Practices" document and among the various projects (It would be very
confusing to have a Use Case in one document become a Scenario in another.)
4. We not lose the "story" aspect and the sequence of what the user
does and what the "system" must do. Joe is on vacation at Yellowstone and
needs to print out the map to a lost gold mine in Wyoming that his friend in
New York City just found. Perhaps the story is farfetched, but it includes
many aspects of the general problem that must be considered.
Thanks,
Bill Wagner
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20110615/29cb5c57/attachment-0001.html>