Should Multiple Actors share the same Goals in Actor-Goal list

Question

Craig Larman states that creating an Actor[/User]-Goal list in form of some table/grid is a good technique for finding Use Cases during Requirements Analysis. (Applying UML and Patterns - P. 69 ff)

Some simple two-column table should be enough to provide a good Overview for this example; imagine following Actor-Goal List:

Actor Goal

Admin Create User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..

User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..

Admin can do what User can + more like managing the Users of the System under Development or assigning Entries to them.

Admin and User clearly are sharing some Goals(Can we use the term Use Case yet?).

Im not really sure where to go from here in terms of refining this Actor-Goal list.

My brain tells me that i can spare time and effort by reusing/abstraction here, so I will most likely end up with one common superclass implementing the CRUD Entry behaviour, where Admin is extending the functionality by the Manage Goals(CRUD User, assign, etc.).

But I know that this is rather a question of Design than Analysis.
I also know that I can write the Use Case for this in isolation: I dont have to state who exactly uses it, I just need to know that it's some entity which is adhering to the given contract[/interface].

When is the time to start thinking about abstraction?
Am I overcomplicating things by doing so right now?
Should We leave the Actor-Goal list like above and check it off as a "complete" Artifact?

Since the classical purpose of an Actor-Goal list is to provide some quick overview for our next Artifact - the Use Case Diagram - could we begin the transition right here?:

The Use Case Diagram makes the whole reusing part much more visible (at least to me). Would it be advisable to adopt the redundancy right now and take care of it during later stages (e.g. design)?

Appreciate your input!

EDIT: Also I'm not quite sure about the User CRUDing himself.. But lets keep things simple and stick to the main question.

Answer 1

It's an excellent idea to identify the candidate use cases in an actor-goal list, as you have described.

The issues when identifying use cases

In the real life, you'll quickly encounter consistency issues when elaborating the list during requirement elicitation :

• some interviewed users/business experts will describe very detailed step by step goals (corresponding to system functions), whereas other will describe rather high level goals user goals. So you'll need a third column to identify the goal level of each use case.

• terminology and user goals will not always be expressed in an homogeneous way. So cross checking, and renaming of use cases might be required. For example, I had a system where:

  • an admin claimed to manage authorizations, and a business user claimed to manage authorization. Was it the same use case ? No: it appeared that the first maintained assignment of authorizations in the system and the second was empowered to decide on authorizations assignment and request them from the admin.
  • a purchaser explained that for a purchase order someone has to register a good receipt before the invoice is paid. The warehouse clerk explained that at warehouse they manage stock movement. Latter, though, it appeared, that those movements where good receipts, good issues, and stock transfers.

So a fourth column for comments about main variants could help to keep the overview, and to spot hidden sharing potential.

There is generally a great deal of cross checking and harmonization to be done before sharing/reusing use cases. Reusing too quickly might end up loosing more time than expected.

The use case diagramming

I will now be very provocative: once you have the nice and consistent table with all the actors and use cases, what will be the benefit that you expect from a use case diagram ?

It is generally recommended not to abuse use case diagrams for functional decomposition (see also here). So the use case diagram will add little more to what you already have in the list.

In addition, <<Include>> , <<Extend>> and generalization relations should be used scarcely because they tend to quickly make the diagram difficult to understand.

Finally, does abstraction and reuse really happen at the level of the use case ? Is this relevant to the actors outside of the system ? If not, it's more about design and implementation details. So I'd suggest to consider these more in the class model that you will create (or derive) to implement the use cases.