The interview was going well. The interviewer was a project manager / architect. “We have identified these use cases for the project. Now what do we do?” he asked. The question was not one of methodology. He knew the basics of how to write a use case specification and how to draw use case diagrams.

When I probed deeper, I found that he was really asking me, “How do I approach this as a project manager? Serially? All at once, in parallel? What is my next step?” He did not know how to plan when using use cases.

[login]There is nothing magical about use cases. Use cases are merely another way to organize a group of functional requirements for a system. Organizing groups of functional requirements is not new in software development. In more “traditional” requirements elicitation and analysis approaches, functional decomposition was used to decompose functional requirements into smaller cohesive component functions (to be later recomposed into the larger functionality). Instead of a typical hierarchical decomposition, use cases organize requirements around the various flows of the use case.

Understanding this allows us to plan use case development similarly to any other software development. However, use cases enable us to better assess the value of the use case’s functionality to the business. A business stakeholder typically would find it difficult to assess how valuable a functionally decomposed function or sub-function is to the overall business. However, because use cases are scenario driven by a specific actor, the business stakeholders can more easily relate the use case to the actual business activity being performed. This allows us to more easily establish a value-based development plan.

Here is a very basic approach to planning your use case development (it is a simplified technique based on the Quality Function Deployment approach to product development). First, identify your candidate use cases. Next (or as you identify your candidates) create the basic short description (2 or 3 sentences for example) for each use case. You now have enough information to do a very coarse prioritization of the use cases.

Examining these use cases, based on value, what is the priority of each use case according to your business stakeholders? (If your stakeholders cannot prioritize the use cases that may be an indicator that your short descriptions may not be clear as to what value they provide. What is that use case trying to achieve? What is its objective? Or maybe you are asking the wrong stakeholders?)

Have your stakeholders rank the importance of the use cases on whatever scale you and they are comfortable with. For this discussion let us use a 1-10 scale, where 1 means least important and 10 most important. You now have your use cases prioritized based on importance/value to the customer. Note that this discussion may provide clarifications of what the stakeholder really want from the use cases, which in turn may change the existing description. This is a good thing. Better to find out now than to find out as acceptance testing begins.While this is a simple approach, you are not quite done. If you believe software development is a profession, you can’t just take the stakeholders’ input as the way things will be. If you do, you have become an “order taker” instead of a professional offering thoughtful technical input to your stakeholders. You and your team need to assess these use cases and determine your ability to actually deliver the use case functionality. It’s your turn to prioritize. This time you prioritize by how difficult/risky the implementation of these use cases will be. Use the same scale as your stakeholders did regarding value/importance. In this discussion, 1 means very easy / no risk and 10 would be very difficult / very risky.

How do you resolve these two viewpoints? You now have two characteristics that you can plot against each other. Create a diagram where the y axis is the stakeholders’ importance ranking and the x axis is your technical difficulty ranking. Then “plot” the individual use cases on this grid. See Figure 1.

Figure 1: Use Case Plot.

Next partition the plot into four quadrants. Moving counter-clockwise, the upper right quadrant contains the high risk use cases (high importance and high difficulty). The upper left quadrant contains the high importance, less difficult use cases. The lower left contains use cases that are not that important and are less difficult. The lower right use cases are not important, but are high difficulty. See Figure 2.

Figure 2: Prioritized Use Case Plot.

This plot can give you the coarse plan for your use cases. Again moving counter-clockwise, the upper right, high risk use cases should be done first. Being high risk you need to mitigate the risk these use cases have before completing other work. If these can’t be done, your entire project may need to be canceled or redefined. The upper left (Do It) are the mainstay of your development. They are important and less difficult. Do these next. The lower left (Maybe) quadrant contains those use cases that you may want to do if you have additional time or resources (chuckle, chuckle) because they are easier and not that important. The last quadrant, lower right are the use cases you may want to descope. Why would you want to develop functionality that is very difficult to create and the stakeholders don’t really want?

Now you have the basic sequence of how to proceed through your use cases. They will mature at varying rates during the development lifecycle. See Figure 3.

Figure 3: Use Case Progression.

Caveats. Realize that this simple method is not to indicate that you should be approaching your development in a serial, waterfall manner. This technique can be used for incremental or iterative or agile development approaches. It merely gives you a way to easily prioritize your use cases (or functional blocks, user stories, or whatever units of work you are using). Also, you should consider adjusting your prioritization based on any interdependencies that may exist between your use cases. (Hopefully there are not many. If there are, that may indicate a problem with your use case definitions.)

The UML is not just a great tool for requirements elicitation, analysis, and design, it also can help the project manager to effectively plan and direct the development cycle.