Enter another use case a precursor to another one

[tobester]

Hi

I am writing a specification for some internal processes that involve two teams.

I have about 30 use cases at the moment. I do intend to reduce this number in due course.

At the moment, I want to mark that one use case must be completed before another.

At present, I am addding pre-condition constraints using the constraints tab.

Is there a better way of doing this please?

Toby

[Gary W.]

Is there a better way of doing this please?

What is the text of your pre-condition?  Is it some sort of system state that is achieved upon completion of the first use case?

If you're saying 'Use Case X must be done', then I don't quite agree, but if you're saying something like "The registration has been confirmed and accepted into the system", then I've used preconditions like this in the past.

gary

BTW, is it *always* the case that the first use case has been completed before the second one starts?

[tobester]

The pre-condition is "Use case x has been done and result y has been achieved".

At present, each use case is a specific action and there will be two results: use case completed, use case failed (normally because of a system failure). In short, I am ignoring the processes that are happening before the use case.

Toby

[sargasso]

Let's see.

UC001: Finangle the doohickey
Allows the user to modifulate a selected doohickey.
BASE CASE=Selected doohickey moved to state finangled.
ALT CASE=(Selected doohickey is unfinangable) Selected doohickey remains unfinangled.


UC002: Prepare foogit.
Allows the user to consolidate finangled doohickeys onto a new froogit.
BASE CASE=Froogit released to bunghangle.
ALT CASE=(One or more component doohickeys of the proposed froogit have not been finangled) (Depending on the requirement) (a) No froogit created. (b)Froogit created as "draft froogit"? (c) User is fried by sending 60KV through keyboard.



Now, Fred (the user) may attempt to invoke UC002 at any time.  There is not guarantee at the commencement of execution of UC002 the the desired doohickeys have been finangled. IOW it is not a pre-condition of the use case invocation. So there is no constraint on UC002 on the completion of UC001 until UC002 is in progress an meets a blocking condition.
As soon as that (in-process condition) is met the system must provide an adequate indication.

This may be a bit more complex (and obfurscated) example than the OP was thinking of. However, I have seen over and over, examples of "UC002 cannot be invoked unless UC001 has completed" and yet when we start testing these things this is ONE OF THE FIRST TYPE OF DESIGN ERRORS WE LOOK FOR.

(The developers usually try to explain it away using the age old "but no-one would ever do that".)

hth
bruce


p.s. Putting it another way.
UC001: Do Shopping
UC002: Cook breakfast
There is no sequential relationship between the use cases. None, zero, zip.
If the model says there is, then the model is wrong.

[Gary W.]

The pre-condition is "Use case x has been done and result y has been achieved".

Sounds like you're using use cases to do functional decomposition and/or CRUD-type operations.

Without getting into a huge methodology debate over this, let me just say that each use case should, by itself, provide some tangible benefit or result to the primary stakeholder (as per use case experts such as Cockburn, Bitten, etc.).

If, in your requirements, it requires a string of successive use case "completions" to deliver such a tangible result (to the primary stakeholder), then you're probably not following this.    

Also, the pre-conditions should be stated in a way that the system can actually detect these conditions.   If it requires some sort of human thought process to determine it, then it'll be impossible for developers to implement the pre-condition checks into your system.

Gary

[tobester]

Hi Gary

That is probably correct. I am analysing an existing process with an eye to producing use cases for a new process.

My idea was to start with a use case for each interaction. The interaction will have "technical" outcomes, for example "Enter deadline date into system". Later on, I will merge these use cases into true use cases.

Toby

[Gary W.]

I am analysing an existing process...

In that case, why don't you use EA's Business Process Modeling functionality?  Check it out at:
http://www.sparxsystems.com.au/platforms/business_process_modeling.html

Later on, I will merge these use cases into true use cases.

Since you'll be re-working these requirements into "true" use cases anyways, it's not like you're creating extra work for yourself by using BPMN.   But you will have the necessary notation to document the activities, inputs, outputs, and goals... without having the contort the Use Case notation to fit your process modeling.

HTH
gary