[UCR] Resolving overlaps between use cases 1.1,1.4,1.5

As agreed in yesterday's telecon, here a short summary of the issues 
around use cases 1.1, 1.4, 1.5 and some suggestions how to resolve 
possible overlaps here. Obvously, I was not the only one arguing in this 
direction, since also Dave pointed out that the difference between 1.1 
and 1.4 is unclear, and Paula agreed that 1.4 and 1.5 are a bit too similar.

Summary:
At the current stage of the document it is not entirley clear on what
criterion these use cases shall be discriminated:
a) Different application area/domain.
b) Different technical requirements for RIF.

a) this is not the case, all these have a similar and partly overlapping 
scenario which can be subsumed under
  "Alignement/maintainance of business rules and policies" and could 
easily and fruitfully be combined in one scenario.
b) might well be the case (I try to make the differences clear below), 
but needs to be made clearer.

While a) would justify merging the use cases into one, b) might
justify to keep them separate. However, to this end the differences 
should be made clearer (see my last mail on a suggested "template" 
structure for each use case, we should try to bring the use cases in a 
consistent format which gets the gist out of each use case packed in a 
nice narrative and pointing at requirements already).

----------------------------------------------------
Specific overlaps/touching points:

1.1 is about negotiating business rules as contracts.
1.4 is abour executing/processing business rules, the overlap is that 
the example rules in 1.1 could be equally seen as the same *kind* of 
rules than in 1.4 which are then executed/processed in a colaborative 
process or on a single engine.
1.5 Is again a similar domain, although it does focus on a different 
aspect, namely what Francois often desricbes as normative rules, I think 
this can be also described as rules checking "consistency of the 
application of the kind of rules in 1.1/1.5 during the running process.

Suggested resolution:

I think this could be nicely combined into one use case with a coherent 
single story which outlines the different stages of business rules usage:
a) contracting (static and dynamic) business rules  and checking static 
consistency.
b) processing and dynamic integration/update of new rules while 
maintaining consistency with the plicy requirements,
For all these aspects the requirements in the end of 1.4 hold: "For this 
to be viable from a business perspective it is critical that the 
semantics of the rules and query exchange be completely predictable and 
preferably loss-less."

Even if we keep the use cases separate, I would prefer, if they use the 
same narrative (same fictitious company/ies, similar scenario), but 
focus on the different aspects in the way outlined above.


  I would also offer help in editing the use case doc next version, if 
this is appreciated!

best,
axel

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Wednesday, 15 March 2006 09:21:14 UTC