attachment

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1>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. <o:p></o:p><o:p> </o:p>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. <o:p></o:p><o:p> </o:p>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 <o:p></o:p><a href="http://en.wikipedia.org/wiki/Scenario_%28computing%29">http://en.wikipedia.org/wiki/Scenario_%28computing%29</a> and <a href="http://en.wikipedia.org/wiki/Use_case">http://en.wikipedia.org/wiki/Use_case</a>, or perhaps the more formal documents referenced by these articles. <o:p></o:p><o:p> </o:p>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”.<o:p></o:p><o:p> </o:p>In short,  I suggest:<o:p></o:p><![if !supportLists]>1.     <![endif]>Our terminology be not inconsistent with typical design terminology<o:p></o:p><![if !supportLists]>2.     <![endif]>We define our approach and terminology in the “Best Practices” document<o:p></o:p><![if !supportLists]>3.     <![endif]>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.)<o:p></o:p><![if !supportLists]>4.     <![endif]>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. <o:p></o:p>Thanks,<o:p></o:p>Bill Wagner<o:p></o:p><o:p> </o:p></div> -- This message has been scanned for viruses and dangerous content by <a href="http://www.mailscanner.info/">MailScanner</a>, and is believed to be clean. </body></html>