Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Bob Burdett

Pages: [1]
1
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.

2
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.

Pages: [1]