I certainly agree that having automatic links to glossary items would be a good idea - probably even worth dumping in the suggestions list.
In terms of using Note and Scenario tabpages, we follow the same general ideas as expressed above. However, I will add the following to explain how we suggest they do it.
When the use case is initially "agreed" in our requirements review sessions, we tend only to give it a
name and the first guess at
complexity (under the theory that initial impressions are usually the best and if we dont do it initially it gets forgotten.) In addition, if there is strong evidence that different users have different names for the same thing we will create a list of Aliases.
If the team has been diligent in creating the external requirements we create a working diagram for the use case and link the associated requirements. This diagram is distributed for review at the next session (or if we are good little workers, after any breakouts in the current session).
The use case is then assigned to a particular analyst as the "owner" of the use case (using the Author field). That analyst writes the use case description (Note) along the following lines:
- what invokes the UC (or alternatively how does it start)
"The process customer payment use case is invoked whenever a new payment is received from a customer, either as a personal payment, a cheque through the mail, an electronic payment or when we are notified of a direct credit receipt in the daily bank statement."
- what is the outcome(s) of the use case with respect to the real world and the system persistence model.
"The use case raises a GL posting against the customer accountand either produces a letter of payment to the customer or, in the case of personal payments, a receipt.
- (if not implied by the outcomes) what indicates that the use case is ended
"The use case ends after the GL interface returns a validation of the posting"
- what other general information may be salient
Sometimes payments for multiple trades are received in the one payment - this means that the "Allocate Payment" use case may be invoked.
Sometimes only partial payment is received - this should not present a problem to processing the payment
You can see we get quite a lot of information summarised very quickly in this way. We also use the Maintenance items fairly repeatedly at this stage to note issues, ideas and proposed changes.
From the above example, you can see that the UC has some pretty apparent candidate scenarios based on the payment types to be handled. Further, there is an indication that an <<extends>> relationship might exist to the "allocate payments" use case.
The analyst will then
draft up their ideas on the scenarios. These are discussed at the next review.
In the main, I have found that about 85% or so of the draft scenarios are real, the remainder are duplicates and can be merged with others or are actually candidates for separate use cases. We try to keep the number of use cases as small as possible - keeping in mind my idea that they are a framework rather than a 3 volume requirement spec (or even worse a system design done by the requirements analysts). Further, the business users tend to focus on the detailed requirements rather than detailed use case annotations as it is, of course, blinding obvious to them how they do their job. They will spend some time reading the requirements to ensure that we haven't left something out that they "cant possibly live without", whereas they tend to pay less attention to the same details if they are hidden in the use case annotations.
We finish up the UC doc cycle by agreeing on the true set of scenarios - based on the idea that each scenario represents a unique usage of the system with diffferent aspects represented that must be satisified if the requirements are fully met.
