SIGIA-L Mail Archives: FW: SIGIA-L: IA notation
FW: SIGIA-L: IA notation
From: chuck.lutz_at_telelogic.com
Date: Thu Jun 29 2000 - 16:37:27 EDT
Meant to send this to the list....oy... /chuck
-----Original Message-----
From: Chuck Lutz
Sent: Thursday, June 29, 2000 3:33 PM
To: 'Kay.McLellan_at_ihsenergy.com'
Subject: RE: SIGIA-L: IA notation
Hi Kay,
You make an excellent point below, and, in fact, it might be that UC
descriptions
go through different versions, perhaps starting with e.g.
"The customer then chooses a product."
Eventually this is transformed to some form like the example I showed below.
It all depends on who is writing the user scenarios.
So, yes, as with any document, the audience must be considered, so you'd
have to have more than one version for developers, users, etc. This is why
I said in another post that if the goal is to be able to communicate the
design to end users, UML is probably not a good idea. Any sort of notation
that is not common knowledge is probably not a good choice unless the
benefits of using it are so high (for both you and the users) that having
the users learn it is something to be considered.
Thus, I think many goings-over of the use scenarios with potiential users
is probably necessary, and the "interviewer" knows some notation or some
technique in order to unambiguously get the requirements down. From there
on, the internal goal is to have unambiguous requirements for the dev team.
However, the general problem of communicating with the end user in "layman's
terms" is not something I have much knowledge about. I'm curious - what
is the experience of the group in this case? My exposure is in s/w
engineering
in which the view of the UCs is in a fairly "advanced" stage (with regard to
how a developer would like to see it).
Chuck
--
I use scenarios because I can reflect back to the user what I think s/he is
trying to accomplish. If Use Cases are normally written from the perspective
of
the system, as is Chuck's example, I think the user would not recognize
him/herself in the task. "Really, I specify a product ID? I thought I was
getting a Twinkie?" And if the developers would find the description
ambiguous,
the who is the audience for the Use Case? What I do is write scenarios for
users, which I translate to lists of functional requirements for whoever is
paying for the project, and then I translate those into page
descriptions/specifications for the developers. I can't see how you can
avoid
re-writing for the different audiences, but I'd sure be open to any
suggestions.
Kay McLellan
Information Architect, IHS Energy Group
Copied from Chuck Lutz's message:
"Use Cases" _do_ tend to concentrate on "data flow", in the sense of an
example like:
Textual UC description: "Next the user specifies their choice of snack
or beverage by supplying a product ID consisting of one letter and one
number, chosen on a keypad with one row of letters and one of numbers."
chuck.lutz_at_telelogic.com on 06/29/2000 10:09:34 AM
To: sigia-l_at_asis.org
cc: (bcc: Kay McLellan/Den/US/IHSE)
Subject: RE: SIGIA-L: IA notation
Hi,
Wow, this discussion gets more interesting with each bounce of the
conversational tennis ball...!
Andrew Gent wrote (first quoting Jesse James Garrett):
>>While I agree that some aspects of UML might find valuable
>>application in modeling information architectures that are strongly
>>dependent upon data models, I have reservations about the
>>practicality of UML in the broader area of modeling user experience.
>>
>>The UML component that seems most applicable, the use case diagram,
>>seems insufficiently holistic to capture the complexities of
>>contemporary architectures in which hypertextual information spaces
>>and interactive functionality are intermingled.
> I am so glad you said that. I was running into the problem that
>whenever I mentioned "user scenarios" to engineers as a mechanism for
>communicating the intended or expected use of a system they would say "oh
>yes, use cases." As a result, for one project, I took a crash course
Could there be a "cultural rift" here between "engineers" and "others"?
>(figuratively speaking) in UML and delivered a requirements document for a
>fairly simple KM system using use cases. Although it was an interesting
>experiment, the resulting spec did a very poor job of communicating the
>"meaning" of the expected transactions. Use cases also provide little or no
Andrew, could you give an example in which "meaning" slipped though the
cracks? This point seems to be the tip of the iceberg, which seems to me
to be the problem of grasping _exactly_ what kind of information we are
trying to capture.
"Use Cases" _do_ tend to concentrate on "data flow", in the sense of an
example like:
Textual UC description: "Next the user specifies their choice of snack
or beverage by supplying a product ID consisting of one letter and one
number, chosen on a keypad with one row of letters and one of numbers."
This would manifest itself as one or two input messages to the UI of
the system. In the case of the former, it would assume the future creation
of some sort of "productID" datatype which would be a composite of a
"character" and an "integer", common fundamental types in most implemen-
tation programming languages. In the latter case, the user sends in two
messages, one containing a letter, and one a a number. The latter case
more closely models the user experience, since they first press e.g. the
"A" button and then the "5" button. Funny, I just realized that I think
most folks "know" to press the letter first. I wonder what happens if
they press the number first. I'll have to try that sometime!
No matter how it's modeled, the goal, _in_the_s/w_engineering_context_,
is to capture the "data" in anticipation of having to represent it in
programming language code in the final implementation.
>mechanism for identifying the relative emphasis on one data flow over
>another.
How do you mean, the "relative emphasis of one data flow over another".
Do you mean likelihood? True the notation doesn't say anything about which,
out of a handful of scenarios, is most likely to occur, other than dividing
them into "main" cases and "exception" (usually error) cases.
The crux lies in what kind of information we want to capture. I wonder
if insight can be had from other uses of UML such as in business or
organizational modeling. I've just started to read a book on the former.
When the end goal isn't software, maybe the vision from the start influ-
ences the modeling in radically different ways; I don't know.
> A standard notation for describing the structure of a design would
>be useful and UML as a notation (minus the current semantics of a
>representation such as use cases) could serve as a good starting point.
As I mentioned in another email, it might be useful as a notation for
capturing high-level, static architectures and high-level "behavioral"
schemes.
It may very well be that models in UML of web sites don't map directly
to implementation as networks of HTML docuements, Javascript functions,
etc. There may be greater resistance in going from the analysis to the
detailed design.
> However, in the meantime I have gone back to representative (as
>opposed to complete) written usage scenarios for capturing requirements;
and
>paper prototypes (of page layouts and the first 2-3 levels of structure)
for
>communicating designs. Other than with professinal writers and designers,
>paper mockups seem to have far more communicative impact than detailed
>"maps". They also tend to avoid bickering arguments over nits and tend to
>elicit "big" questions about the design.
If this works well, by all means, use it. Besides, using UML to communicate
with the customer, in the intent on agreeing on a proposed design, is ob-
viously a bad idea, unless you work only with UML-saavy clients.
That might kill the whole UML argument, although the problem of agreeing on
the requirements for the site design still remains. The requirements defin-
ition starts with natural language and must eventually be formalized in
order
to get an unambiguous design definition.
Perhaps, then, UML (or something like it or any formal notation that needs
to
be learned and mastered) could be used in-house. Internally, communications
with the customer are translated into the notation.
But how, then, do you get the customer to agree that the design is
"correct"?
My brain just popped...
Chuck
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:20 EST
|
