Carmel,
No concreting this time, I’m taking Kimbo’s advice!
When confronted with these convoluted requirements, always revert to the basics of a use case. We identify the user and the user’s goal. Secondly, a single screen could map onto multiple use cases and vice versa.
So, given the complex design constraints placed on this requirement how would you 1) identify the users, and 2) identify the goals of each user. At a high-level each of the goals becomes a use case.
Lets say the goals are 1) to capture/record client information (this covers cleint capture and imports); and 2) to make client details available to others (this covers the export functions).
Here is a sample snippet for goal 1:
Goal: capture/record client(s) information
Main Scenario
1. This use case starts when the clerk is presented with the new client options screen (scr:CLi).
2. The clerk selects the “Enter Client details“ menu item
3. The system presents the “Enter Client details“ screen (scr: CLi001-001 with two tabs)
4. The clerk enters the new client data. Current address at Tab1, and other address at Tab2.
5. The system records client details and displays “wow another client”
Exception
2.1. The clerk selects the “Import client details” menu item.
2.2. The system presents the “Import client details” screen (scr: CLi002)
2.3. The clerk enters the file location and format(XML, CVS format)
2.4. The system uses the import file at specified location and updates client data.
2.5. The system displays “wow heaps more clients”. This use case end here.
Post Condition.
New client(s) established
Sample Screens:
Note: all screens are mock-up VB screen editor/dumps)
CLi – Main Menu
CLi001-001 – Enter Client Screen
Cli002 – Import Client Screen (etc..)
All the best,
K