How requirements use cases facilitate the SDLC

The use case helps the development team answer many of the predictable questions about an application's requirements; but it does so only if a well-conceived common approach is used from project to project. Fortunately, there's no need to reinvent the wheel when an organization needs to nail down use case best processes and practices. Here are some guiding principles, pros, cons and gotchas of some approaches, gleaned from my experiences.

Before jumping onboard the 'use case bandwagon' or staunchly opposing it, we should explore a bit, asking two questions:

 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:

Accomplish

• business goals
  
  Provide support for..
• user tasks
• system functions
• quality attributes
  
  Provide compliance with..
• policies...regulations

  Keeping these things in mind, what questions should be asked to facilitate the discovery of what is needed? What will the developers actually implement?
  
  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.
  

  Thus far, I have described the different types of requirement information that need to be elicited using only a few 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.

  Requirements types
  
  The requirement types we have looked at so far are listed in the chart 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.
  
  
  Requirement use case diagram: An example
  
  The use case diagram below identifies the users (represented by an actor) and user tasks (user requirements) needed for an order management system.
  

  
  

  A requirements 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.
  
  
  
  Taking this one step further, quality attributes non-functional requirements and policies and regulations business rules apply to some of these functional requirements as shown below.
  
  
  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.

  User acceptance test case examples	Functional Test Case Examples
  Create order for first time customer Create order for existing customer …	Create order using valid mailing information Create order using invalid mailing information …

  Requirements Use case considerations and cautions
  
  While the basic concepts around use cases are simple and powerful, here 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 of 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 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?

  Use cases
  
  No one technique is a panacea--the end all, be all, the 'silver bullet.  The use case technique is no exception So always consider: "Can this technique bring a simplicity and consistency to requirement definition and even elicitation? Does the lead to understanding what the software is expected to do?"  If the answer is "yes" or even "possibly", then the next step is to clear the way by:

  • ensuring a common understanding of requirement basics
  • facilitating a consistent use of this technique; and
  • defusing the emotional sidetracks

  Much of realizing the power of a technique is dependent on sticking with the basics and consistently insisting that the technique(s) chosen yield a definition of what the system needs to do.