How use cases facilitate the SDLC

So, why develop use cases? How does this technique facilitate the system development process? Unfortunately, many who write use cases have never really asked, much less answered, these questions. If they had, the emotional discussions that surround this topic would largely dissipate. I suspect the common but unspoken answers to the first question, "Why do you develop use cases?" might be "because everyone else is using this technique" or "because I am expected to provide use cases." It is actually the answer to the second question of, "How does this technique facilitate the system development process?" that will give us a clue as to why use cases are such a valuable technique.

First, any system that is built or bought has certain things it needs to accomplish, provide support for or compliance with, namely:

Keeping these things in mind, what questions should be asked to facilitate the discovery of what is needed? What will the developers actually implement? (Click on the image for a larger view.)

Any technique that describes what the system has to do in the context of a user task needed to achieve a business goal not only ensures that only required functionality is built, but also enables quality attributes, policies and regulations to be applied in this context as well. The use case diagram and use case are just such techniques. (Click on the image for a larger view.)

Thus far, I have described the different types of requirement information that need to be elicited using only some key words. Hopefully, this has facilitated an understanding of exactly why you need to go after certain kinds of information. Your approach needs to make sense in the most logical way, for it is not technical but is all about understanding what information is essential to building the right product. The requirement types we have looked at so far are below. We will need them as we look at the use case diagram and use case techniques that help discover some of this critical information. (Click on the image for a larger view.)

Use case diagram example
The use case diagram below identifies the users (represented by an actor) and user tasks (user requirements) needed for an order management system.

Use case example
Now, let's explore the first user task -- "create order" -- in the diagram above using the use case technique. By asking a few simple questions (embodied in the use case template), we discover the functional requirements for this user requirement. (Click the image for a larger view.)

Taking this one step further, quality attributes (nonfunctional requirements) and policies/regulations Business rules apply to some of these functional requirements as shown below. (Click the image for a larger view.)

As illustrated below, it is not much of a stretch to see that test cases can be derived from the information in a use case, thus adding one more benefit for leveraging the use case technique.

Use case considerations and cautions
While the basic concepts around use cases are simple and powerful, there are some additional considerations and a few cautions.

Develop iteratively	You will not know all the details of a user task on the first pass. Expect to elaborate further to: Discover additional steps, rules, qualities or alternate paths. Document all the data that is needed for a particular step.
Know when to repackage	As we have seen, each use case is a set of steps. Often when you revisit a user task you discover all sorts of things that intentionally were not dealt with or not known at the time. The result can be a lot of additional steps -- so many that you may feel that the entire system will be captured in this one use case. This is a warning sign that you need to "repackage" the steps either in another user task or as an alternate path. (More than 10 steps in a use case warrants asking the question "Is this more than one user task?") Here is the secret! The pre/post-conditions act as "bookends" because they define what has to be true at the beginning and the end of the user task. If you need to repackage the steps, note that the pre/post-conditions will not only help with this process, but they will also associate one user task (use case) to another. In my experience, there is a lot of emotional talk around, "Is this one use case, two use cases, three use cases OR is it one use case with two alternate flows OR…?" Wow, give that discussion about 10 minutes and then make a decision. If you have to "repackage" the steps later, so be it -- it is only a regrouping!
Focus on WHAT not HOW	Don't constrain design by using what I call "banned" words that indicate a particular design. Some "banned" words are: click, dropdown, and button, among others. Some "useful" words that convey the same idea without constraining the design are: select, provide, request and so on. When you talk with customers, they will often describe their needs in a system context which has HOW all through it. A great way to acknowledge what they have said is to restate as a WHAT and note their "design idea." Know that once you have described the WHAT, you are done!
Recognize the emotion, but know the power	Because this technique is being widely used, there are a lot opinions and sometimes a lot of emotion. We have already highlighted the all-too-frequent discussion around "One use case, two cases…?" There are others based on how a person has developed use cases in the past, what a UML book said to do, what worked or didn't work in a particular situation and so forth. In these discussions, go to the power -- the simple power that that this technique brings. Simply stated, the power is: A use case is a user task which is necessary to accomplish something important to the business (business goal). By asking the straightforward question, "What are the steps?" the functional requirements "fall out." Test cases can be easily derived from a well-defined user task (use case). There you go! You may have to restate the power a number of times before those who have never asked the questions we started with can finally answer: Why develop use cases? How does this technique facilitate the system development process?