Dos and Don'ts
Home Business Change Analysis & Design Agile Testing Templates About us

Problem Statement
Introduction
What they are
Granularity
Coupling
Flow Proliferation
Description
Dos and Don'ts
Example

 Dos and Don'ts

Policing semantics requires careful consideration and balance; since use cases are chiefly a “word” deliverable, inevitably every author will adopt a slightly different style. It will therefore be pragmatic to let some borderline cases through. However the following standards identify what is expected from a use case.

bullet

Do keep any design and developer notes to a minimum and place these in the appendix, referenced by footnotes in the text. The flow should in no way be dependent on the contents of design and developer notes.

bullet

Do use actors to describe cross-component interaction rather than extends and includes.

bullet

Do avoid use of includes and extends where it can be avoided, as this can reduce cohesion and therefore reuse.

bullet

Do use pre-conditions and post-conditions, rather than includes/extends, to describe interaction with the infrastructure.

bullet

Do be pragmatic. For existing use case, strike a balance between effort and benefit to correct, i.e. avoid rationalising use cases that are closer to an archetypal “perfect use case” guidance example (see appendix) than the bad.

bullet

Do ensure “Actor” and “System” are always referred as such. Where there are multiple actors then the component can be parenthesised. No such refinement in the System is allowed, as this infers design.

bullet

Do not include or extend into a part of a use case i.e. into an alternative flow or a specific step.

bullet

Do not reference design domain artefacts, design should reference analysis.

bullet

Do not use alternative flows to describe rules, cross reference rules

bullet

Do show where there are multiple actors then the component can be parenthesised. No such refinement in the System is allowed, as this infers design.

bullet

Do not accept flows that can be interpreted as how the system is behaving..

bullet

Do not use technical terminology and jargon, unless they form part of the business domain.

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: info@codel-services.com