I would agree with the other comments, and would probably treat the upper level data points as parent <nodes> that direct the use case to flow in a differrent direction depending on the child <nodes> selected in the senario. This is probably better detailed in a matrix or something to the xml effect listed below. I would still develop a basic use case that flows through the upper level nodes, and not list the data points that are at the child node level. Hope this helps!
<business logic 1>
<data selection 1>Path 3</data selection 1>
<data selection 2>Path 5</data selection 2>
<data selction 3>Path 3</data selection 3>
</business logic 1>
Hello All,
i was reading on all of the discussion about this particular scenario and Well my two bucks would be so :
1, one thing which is clear from the discussion is that there are lot of scenarios to be dealt with, so a good option would be generalise and put those together as a table and that table can be embedded into the UCs. We do the same when for 10-12 cases we have huge no of values, then a tablular form of data would best describe it.
2, at times, we may land into a situation that can not dohardcoding- "where you dont have exact values", in that scenarios, we have a template of a UC where we can state different scenarios and we call them as ALTERNATE SCENARIOS/CASES. those would give you all the space and detail to capture such requirements and explain them clearly.
But yes, if its generic and very highly threaded, then modelling of the requirements to understand the complete flow and then illustrating through UCs should help. Not sure that every time we can change the way we gather requirements and we may still be needed to use the UC model or any specific one under use.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: