views:

37

answers:

1

My company develops a rich GUI from a detailed specification document, written as 100+ Use-cases (UC's). These detailed UC's drive the development. They are written as tables with actor and description columns. We (me and others) have mangled real UC prose style to support the interactive nature of our application.

We also use the specification to generate (manually) a test spec, so the detail (to me) seems important. This test-spec is used in verification to get sign-off.

Note: There are many more components to our product than just the GUI. The GUI team is 6-10 strong, the project as a whole, about 60.

Until recently I used to create a "storyboard" document detailing each panel and its interactions in relation to the specification. There also used to be a GUI architecture, plus designs for major sub-components. Ouch! It has led to very slow development times, a poor code base (ha!) and a poorly motivated team.

The app is more of an IDE, allowing users to create their own test-cases (for mobile 'phone testing) using a drag'n'drop, flowchart idiom. It is very complex, mature (7+ years) and offers many functions. The test-cases are then run and the results analysed. Being such a free tool (user can follow a nearly infinite number of paths through the tool), it seems to make a nonsense of sequential use-cases. We use "O" to mean optional, "R" to mean repeatable, nesting and many other "extensions". UC's are fundamentally a poor match for designing an IDE's interactions. Think of this app as offering a blank worksurface (like a word-processor, or spreadsheet), where users can do anything, in any order: this has led to the UC bloat.

Currently there is a desire to simplify the specification from 100+ UC's into fundamental UC's: "Develop Test-case", "Run Test-case", "Analyse Results" (or something similar).

Whilst I understand our UC's are not "true" UC's (focussing on the business value), my concern, as team lead on the GUI and also developer is that without the detailed information, my guys won't know quite what to develop. Three UC's just seem too abstract.

We follow a form of Unified Process, with spec done up-front. Perhaps we should change to a more agile process, with developers themselves doing the interaction design.

A: 

In OpenLaszlo recomend a four steps design process: 1.Wire-frames. 2.Storyboards. 3.Animations. 4.Engineering prototypes.

It's very interesting...alt text

Aito