If you did step two, this step will be much easier to do
well. Having an organized use case suite makes it easier to name
use cases because the task is broken down into much smaller subtasks,
each of which is more specific and concrete.
Put your finger, or cursor, on each list item or grid cell in
your use case suite. Then, for each one, ask yourself about the
relevant goals of users. Most of the time, you will think of two
to five use cases fairly easily. Sometimes, there will be a list
item or grid cell that really should be empty. For example, the
administrator of an e-commerce site might not have any use cases
for editing product descriptions, if that is done by a "store
manager" class of users instead. In that situation, write "N/A" for
"Not Applicable". Other times, you might know that there should
be some use cases listed, but you cannot think of them at the
moment. In that situation, write "TODO" as a reminder to come
back to it later.
The name of each use case should be an active verb phrase
describing a goal. For example: "Select product for purchase".
The name should be written in terms that a user might use
themselves. So, "Put product in shopping cart" is also fine.
Use case names should not be written in implementation terms:
"Insert SKU into checkout phase one hash-table" is definitely
wrong. Keep in mind that one of the goals of writing use cases
is to allow potential customers and users to read and validate
It is important to keep in mind that use cases focus on users'
goals. For example, a banking ATM user's goal might be to "Get
cash quickly." It is never the user's goal to
"Choose preferred language", that is simply a step imposed
by the system on the user who is trying to get cash quickly.
As you work through this step, you may also think of a feature
that should be specified in the feature set. If that happens,
just take a moment to note down the name of the feature.
Before moving on to the next step, it is worth pointing out
that the result of this step is itself very valuable. Having a
fairly complete suite of use case names, by itself, is major
progress on the system specification. It already is enough for
you to start doing some things that can help your overall project
succeed. At this point, you can already get a better feeling for
the scope of the release. You can already roughly prioritize use
cases. You are already validating your definition of the classes
of users. And, you can already recognize some needed features
that might have been overlooked if you had jumped down into
detailed steps too soon.
Step Four: Write Some Use Case Descriptions
In step three, you may have generated ten to fifty use case
names on your first pass. That number will grow as you continue
to formalize the software requirements specification. That level
completeness of the specification is very desirable because it
gives more guidance in design and implementation planning, it can
lead to more realistic schedules and release scoping decisions,
and it can reduce requirements changes later.
The downside to mapping out the big picture is simply that it
is too big. It could take a long time to fully specify every use
case that you have mapped out. And, the resulting document could
become too large, making it harder to validate and maintain.
The solution is to be selective before moving to the next
level of detail. For example, if there are clearly too many use
cases for one release, reschedule some of them for later
releases. Also, it's a good idea to just write descriptions
rather than get into detailed steps for each use case. Going
deep into the details of just a few use cases is enough to shake
out uncertainties and identify areas for improvement. The bulk
of the use cases can be done later, it needed at all.
Write one to three sentence descriptions of each use case that
you plan to implement in this release. The description should
provide a little more information on the user's goal and briefly
outline the strategy that the user will follow. Sometimes there
will be two or more ways to accomplish the same goal. If there
are significant differences in strategy, it is a good idea to
split the use case into two distinct use cases.
Step Five: Write Steps for Selected Use Cases
Now it is time for the main event: actually writing the use
case steps. This is a task that you can expect to take ten to
forty-five minutes for each use case. That might average out to
only about ten use cases in a typical work day. Again, you must
be selective to get the most value in return for your limited
Focus on use cases that seem most likely to affect the success
of the project. For example, select use cases that:
Enable users to achieve the key benefits claimed for your product
Determine a user's first impression of the product
Challenge the user's knowledge or abilities
Affect workflows that involve multiple users
Explain the usage of novel or difficult-to-use features
Each use case should show a straightforward example of the
user succeeding at a goal. The steps in a use case are almost
always a linear sequence. You should not use programming
constructs such as if-statements or loops, if at all possible.
Rather than use conditional statements, use an extension point to
describe any type of failure or error condition.
Each use case step has two parts: a user intention and system
The user intention is a phrase describing what the user
intends to do in that step. Typical steps involve accessing
information, providing input, or initiating commands. Usually
the user intent clearly implies a UI action. For example, if I
intend to save a file, then I could probably press Control-S.
However, "press Control-S" is not written in use cases.
In general, you should try not to mention specific UI details:
they are too low-level and may change later.
The system response is a phrase describing the user-visible
part of the system's reaction to the user's action. As above,
it is best not to mention specific details that may change
later. For example, the system's response to the user saving a
file might be "Report filename that was saved". The system
response should not describe an internal action. For example,
it may be true that the system will "Update database record",
but unless that is something that the user can immediately see,
it is not relevant to the use case.
Use case steps can be written in either two-column or
one-column format. The two-column format forces every step to
include an explicit user intention and system response. The
one-column format gives you more flexibility to skip system
responses that are obvious, and to handle multiple actors
interacting with the system in one use case.
Recall that one of the advantages of writing use cases is that
it forces you to clearly think through the details of the system.
Capture your insights by writing notes and questions as you go.
If a use case step reminds you of a specific requirement in a
system feature, make a note of it in the corresponding feature