use case prob

[fluxtah]

This is something that probably does not belong in a use case but it is a requirement.

The requirement is

'The user of the site will find a widget listing by selecting a region on a map or from a drop down menu.

The user should be able to order the list of widgets by either column name or the amount of times the widget has been clicked'

Now take my use case flow for 'Find Widget':

1. The actor Widget Finder chooses a region.
2. The System displays a list of widgets.


The use case is only part of a the sequence but would be the point that the requirement would matter.

Now where do I put the requirement? I could make the use case realize the requirement and draw some UI mock ups, but is that all i could do? :]

regards

Ian

[sargasso]

I think you are right???

As you have written it the outcome of the UC is a sortable list of widgets.  Perhaps a rename to "Create area widget list" is indicated.  

My reading of your text is:
1. user invokes the "Create area widget list" UC by (doing something somewhere else probably in a "Navigate the Site" type of UC )
2. The system displays a clickable map of (something) and an equivalent dropdown menu of regions
3. The user selects a region
4. The system displays a list of widgets associated with that region
5. The user peruses the list and can request that the list be resorted by a specific column or by the number of times that the widget has been clicked ()
6. The system redisplays the list in the desired order.

Now there are other interpretations of your text possible, but is this what your after - it seems to me that the UC name may be forcing you into thinking a certain way.

B

[fluxtah]

Actually now you put it like that it fits ok into the use case, if the client read it they would be happy to see there requirements involved in the scenario, although I question why some practioners warn  not to use words such as click, etc, however in this case I see no reason why not to include the detail as the model is well known to be a site and things like clicking is a primary function of a web surfer..

Is it ok to include reference to UI elements within a Use Case? or does this depend on the domain of which the solution will be modeled?



regards

Ian

[sargasso]

Ian,

In the main I strongly agree that UC descriptions, requirements and constraints are not the place for UI specifications.

We recently reviewed a project here where the business had specified all their requirements to the UI component level.  The IT team spent 25% of the project deciphering the true business requirements from which they could derive the system requirements, and then another 8% of the total spend redesigning the "proposed" UI to meet:
1) corporate image standards, as the app had some public exposure (which the business should have been aware of)
2) corporate IT standards, which has policies limiting the
UI components used to allow the interoperability requirements of the enterprise architecture to be met (multinational, multilanguage corporation)
3) their own ideas and ideals as to what the UI should look like.

The business reviewed the revised UI and agreed that it was much better than their ideas.

So, I reckon that in general you (i.e. the mankind type of "you") should strongly discourage the inclusion of specific UI commentary in any use case or other requirements level annotations ... with the following provisos:

1) Particular to web delivered apps, there are so many "objects" that provide/enrich/whatever the user experience, such as clickable maps that it is fair for the users to express UI requirements as sort of generic display requirements.  Your example includes an intrinsic (as in not expressed directly by the user) requirement that "the system shall provide alternate widget-region selector mechanisms - graphical and text based", i.e. the combobox and the clickable map.  In this case I would not bother to translate the user expressed requirement further than I did in the previous reply - it is expressed in the language that the user understands. However, I would query the reason for alternate selectors!  I would discuss with the user whether their is a true requirement to provide both mechanisms, pointing out that the text based selector is only going to work in one language, and is that a problem etc etc.. or maybe they are trying to cope with a specific target audience with some sort of usage challenge.  You see what I'm trying to get at?  They may have a very good reaon for 2 mechanisms, but their expression of the requirement for specific UI types rings warning bells in the "what is the REAL requirement" department.

2) Remember my other raves - UC models are a way to come to an agreement with the client as a framework for the true expression of detailed requirements.  If the language of the user is such that UI "expressions" are convenient then so be. But if you are an external supplier then beware!

Bruce

p.s. Tips & Tricks department - one of the techniques we use when we have similar problems with use cases to yours, and its a fairly common occurrence, is to throw out the usecase name and rename it.  By forcing yourself to think up a new name sometimes the fact that you have caught yourself up in a technical viewpoint rather than a usage viewpoint becomes apparent.

Cheers!

[fluxtah]

Cheers Bruce, thanks very much! that cleared up a LOT of things :]

regards

Ian

[fluxtah]

hmm I am stuck again on this kind of question  

ok. I have a requirement that specifies a certain way to 'Find a Widget'

The widget has a few properties, and also there are a list of many widgets...

Now it is specified, through Usability/UX activities, that a panel that provides categorised criteria that acts as a filter for the widgets, to display less and less widgets as the user clicks down a matching criteria to the widgets properties, until an option from each category has been selected... now already this is quite complicated to explain!

Anyway, I understand what the client requires, however I have had to think of a name for this specific UI element, I called it 'Widget Filter Panel' and have described what categories it contains.

not sure if I should do these things though if someone says, I wish to have a panel that pops up and allows the user to select a date from a calander, i could call this 'pop up calender panel' whilst referencing it during using case descriptions?

It's jsut my use case was queried today for the use of 'Widget Filter Panel', I can leave the description of teh Widget Filter Panel to the glossary.

would be interested in your thoughts  

regards

Ian

[sargasso]

You are moving from requirements to design.

But that' OK.

What you seem to be describing is that the user has a requirement for a complex (to describe) filtering technique by which they can narrow down the list of displayed widgets.Filter Displayed Widgets
«Display» Requirement:  The user must be able to narrow the list of widgets displayed on the xxxx page.  An appropriate mechanism would be to provide a means for the user to select values for each widget attribute and redisplay the list as each attribute value is selected.

The user can select only one value for each attribute ()

The user must be able to clear the value of an attribute, thereby "defiltering" the list. ()

etc ..

This requirement seems to me to be part of a "View Widget List" use case.

Now, by discussing the implementation of the requirement with the user in terms of concrete UI ideas, you will have

[a]to the purists, moved out of the requirements gathering phase and into analysis and design, and
set an expectation as to how the end product will look and act, if anyone in the development stage comes up with a "better" idea (cheaper, easier to implement, flashier, easy to use etc) it will be harder to sell that back to the user as they may have to think again.
[/list]
The method we (royal we) prescribe here is to be extremely up-front with the business when talking about UI prototypes, we stress the word prototype loudly and repeatedly.  EA has a remarkably wonderful UI prototyper that lets us talk through ideas with clients and discuss very abstract UI concepts.
Something like this..

allows you to discuss without committing development.

hth
Bruce

[fluxtah]

Cool, the UI prototyping will help our IA/Usability dude create mock ups of the UI component his activities have lead him to require for the current project.

The steps you described are correct, I was actually given an example of the functionality on this page

http://www.tesco.com/winestore/

You basically choose a wine attribute, i guess the attributes are gathered from wines available and you use the panel on the left to filter through the attributes, which are categorized.

I can see how this can work in code, though to describe it in a use case is of difficulty.

The use case here i guess would be to 'Buy Wine'.

The idea the IA/Usability dude had I guess was that this filtering technique always has a result, you can never filter it enough to display nothing :]

The real world project aside from widgets is actually  recruitment site, where you essentially go to the site to find a job... using this proposed UI filter thingy that works so wonderfully for wine bottles  

which makes me wonder about the use case description for 'Find A Job'

The use case starts when the actor Job Seeker selects an option from the 'UI filter thingy that works so wonderfully for wine bottles ' doesnt quite fit

[sargasso]

Buy Wine
Browse available wine

Find a Job
Browse Current Jobs

B

p.s. If you're an Aussie/wine fanatic that's the funniest site I've seen recently!
xxx Unwooded Chardonnay 750
Unoaked Australian Chardonnay with appealing flavours of citrus and tropical fruit. Drink with fish.

Drink with fish!! Drink like a fish

[fluxtah]

  cheers Bruce, those use case names seem much more appropriate.

Ian

[fluxtah]

This is the best I can come up with  for 'Browse Current Jobs' using the writing style described in Use Case Modeling on the object techology series books.

pre-condition:

The actor has navigated to the home page.

Flow:

{First Option Selection}

1. The use case starts when the actor Job Seeker selects an option from the following categories:

division
role
salary
location

2. The system re-displays the page and  the list of categories excluding the category from which the option was selected from.

The system also displays a list of Current Jobs that match all remaining options from all remaining categories.

{Select Another Category}

3.  The Job Seeker selects another option from a category.

{Check More Categories Exist}

4. The system checks that more categories are available to display.

{Re-display Page}

5. The system re-displays the page and  the list of categories excluding the category from which the option was selected from.

The system again displays a list of Current Jobs that match all remaining options from all remaining categories.

6. The use case repeats at {Select Another Category}

if no categories are available to display the use case resumes at {Use Case Ends}

{Use Case Ends}

7. The use case ends.

Could do with more work the more I found out about what is really needed, for instance what happens when there are no categories left? will there be a big blank spot on the screen where the categories where? - These questions I need to gather and ask, considering the wine example involves many more options to browse available wine other than the filter feature.

Ian

[sargasso]

These questions I need to gather and ask,

You betcha!

(now you know what its all about)

[Captain_Ding_Dong]

Ah great Australian wines and learning to refine Use case modeling techniques.  It could only be better if I actually was in Australia drinking the stuff.  

Oh gloom I,m still in South Wales and its raining again, wheres my passport and credit card! Taxi................