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.

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

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

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

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.

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.

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

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

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

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.

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

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