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.
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.