Before developing a use case determine the systemís responsibility. Sometimes, itís even more important to determine what is not the systemís responsibility. Refer to your context diagram as guide for this activity.
Make sure you do not describe activities outside the systemís scope. If you do include outside activities it will make the use cases larger and too confusing for the analysts to comprehend.
A use case description must include how and when the use case begins and ends. Also, consider the possibility of any looping behavior within the use case.
When writing the use case utilize a limited vocabulary and avoid using adverbs (e.g., very, more, rather). The use case should be detailed enough to give an adequate description of the system.
As you create the use case make use of the data dictionary. Define new terms and clarify existing ones as needed. Avoid the urge for creative writing. For example, if you are referring to a customer throughout your use case do not start using person or client because you are bored using customer. Objects are going to be mined from the use cases. If you introduce two new terms for customer the analyst may think there are really three objects (customer, person, client) instead of one object (customer). However, you may discover there is a difference between customer and client and how they are treated within the system. In this situation, use both terms and document the differences between the two.
Be specific when defining the activities of an actor. Use phrases like: ďThe actor will create, store, change, remove, initialize, or read data in the system.Ē Think of the primary tasks that the actor wants the system to perform.
Verify the flow of events is performed in the correct order and complete. It is sometimes helpful to make a list of questions to pose to the business expert at the next requirements meeting.
The use case should describe in detail the stimulus to and from the actor. Always express the flow of events in terms of the actor and what is exchanged with the actor. Do not mention actors, or people, that do not communicate with the use case currently being described.
The use case should not include technology considerations. There exists a common misconception that a use case is solely created for user interface specification. A use case should not contain any user interface dependent information (e.g., radio button, check box, drop-down menu). However, the interface design specialists will eventually use the use case to help develop the user interface.
It is often easier to start writing the use case in its entirety in the beginning and split it up later if necessary. You could simply divide the flow of events into several subevent phases using words like: ďThe use case contains several options from which it may proceed.Ē If the subevent occupies a large segment for a use caseís given flow of events, then split it out into a separate sub-use case. However, only create sub-use cases if this flow of events is being used in multiple use cases. A sub-use case exists to decrease redundancy across many use cases that share the same flow of events.
A use case should know what use cases itís referencing, but it shouldnít be aware of how itís being used. You should avoid mentioning use cases that have no relation since that would create unnecessary dependencies.
Knowing when to stop writing the use case description is a concern many analysts will encounter. Each use case has been created to provide a service or set of services for the actor. When the use case has provided a meaningful result for the actor then it is time to stop developing the use case. How do I know when Iíve provided a meaningful result for the actor? The use caseís abstract should contain a brief description of the use case and that description should include the goal of the use case. When the use case has achieved that goal it is time to stop writing.