Use Cases vs. Scenarios == Advice needed..

[bob_d]

My company makes a software product (call it Product A) which (loosely speaking) "synchronizes" appointments, task and contact information with two other commercial products (call them Products B and C).   We obviously do not have source access to B and C.   I have been charged with getting a conceptual and product direction grasp on this.

I have a set of (roughly) 100 use cases related to the subject matter from an independent consortium which depict the abstract use cases that arise in calendaring/tasking operations.   What I'd like to do is use these as a "reference set" to discuss the  various implementations of "synchronization" (product A-B, B-C, A-C).

To do this, I need to depict the actual use case a User encounters in product (A/B/C) when the original appointment/task/contact was created in product (A/B/C) -- so there are 9 permutations (A-A, B-B, C-C, A-B, A-C, B-A, B-C, C-A, C-B).  

I can see a number of ways to model this and would like some advice from the real veterans on this board.   The possibilities I see are:

1.  Model each permutation as a use case realization of the relevant abstract use case.

2.  Model each permutation as a scenario within the general reference use case.

3.  Model each RECEIVING product as a use case realization off the relevant abstract use case, with different scenarios for each ORIGINATING product.

4.  Model each ORIGINATING product as a use case realization off the relevant abstract use case,  with different scenarios for each RECEIVING products.

Does anyone have any helpful hints/analytics suggestions on this situation ?   I'm leaning toward option 3,  but all the options are a considerable amount of work (9 permutations times 100 reference use cases), so I'd like to avoid false starts/blind alleys.

Thanks in advance for any insight you may have.

Bob

[thomaskilian]

Sorry, but I don't get it with these permutations. For me there are just the UCs you have with your product. The rest is just different state models you have to go through. These might be the faculty you proposed. But the UCs definitely are NOT. I anyway wonder where you would have a 100 UCs in a calendar synch tool...

[bob_d]

Thanks for the prompt reply Thomas.   Let me try and explain why I think they MIGHT be different use cases for the permutations.  

The "worst-case" situations involve recurring appointments or tasks.  Say the User has created a recurring appointment in Product B which has been synchronized to their own calendar in Product A.  They now wish to modify the Nth instance of the recurrence from within Product A.  Because these products (A,B,C) all have different underlying data models and implementations of recurrence, the ACTUAL CAPABILITIES which can be surfaced to the user differ depending on both the originating system and the system on which the action is being performed.  Since what can actually be done differs based on the permutation of originating and receiving system,  I am thinking each permutation is a different use case and/or scenario.

Did that make it any clearer ?

Re your last point on "100 UCs in a calendar sync tool" -- I refer you to the reference set at the Calendaring and Scheduling Consortium here :  

http://www.calconnect.org/usecases.shtml

Bob

[thomaskilian]

Well, the first mentioned document shows 6 UCs (looks appropriate) and the 2nd is just numbering a lot of CRUD. There are quite some opinions about what is a UC. But the only first sight relevant UC I see is: Synch Calendars (and likely Manage My Calender and a few more). I'm pretty sure the Synch Calenders is VERY complex when using multiple source (I know from personal experience). But that definitely does not mean there are more UCs. NO! It's just that the scenarios get very difficult. And the solution is not to create a bunch of additional UCs (be warned: stay away from <<include>> and <<extend>>; read books about UC modelling, like g.e. from Bittner et al.). It's a matter of how to describe the relevant UCs. And that will likely lead to another kind of problems you will encounter. (It's Sunday night here and I'll go to bed now. I'll leave the field for the next time zone )

[bob_d]

Just FYI.  

The third and particularly fourth documents on the CalConnect reference contain the most information/"use cases"/"scenarios"/Gordian knots.

Regardless of whether these items are "really" use cases or not,  it's still the problem I have to capture and manipulate in the model to make sense of the situation for both development and marketing.  And it definitely matters in each "circumstance" what system you are using and what system originated the appointment/task/contact.  

[thomaskilian]

2nd means the 2nd mentioning UC in the title so it's actually the fourth' you mean. And that just mentions CRUD. Well it's really late for me - I'm asleep soon..

[sargasso]

Hi Bob,

I've only had a quick glance through the CalConnect docs, but I must agree with Thomas here.  I haven't gone as far as counting them, but if you'll allow me a little latitude there seems to be some confusion between use cases and the objects that they are manipulating.

The "use cases" in CalDev Usecases seem to be specified at the second dot point level, e.g. in section 4 at 4.2 we have two lower level items that are merely specializations of "modifyCalendarattribites".  They would probably follow the same pathways (steps) and the differentiation is merely which attirbute of a calendar instance is being modified.

By way of another example, the regional rail operator here in NSW sells reservations on services that may be trains or coaches.  There is no difference in the user's view of the system dependant on the service carrier type.  All the user  wants to do and all the system behavior specification is for the usecase "Book Trip".

Similarly, I agree with Thomas that a lot of the specifications appear to be CRUD breakdowns.

In fact I might go asa far - depending on the model audience to suggest that there are only two use cases at a meta level, "manageCalendar" and "manageCalenderContent".  However, here YMMV.

To get back to your original question, though.  If I take it correctly, you have a system "ProductA" whose objective is to provide synchronization between "n" instances of external systems "ProductB" and "ProductC".  From my POV then, lets consider the live operations of ProductA.  It merely awaits requests from an instance of a ProductB or ProductC and based on the nature of that request requests an appropriate service provided by one or more instances of a target ProductB/C.

Hence, for ProductA there is exactly one usecase so far visible, "respondToRequest".  There are probably a few more, depending on the real requirements for ProductA, say "displayLog", "startOrStop" etc.


hth
bruce

[bob_d]

Thanks Bruce.  

Regarding your last  two paragraphs, "ProductA"  also has a calendar system, complete with UI -- it's objective is NOT to provide synchronization BETWEEN  ProductB and ProductC but to synchronize WITH them as a (small) product feature of ProductA, either individually or in customer installations which have all three Products.  So the calendar in ProductA has to synchronize with the calendar in  ProductB in the situation where the calendar event may have originated in either product AND the possible actions depend on which system has which role - the same human being may have logins in both systems and may create and view calendar events in either one.  

I'm not disagreeing with the CRUD comments either regarding the CalConnect docs, but manageCalendar and manageCalendarContent seem to me to be so "meta" as to be TRUE, but fairly useless from a product-driving practical perspective.  It seems to me that you have to at least get to a level of business purpose with the use case -- i.e.  manageRecurringMeeting,  maybe even rescheduleRecurringMeeting or cancelInstanceRecurringMeeting.  

Are these not valid business purposes in the Use Case sense ?  They are atomic business results which are initiated by a  (human) actor and may be implemented in a variety of ways, unspecified in the use case.....   In my particular problem,  the system may behave differently in realizing those cases due to the underlying implementations of Products B and C -- (back to my original question).

Bob

[sargasso]

Regarding your last  two paragraphs, "ProductA"  also has a calendar system, complete with UI ....

OK, my mistook.

I'm not disagreeing with the CRUD comments either regarding the CalConnect docs, but manageCalendar and manageCalendarContent seem to me to be so "meta" as to be TRUE, but fairly useless from a product-driving practical perspective.

Indeed, I was "abstracting ab adsudium"
 

It seems to me that you have to at least get to a level of business purpose with the use case -- i.e.  manageRecurringMeeting,  maybe even rescheduleRecurringMeeting or cancelInstanceRecurringMeeting.  

Are these not valid business purposes in the Use Case sense ?  They are atomic business results which are initiated by a  (human) actor and may be implemented in a variety of ways, unspecified in the use case.....   In my particular problem,  the system may behave differently in realizing those cases due to the underlying implementations of Products B and C -- (back to my original question)

Yes(, and no).   Again, as I have said before elsewhere, you need to consider the usecases from the perspective of the actor(s) involved.  Now I see that ProductA (henceforth "BobCal", I'm sick of typing that)  is a calender app in its' own right, let's look at it from the pov of BobCal's actors.

Actor::bobCalUser
Actor::productBinstance
Actor::productXinstance

I'll leave that as an exercise for the reader... gotta meeting.

bruce

[Jan ´Bary´ Glas]

To add something from my point of view:
It is a thing of abstraction a sense of different views. We all are used to describe black-box behavior a goals of a system within UseCase view of our models.
The UseCases specifies what an actor wants to accomplish with using your system. As I have heard somewhere "what makes him wake up from his bed, start his system (computer and application if you want), do some work with it and close it feeling satisfied".
If you describe this level of things you may go deeper and the way is much clearer.

HTH,
   Bary

[bob_d]

Thanks Bruce for this:

Actor::bobCalUser
Actor::productBinstance
Actor::productXinstance

This seems like a helpful framing suggestion to reduce the complexity factor and sort out some noise.  I'll work from this angle for a bit (and keep you apprised).


Thanks to Jan for your description of the UseCase-Actor "satisfaction" relationship --- it's a good reality-check criteria to avoid (personal) madness /thrashing.  

(I'll keep this thread updated as things unfold. )