Still sick. Still bored. Time to talk about some more BA topics.
Use Cases and (the appallingly badly translated) Actors  are a powerful tool for documenting system requirements, as well as for aligning the requirements to BMM goals and objectives. Put bluntly: if the use case does not help to achieve a quantifiable objective, then the business analyst needs to challenge the existence of the use case.
However much of this power comes from the relative ease of communicating behavioural requirements with use cases. A tightly written use case tells a clear, succinct, easy to read
However a use case should not contain the complete requirement set.
Attempting to do so will horribly clutter it with extraneous information, and I've seen examples  where this completely obscures the core behaviour and the core goal of the use case.
In no particular order I believe that the following, at minimum , should be excluded from a use case:
1. User Interface :
a. A Find Something use case should have the same basic steps regardless of what the UI looks like .
i. The Actor provides search criteria
ii. The System searches for matching records
iii. The System returns a list of matching records
iv. The Actor selects the desired record
b. This prevents the use case impacting design – a reference to “clicking on search” for instance carries with it a host of undesirable assumptions.
c. It allows for multiple user interfaces to meet the use case. 
d. This does require separate UI documentation. 
2. Separate alternates for every business rule violation:
a. Alternate flows should identify key variations in behaviour.
b. It is often the case in search behaviour that:
i. Values are required for some search criteria; and
ii. Some search criteria have restricted values
c. Violating either, or both, of these rules should trigger the same alternate to step ii above:
i. The System advises the Actor of errors in the search criteria
ii. The Actor corrects the search criteria (rejoins basic flow at step ii)
d. Using separate alternates creates the horribly frustrating user experience of “correct one error, get told of another”.
3. A detailed list of business rules:
a. Remember that a good use case tells a story. In the example above there is already a block of text separating the basic flow from the first alternate flow.
b. This disrupts the flow of the story.
c. Now imagine putting in all the search criteria rules (what’s mandatory, what’s optional, data types etc, etc) between the first alternate and the next.
d. Then try to read the resulting use case. I guarantee that it will be almost impossible to trace the flow of the story and the alternates.
e. A secondary issue is that several of these rules will be shared between use cases, and repeating them will complicate maintenance of the requirement set. 
4. Non-functional requirements:
a. A use case is about doing something useful.
b. Non-functional requirements are about the environment in which the useful things get done. This has two key implications:
i. They are likely to be the same for all use cases .
ii. They may not help achieve the goal, and in some cases may prevent the actor achieving the goal .
5. Static or structural requirements
a. By which I refer to things like class models or entity relationship diagrams, etc, etc.
b. I do recommend referencing the static requirements, but they should be documented elsewhere.:
i. The Actor amends the Client Name
c. Client Name is then a class that should be documented elsewhere.
d. There is one hybrid dynamic-static concept that I tend to group here: state charts for objects with complex life cycles. This is usually because the life cycle crosses multiple use cases.
All of the above need to be documented outside of the use case set. I’m not going to talk in this post about how, or where, they should be documented. Nor am I going to talk about maintaining the conceptual links / traceability between the various requirements artefacts beyond noting that a requirements modelling tool can be useful for this. 
I think that’s enough for now.
 IIRC Fowler’s UML Distilled (recommended as a practitioner’s guide to the UML) contains a throwaway line that it should have been Role due to a mistranslation from the Swedish where use cases emerged in mobile telephone software development.
 And when I got started with use case I wrote some myself. I’m better now. What follows is the benefit of my experience with a healthy dose of Cockburn’s Writing Effective Use Cases (recommended).
 Remember: currently sick and bored so this is off the top of my head.
 This can be incredibly hard to do by the way. It is all too easy to accidentally use wording that implies some aspect of the user interface.
 Assuming that there is a UI. For example a web service that exchanges messages between a 3rd party UI and the system under discussion is one way to implement a user case without a UI at all.
 Accessibility for starters. Including “clicking on search” in a flow implies both that the system will use a mouse, and that all system users will be able to use a mouse. My first major project as a BA had a user for which this wasn’t true.
 For example, web services, a web site, smartphone applications should all be capable of delivering the same use case.
 In theory this supports retention of the UI-independent use cases when an aging system is replaced. The key assumptions here are that the business goals will not have changed, and that the core behaviour has also not changed.
 It is my opinion that re-use is something that Bas should also strive for: Write Once, Use Many is a good goal.
 And there’s that re-use concept again. WOUM.
 Security is the classic example. That systems need to be secured from unauthorised use is a given, but the requirements imposed (passwords, user Ids, logon procedures, etc, etc) make it harder for actors to achieve useful goals, and this is why I generally resist the inclusion of a Logon use case.
 I will however note that my key requirements for such are:
a) Support for both graphical and textual requirements; and
b) Easy publication to business users: these tools tend to be expensive, and clients generally (and reasonably) expect to be handed a website and/or word documents when the time to review and/or sign off comes.