| ReadySET Pro for example test plan templates Enterprise-Ready Software Engineering Templates |
|---|
Use Case Tutorial
Step Three: List Use Case NamesIf 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 them. 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 DescriptionsIn 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 CasesNow 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 available time. Focus on use cases that seem most likely to affect the success of the project. For example, select use cases that:
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 response:
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 specification. |
||||
| Copyright © 2010 Method Labs. All rights reserved. Privacy. | ||||
