Hi,
I have a few questions on how I can model the follwing via Use Cases and I would appreciate advice on any of the questions I have belowo . To put it into context, we have a vendor trading system that initially we want to replace the GUI screens such that it performs the same functions as existing GUI - processing of trades must hit same database (existing guis commit via client screen). The main GUI is is the Trade Capture screen/functionality where the actor can input different product types & flavours, possibly upto 10 types. Each type can lead to commiting between 1 row or 10 rows into the trade table (please forgive the design element here but as processing into database remains the same and I wanted to give the relevant context).
In summary, the Use Case "Capture Trade" can therefore be used to manually capture many different types all relevant to the actor. Depending on the trade type, different data is required for input and also results differently in the no. of rows in the trade table.
Question 1)
Should I consider each type of trade input as a separate UC? Ie. "Capture Trade" is a high level UC and I decompose to these 8-10 different types? The alternative is to pick one as the main flow and do the rest as alternatives but there is no obvious main one as it stands ? im leaning more towards doing a different UC for the more common types, ie. merge a couple in. So a "trade capture" UC will decompose into 5 or so UC's.
Question 2)
Current gui's perform the trade processing (ie. commit to database after trade capture) within the client . Regardless of whether the new design will be to do in client or server process for the NEW gui's I am struggling to think of how to capture this as a abstarct UC level. If I add the processing at the back of the UC (or multiple UCs , see Q1) as the final step, then I have to repeat this processing for "interfaced STP trades" (another UC we have to do later) as the same processing has to occur for that process. So should I create a new UC called "commit trades" that is an included UC to the "capture trade" UC ? My reason for separating is that it will be used by another UC.
Question 3)
New trades that are captured (or even amended or cancelled) are to be reflected realtime in other gui's (approx 4 different GUI types). Where do I document this process "update GUI" - It seems to fit in the same place as Q3 , ie. separate UC thats an include in the "trade capture" , "amend trade" , "cancel trade" Use Cases? If I don't use an include and its a standalone UC then the initiating actor is a Use Case eg. "Capture Trade" which doesnt seem right.
Any thoughts on the above will help me think about an approach on this. I have urges to decompose a high level UC which I sometimes feel I might have to do but at the back of my mind I have to think about the rule of not decomposing. I am trying to document a level that will mean something to a user and a developer, these are all system use cases only.
Many thanks,
BK