1

I have one use case "Transfer request" linked to two Actors (Analyst and Inspector). The scenario/exceptions/alternate flow are essentially the same, but for each actor the pre-conditions and post-conditions are different. The request has different states, and that final state and previous states differ depending on the actor that's calling the use case.

How can I resolve this issue efficiently?.

Kara
  • 6,115
  • 16
  • 50
  • 57
dantebarba
  • 1,396
  • 1
  • 12
  • 22

2 Answers2

4

It sounds to me like your use case might be too abstract to be useful.

Sure, at a very high level of abstraction the steps might look the same, but if you have a different set of pre/post conditions, different states etc.. then maybe you should be using different use cases.

It could be something like "Transfer payment request" and "Transfer inspection request"

If indeed there is a similarity in steps of the execution then you can still, at the locical level, create an Abstract class "Request" that takes care of the common parts. The subclasses PaymentRequest and InspectionRequest can then take care of the particulars of their own context.

Just remember that use cases are primarily meant to agree on the requirements with the business. So for the sake of clarity it is often better to avoid all too abstract use cases.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
  • 1
    +1 Your last sentence should be underlined several times. It can save all participants from confusion and trouble when use cases that are similar but not equal are named and specified separately. Then they are less likely to be mixed up later. – observer May 22 '15 at 09:34
  • 2
    If you have a lot of shared behaviors in a transfer request, you can always have Geert's two use cases inherit from a base use case. – BobRodes May 25 '15 at 20:34
0

You simply formulate those conditions as constraints in the pre-/postcondition. (It's simple like that.)

qwerty_so
  • 35,448
  • 8
  • 62
  • 86