Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

GUI requirements

 
Wladimir Babitzki
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Wladimir Babitzki
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scott and Ilja thanks for your valuable input, this information and references should bring me to the right way and clear the issue
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic