This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes GUI requirements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "GUI requirements" Watch "GUI requirements" New topic
Author

GUI requirements

Wladimir Babitzki
Greenhorn

Joined: Apr 27, 2004
Posts: 19
Hi!

It's interesting, which documents or formats are commonly used for setting GUI requirements.

I used to describe general Business Process as Summary Use Cases with the overall scope. From the Summary Uses Case it's handy to reference the Use Cases, which define the complete system functionality, and so on to the Functional Use Cases with GUI description.

The most problems caused this last level of Use Cases, especially by GUI developers, who can't look through the Use Cases approach. So I think that the way applying to GUI is too complicate and too artificial for setting clear implementation requirements.

I'll appreciate if you can share your experiences or advice some techniques/strategies for a smart problem's solution.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
It's interesting, which documents or formats are commonly used for setting GUI requirements.


If you drop by Agile Models Distilled you'll see that I have described several UI-related artifacts. If you're interested in understanding UI requirements, essential/abstract prototypes are a good option. If you're interested in documenting the requirements, which I question the value of, then a screen specification which has a picture of the screen and description of each field is a strategy.


I used to describe general Business Process as Summary Use Cases with the overall scope. From the Summary Uses Case it's handy to reference the Use Cases, which define the complete system functionality, and so on to the Functional Use Cases with GUI description.


Your use cases should reference your UI elements, such as screens and reports. See this example.


The most problems caused this last level of Use Cases, especially by GUI developers, who can't look through the Use Cases approach. So I think that the way applying to GUI is too complicate and too artificial for setting clear implementation requirements.


You need to understand that use cases are only one of many requirements artifacts. See Use Cases of Mass Destruction. If your GUI developers are having a tough time, why don't you follow the AM principle of Model With A Purpose and identify what they actually need from you? Better yet, follow the practice Model With Others and work with them to develop what they need. Handing documents to people to tell them what to build is a spectacularly risky way to work.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
The "format" we use is face-to-face discussions with the domain experts, often in presence of an early implementation.

We also don't have dedicated GUI developers. The developer working on the business logic also develops the GUI for it, which means that he typically already has a quite good understanding of the context the GUI will be used in.

Of course we do have developers who are strong in GUI development, and some who aren't. The latter typically will ask the former for help, possibly even be pairing on the GUI.

Works quite well.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Wladimir Babitzki
Greenhorn

Joined: Apr 27, 2004
Posts: 19
Scott and Ilja thanks for your valuable input, this information and references should bring me to the right way and clear the issue
 
Consider Paul's rocket mass heater.
 
subject: GUI requirements
 
Similar Threads
Domain Models
GUI design choice for the SCJD
The Case Against Use Cases
Urly bird find method: are search criteria "and"- or "or"-composed?
use case