Hi Kimbo,

I use similar template, except that I don't list the business rules but reference them by number, as the realised requirements.Often the same business rule(s) apply to multiple use cases, and I don't think it is a good practice to state any requirement or a rule more than once in the document. If your projects are different your approach may work just fine.

I have noticed also that as my understanding of the use case grows and I discover more details about them, the content of the "Notes" section becomes an alternative flow or begins to apply to a specific requirement or business rule that is realised by the use case, so I move these notes to a better location and again reference them by number.

-Vessela

I agree with Vessela, it is a good idea to keep business rules in a separate repository and reference them from the use cases.  In some cases, this practice can reduce readability but it makes up when it comes to maintainability.

Here are a couple more thoughts/practices that I have found useful when it comes to Use Cases:

• In the Use Case specification document, I like to include at the beginning of the document a use case context diagram which is a subset of the larger use case model but which only includes the use case being described and all the other actors and use cases with which the use case in context is related.
• In addition to the Basic (main) Flow and Alternate Flows, I also like to identify Exception Flows which contain those branches in activity/process which the actor (user) does not expect/desire.
• Also, every use case document I create has an Issues section and an Assumptions section. This is helpful in a larger team when I read a use case created by another analyst and I see if there are any issues or if the issues section is blank.  Now I only use this section for issues which relate directly to the given use case.  This is not the place to manage project or program level issues.  Many of the resolved issues become assumptions, in which case I add those to the Assumptions section.
• For large projects, where a robust set of artifacts are needed, my use case "family" of artifacts generally includes the following:
  • Actor Overview -> a document which contains a diagram of just actors and the appropriate generalization relationships among them.  This document also contains a description of each actor and their mapping to actual job titles within the given organization.  Remember that an actor represents a "role" not a job title and, therefore, many job titles will most likely map to one role/actor.
  • Use Case Model -> this is the set of UML use case diagrams (separated by packages if needed) which usually lives within a modeling tool such as Enterprise Architect, Visio, etc.
  • Use Case Model Survey -> this is a document which contains the "key" aka main aka high-level use cases of the system and it has two parts: use case diagram(s) and use case description(s).  I found this artifact to be very useful for high-level stakeholders such as executive management who don't care to get into the details.
  • Use Case Specification -> I have one of these for each use case and this is where I document the use case in details: use case name, description, pre-conditions, post-conditions, main flow, etc..
  • NOTE: it is very useful to have a tool, such as Requisite Pro, to manage all the use cases.  This way the actual documents simply become reports generated from the tool.
• And since it is generally accepted that use case are to be used for functional requirements and NOT for non-functional requirements, my set of use case artifacts is complemented by a document which lists the non-functional requirements; some folks like to call this the Supplemental Requirements document.

Thoughts?

- Adrian