Alternative Flow Proliferation
Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
What they are
Flow Proliferation
Dos and Don'ts

Flow Proliferation

It is common to use alternative flows to describe all logical outcomes of a step in a use case.

example of alternative flow proliferation


Main flow – User authorised

4.    System retrieves Profile for the supplied Electronic Identity.

(Alternatives: User provides incorrect identity less than the maximum limit; User provides fails to log on exceeding suspicious threshold limit; Secondary profile; Cannot retrieve profile; User moves organisation)


Whilst this is semantically correct this can lead to a proliferation of one-line alternative flows. Also each of these flows are relatively simple, and all are saying the same thing that validation failed. Since the interaction is not different in such cases is better to wrap these up as one use case, and to describe the logic around this as a single or rationalised set of business rules. This way the dynamic nature of the use case is much more apparent, and therefore easier to review. 

rationalised example


Main flow – User authorised

4.    System retrieves and validates Profile for the supplied Electronic Identity. 

(Business RuleXYZ. Authentication Count Rules)

(Business RuleXYZ. Authentication Validation) 

5.    The system establishes the entry is correct. 

(Alternative: Failed Authentication)


As a guideline do not use alternative flows if both:


The interactions are identical


The same actor is involved

For example with a trade management use case involved in trade acceptance the first step should mention that an Actor – business portal – sends a message to the system. An alternative flow for manual, automated and contingency files are not necessary since for trade management’s purposes the interactions will be different (a different story in the case of business portal), and the actor is the same. However it would be acceptable in the triggers section of the use case to mention that this could be triggered in the case of manual, automated and contingency files.

Back Next

[1] Although in the case of security these goals can often be the mitigation of key, named risks.

© 2002-2005 Codel Services Ltd

This paper has been prepared by Codel Services Ltd to illustrate how structured business modelling can help your organisation. Codel Services Ltd is an IT Consultancy specialising in business modelling. If you would like further information, please contact us at: Deryck Brailsford, Codel Services Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom. Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: