In the previous article in this series, UML for Project Managers, I discussed how the UML (Unified Modeling Language)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.
As part of that article I mentioned how use cases “will mature at varying rates during the development lifecycle.” Let’s expand on the idea of use case maturity. Just as children mature over time, so do use cases. This is not referring to the nominal 9 months children mature before birth. That period is always necessary, just as there is a minimal amount of information needed to describe use cases (see first 3 stages in Figure 1). What I am referring as “maturity” is the level of detailed elaboration of the use cases, beyond the minimum needed.
[login]
Figure 1: Allow use cases to mature as appropriate.
Many teams jump into their use case development, pick one use case, drive down to deep, deep detail (i.e. all conceivable alternate paths are documented, with all the possible combinations of error conditions and responses, and so forth). Then they move to the next use case. Rinse and repeat. (Often different people or teams are doing this in parallel.)
As Murphy would have it, half way through all their use cases, some new information, understanding, or requirement typically emerges. Then oops! They have to go back and modify the first use case that they already “completed.” This can cascade as the team slowly slides into the analysis paralysis vortex.
Instead of drilling down “vertically”, why not look across all your use cases “horizontally”? What level of detail do you really need for each of the use cases? For example, if you have a use case that provides search functionality, and your team has developed such functionality numerous times in the past, do you really need to specify every possible nook and cranny of this use case? If you team has such expertise, why not stop elaborating that use case once the behaviors are allocated among the actor and system (3rd stage in Figure 1)?
Now if you have use cases that are under the burden of regulatory compliance, high financial risk, high risk to life, or other critical concerns, a full blown elaboration of the use cases is more appropriate (see Figure 2). But don’t choose full elaboration as the default position.
Figure 2: Choose your level of maturity based on your prameters.
What if things change or new information emerges as postulated earlier? Taking a rigid approach requiring fully elaborated use cases at all times raises the probability that your change impact will be much greater than if you take a more, dare I say, agile approach, developing your use cases only to the level needed for implementation.
Use your and your team’s knowledge and experience, considering your particular project situation, to decide how mature your use cases need to really be, before allowing implementation of those use cases to begin.
