Structured specifications + included use cases + exception paths

[Bob Burdett]

Hi,

I’m working on a project where the customer has provided some detailed rules about how to validate a type of document.  This validation gets used in a lot of places and I have created a use case that can be included in other use cases.  There are 5 possible outcomes from the validation use case, including success.

My issue is, that when including the use case in the structured specification of another use case I can’t attach any exception paths to it to handle the 4 non successful outcomes.  I also can’t handle the exception cases in the included use case because they are handled differently depending on context.  E.g. when validation is executed in the context to reviewing a document the errors are politely pointed out to the user. But if the validation is happens as part of submitting the document then all sorts of alerts can be raised.

This can’t be the first to encounter this, so I’m looking for advice on the most appropriate way to document the handling of exceptions triggered by an included use case that need to be handled by the including use case.

Thanks
  b.b.

[qwerty]

Well, the structured UCs are kind of a good idea. But they are only half bred. You can have only one level of exception. What I do and recommend is to use plain notes text and enumerations to describe use cases (Cockburn style). That gives you complete flexibility. The drawback is, that you need to maintain step references manually (e.g. if you have a "repeat at step 5" and you insert a step before #5 you need to change the reference).

q.

[Helmut Ortmann]

Hi,

there are a lot of views about Use Cases.

I don't like the idea to functional analyze some behavior. I also don't like the idea of complicated and well-thought <<include>> or <<extend>> relationships. Often it is possible to add a Use Case or a note to make things clear. Thinking of scenarios could be a good idea. Scenarios are linear and easy to grab.

In my point of view, Use Cases should easily depict the benefits a stakeholder has from the system at hand. Show the important things and avoid too many details.

For complicated or nested things UML has a lot of useful tools.

Kind regards,

Helmut

[Bob Burdett]

Hi,

Thanks for the responses.   It seems to me that being unable to add an exception paths when a step has been linked to another use case is just a limitation of the tool.  I did fear there was some fundamental reason not to do it that I was missing.

As Qwerty has said the issue  can be got round by using the plain notes, however this sacrifices all the benefits of the structured approach.  I’ve chosen a more middle way adding the link to the use case as just a context reference. I’m sure there will  be some problems with this down the line but I still get the benefits of the auto numbering. (I’ve had cause to be thankful for this on a number of occasions.)

I fully take Helmut’s point, that use cases are supposed to be easily digested by business stakeholders and therefore using a lot or includes and extends only makes things complicated.  However in this case the customer has provided a lot of detail in the user requirements specification, right down to exception conditions and the specifics of this validation process. In fact the user requirement specification runs to over eight volumes, so in this case the idea of keeping things simple for the stakeholders was abandoned about seven volumes earlier, before we got the contract to implement.

The customer requires to see the detail in the user requirements expanded on in detailed use cases in a functional specification as well as traced to their original requirements.   Hence why we are using Enterprise Architect, in the hope of bringing the whole thing under control  in a consistent and traceable way.

Thanks
  b.b.

[qwerty]

You shouldn't misuse UC representation though. The idea behind UCs is to show the added value of a system, not it's functionality. Leaving out this most important abstraction layer and starting with functions will clearly blind anyone dealing with implementation of the system as well as business people trying to grasp especially the added value. All those pieces need to be kept under the hood in scenarios which shall only be revealed once you start looking into an UC. I often had these talks, but you need to persuade your customer.

q.

[Geert Bellekens]

I agree with Q on this one. Don't abuse use cases and use case scenario's to do your technical design, even if the client has provided you with so much detail.

Use cases a and their structured scenario's are a very powerful tool if you use them how they are intended to be used.
Use activity diagrams or sequence diagrams for the more complex behavior descriptions.

Geert