A Couple Tips on Keeping Use Cases Simple

Use cases are atomic functions that are portable and not dependent upon a certain situation. They are requirement “objects” in the “object oriented” sense. I think that modularity and “reusability” are among the most valuable aspects of using use cases to express requirements.

This modularity can be undermined, though, if we allow our use cases to get too far into specifics and implementation detail.

The book “Use Cases: Requirements in Context”, by Kulak and Guiney, provides us with a couple simple ways to self-check our use cases to ensure that they include the appropriate level of detail, but aren’t reaching too far into design.

Precision Tools: Requirement Structure

I recently posted about the need for accuracy and precision in requirements. In that post, I mentioned that natural language requirements are probably the least precise format for expressing requirements. Many BA’s, myself included, write specs composed of natural language requirements and a few flow diagrams for clarification and context. So, given that natural language is not inherently precise, how do we at least make them as precise as possible?

What are user stories, and why should I use them?

I have used user stories – or at least something similar – to help me identify user requirements, but have never used them as the means of documenting requirements. I am somewhat familiar with the concept, though, and have been interested in learning more.

I found a great deal of help in Mike Cohn’s article, Advantages of User Stories for Requirements. In this article, Cohn explains user stories and the advantages of using them over traditional, natural language requirements and use cases.