Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case Modelling - Advice on an example
Previous Previous
 
Next Next
New Post 9/15/2009 10:52 AM
User is offline Binny
5 posts
10th Level Poster


Use Case Modelling - Advice on an example 

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
 
New Post 9/15/2009 3:50 PM
User is offline panofoot
11 posts
10th Level Poster


Re: Use Case Modelling - Advice on an example 

Hi BK,

I think that perhaps your problem is that you're trying to shoehorn your User Interface into Use Cases, when perhaps Use Cases aren't necessarily the best technique for the job. If you're struggling to think of ways to use a technique, then perhaps consider alternatives to represent the flow.

Use Cases are traditionally used to define behavioural requirements, and not GUI design. Some people do use Use Cases for the GUI, but I'd be wary of it personally. Also bear in mind that even when defining requirements, Use Cases aren't always able to catch every single functional requirement. The same would likely be the case for GUI design using Use Cases.

Regarding 'decomposition' of Use Cases, I'd definately avoid that. Use Cases typically represent user goals, something of definate observable value. That being said, have you read about Alistair Cockburn's ideas regarding different levels of Use Cases? See book "Writing Effective Use Cases" or an article http://alistair.cockburn.us/Structuring+use+cases+with+goals. Use cases such as "Update GUI" can be considered 'Subfunction' Use Cases.

For 'Capture Trade', you'd be better off explaining the combination of alternatives in a model attached/referenced to the Use Case (decision tree, activity diagram or the like).

Hope that helps.

Graham

 
New Post 9/17/2009 2:57 AM
User is offline Binny
5 posts
10th Level Poster


Re: Use Case Modelling - Advice on an example 

Graham,

Thanks for your reply. I know the system well and therefore all the functionality in the guis etc. Its not that i am trying to document the gui, I just felt that there were so many different paths for trade capture that not one is considered basis, and therefore I should decompose maybe to the 10 or so product types, else the UC will get long and complicated? guess thats my call. the trade capture is not complicated in terms of branches/conditions, its just has different info for different product types and therefore different results in how its eventually commited to the database (again, ignore this design element but this is to remain same as we are keeping that processing and have to define it now).

I have alistair's book, just starting to read, time permitting of course.

I did post another Q on the forum on a complicated gui screen where the user may have 50 different paths, ie. functions/behaviour and am still stuggling to think how or if to break that down? there is one basic path i can think of for that example though, the rest of the functionality are options and manipulation of data on a screen.

BK

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Case Modelling - Advice on an example

Community Blog - Latest Posts

In today's ever-evolving market, businesses must adapt swiftly to remain competitive and meet the needs of a fast-paced digital economy. Among the various business strategies available, digital transformation, customer-centricity, and sustainability have emerged as top priorities. Let’s explore why these strategies are critical for busine...
The Cisco Certified Network Associate (CCNA) certification is a pivotal credential for networking professionals, validating your skills in networking fundamentals, security, automation, and programmability. Preparing for the CCNA exam can be challenging, but with the right strategy, resources, and mindset, you can successfully achieve this certific...
The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC