Using 'Page' or 'Screen' in use case descriptions

[fluxtah]

I have asked similar questions like this before, though this particular situation came up in a discussion at work.

I just need to make sure I am doing the right thing here so I thought I would ask the EA community :]

take this for example:

1. The use case starts when the actor Shopper navigates to the Shopping Cart Page.

2. The system displays the Shopping Cart Page.

3..... *snipped*

Considering pages are common terminology for web sites, is this allowed in a use case?

sorry for my simpleton questions, though these things bug me and I see no reason why I can not reference screens/pages within a use case description as most clients who want a web system built are familiar with the terminology 'page'.


Bruce (sargasso) did actually answer a similar question which I could take and apply to this problem too as a page is essentially a UI element of a web browser that houses child UI elements..  however, would be good to confirm wether 'page' and 'screen' are suitable for use case.

regards

Ian

[JourneymanDave]

My own perspective:  I'm not aware of anything like a syntax dictionary for Use Cases, so "page" or "screen" should probably be equally usable, as long as it makes sense for you and yours.  

Experience has taught me, sometimes through hard lessons, that it's entirely possible to get to wrapped up in the details of design and lose focus on the end goals.  It's nice to comply as much as possible with accepted standards so that your artifacts are easily understood by others who are also fluent in the ubiquitous language of UML.  But, having said that, my goals are still to 1) Communicate design, 2) Effectively, 3) In as much volume as necessarily but not more.

Unless you're having a UML "Bake-off" with you techno-buddies, it's probably not adviseable to use everything in the UML or to fret over minute details of the syntax.

[fluxtah]

cool! cheers, I think I am looking into it in to much detail, navigating through behaviour of a page does involve the page itself in order for the user to achieve something.

Just reading the top 10 use case modeling errors in the book - Applying Use Case Driven Object  Modeling

no 7 'Divorce yourself completely from the user interface' made me chuckle :]

regards

Ian

[Oscar]

Fluxtah,

In my opinion there is not one conclusive answer.

It depends on :
- the level of abstraction of the use case(s)
- the kind of "audience" you're writing for

A set of use cases is a means to describe the working of the "system" in such a way that the "audience" can understand it (and comment/agree).

If a set of use cases describes a business proces [high abstract level] don't mention specific UI-details (pages, buttons etc) but keep it abstract.
If the technology is not decided upon (likely if you describe a business proces) : keep it abstract.

If a set of use cases describes the specific (detailed) use of a system [low abstract level] or the technology to use is know you can mention specific UI-details.


If the "audience" are managers you can/should keep it more abstract.
If the "audience" are end-users you can/should put more details in the use cases.


In the "detailed" case I personaly like to keep the description of the use case flow as abstract as possible and describe the details in a separate (foot)note.


In your case I would mention the shopping cart page in the flow, but the (exact) layout and all buttons or hyperlinks would go in the (foot)note.


Oscar

[thomaskilian]

Hi Oscar,
that corresponds very much with the following:
http://www.umlchina.com/Indepth/howto.htm which was mentioned earlier in this board:
http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=UMLPRO;action=display;num=1076246030

Using Use Cases seems to be most confusing Would be nice to see all Use Case related topics in one directory here.

Cheers,

Thomas

[fluxtah]

Cool, thanks for your input oscar, I guess the decision goes with the job!

Essentially if you was to do a Use Case for someone to enter another world through a single door, if the only way to get through the door was to push the handle, then pushing the handle of the door would need to be described, and a handle is ussualy a common element of a door.

regards

Ian

[mbc]

In my opinion, the important thing is not to make design decisions in the Use Cases. Use Case writing should be requirements definition, not user interface design.

In your example, if your door to the other world is already given by external factor before you start your design - then you can mention the handle. BUT if the door is part of the system you are designing, and you write "door handle" then you have already excluded other options. Later in the design phase you will not have the freedom to decide on a button or infrared device to activate automatic opening of the door.
A more abstract text would give you more freedom in the design: e.g. "The user activates the door-opening mechanism" or even simpler: "The user opens the door".

I hope this wasn't too obscure  

Mikkel

[fluxtah]

No your totally right mbc and I agree entirely, if a client specifically requires a door handle and it is stated that 'the door shall have a handle' then I would include this in the use case description If not like you say a more abstract text would allow more freedom in design.

thanks for the help!

regards

Fluxtah