Rogs & K,

My old mate kmajoos makes the classic mistake of people using use cases to design a solution i.e. screens etc. If you have design e.g. UI screens, fields etc in your use case, then when these change you have to go and change your use case. If you want to design screens, then use a UI specification. e.g. line 2 of the main flow above - The system displays the request screen (see GUI-001).

This approach means your use case is tied to your solution and use cases are by definition solution independent. To continue the example, if the company decides to allow mobile access using say a PDA, then having defined a particular screen in your use case, your use case is invalid and must be revisited. But if you've just defined the function, no change is required.

Understanding this is crucial to writing good use cases.

Another thing about use cases, don't assume one use case equals one screen. The relationship is many to many. In the above example, if another screen was required to enter parameters or something, then the use case must again be changed.

I suggest these artefacts in your case Rogs

• functional definition - including use cases that defines the functions (and process or whatever else fits) in the system and is solution independent
• UI definitions
• Report definitions

Kimbo