A use case is a prose essay. Nicht die Diagramme sind wichtig, sondern die Prosa.

Make the use case easy to read. You want your requirements document short, clear, and easy to read. Lasse die Intention des Aktors deutlich werden. Vermeide nach Möglichkeit ausgegliederte Extension Use Cases.

Just one sentence form. Die Einzelschritte eines Use Cases werden in nur einer Art beschrieben: mit einem Satz in Präsens, einem aktivem Verb, mit einem Subjekt, das erfolgreich ein Ziel verfolgt. Bsp: "Kunde schiebt Karte ein und gibt die PIN ein."
Im unteren Teil des Use Cases, in dem Extensions beschrieben werden, ändert sich der Stil. Eine Bedingung wird vorangestellt, z.B. "Falsche PIN eingegeben:..."

"Include" sub use cases. In UML-Terminologie ausgedrückt: verwende die include-relationship, sie ist eine natürliche Sache. Vermeide die extends- und specializes-relationship, sie trägt nur zur allgemeinen Verwirrung bei.

Who has the ball. Benenne den Aktiven eines Use Case Schrittes (Aktor oder System, das auch eine Art Aktor ist).

Get the Goal Level Right. Auf welcher Ebene bewegt sich der Use Case? Wird ein ganzer Geschäftsprozess dargestellt? oder ein einzelner, abgeschlossener Arbeitsschritt mehrere Ebenen darunter? Beides ist erlaubt, sofern dadurch Klarheit geschaffen wird. Entscheidend ist aber die Ebene des einzelnen Akteurs: was will dieser in einer Arbeitssitzung erreichen (deswegen spricht Cockburn auch immer von einem "goal level"). Entspricht in der Geschäftsprozessmodellierung der ElementarFunktion. Der Test für den user level:
- it is done by one person, in one place, at one time(2 to 20 min.)
- the actor can go away happily as sooon as it is completed
- the actor (if an employee) can ask for a raise after doing many of these (ist das nun typisch amerikanisch oder typisch gewerkschaftlich?)
Beispiele: "Log in" ist zu detailliert, "buy a book" ist OK, "online auction" ist high level, weil sie über mehrere Tage geht. "Schadensmeldung eingeben" in einer Versicherung ist user level.
Es ist durchaus sinnvoll, use cases auf allen diesen Ebenen zu schreiben.

Keep the GUI out. Capture the real intent of the actor.

Every use case has two possible endings, success and failure. Das trifft auch auf die include use cases zu.

Stakeholders need guarantees. Das System soll die Interessen aller beteiligten Stakeholder gewährleisten, und zwar nicht nur bei success.

Preconditions werden als wahr vorausgesetzt und im use case nicht nochmals überprüft. Bsp: Benutzer ist eingeloggt. Preconditions werden in einem vorausgegangen use case hergestellt.

Pass/Fail tests for one use case Tabelle auf S.213

It's just chapter three.
Use cases are only a small part of the total requirements-gathering effort, perhaps "Chapter 3" of the requirements document. Sie sind zwar zentral und verbinden Datendefinitionen, User Interface, etc. Aber nichtsdestotrotz sind sie nur ein Teil der Requirements: nämlich der funktionale.
Eine Verlinkung der use cases mit Datenbeschreibungen wie "Adresse" ist sinnvoll (S.162)
Im use case selbst wird ein Nickname benutzt, z.B. "Adresse", deren Bestandteile müssen in einem weiteren Präzisierungsschritt beschrieben werden, am besten nicht im use case-Format.