Welcome! This site specializes in providing tips and tools for Business Analysts and systems development in general. If you're new here, you may want to subscribe to my RSS feed. If you'd prefer, you can also receive my posts directly to your e-mail. Thanks for visiting!

As I was scanning some requirements-related blog posts a few days ago, I came across a solid post by Prashant Hegde on the topic of Use Case best practices.

He provides quite a laundry list, and I recommend that you give him a read for the rest, but I’ll include a few points that I particularly liked below:

Use discretion while detailing requirements. The mistake is getting too much caught up in precision and rigor when it is not required. If the system to be built is simple and easy to understand the use cases need not be captured with much detail.

Functional decomposition in use cases can get you way off into the weeds and make use case writing much more complicated than it should be - and that’s speaking from experience. I have to admit that that is one of my biggest challenges when it comes to writing out detailed use cases.

The best way to identify the use cases is through brainstorming…. This procedure of identifying the use cases first and detailing them later provides the opportunity for the stake holders to correct any of the wrong assumptions made during the identification process. The thing to remember - once the use case is accurate, you can add precision during its expansion.

I think that is a pretty common approach. It’s certainly one that I use.

The name of the use case is best described with primary actor’s goal. Most of the time it’s the primary actor who triggers the use case.

Use cases need to protect all the stakeholders’ interests even though they are not the primary users of the system.

Writing down the backgrounds, skills and job descriptions of each actor would be useful. User interface designers can use this information for designing appropriate user interfaces.

Agree. I typically maintain a separate stakeholder information sheet/matrix that houses a lot of this information, but if you don’t have that, the use case is certainly a reasonable place to include that type of information.

It is best to avoid naming actors based on their job titles for ex: dispatch clerk etc. It is best to name them according to the role they play with respect to a goal.

This is good counsel, but if you really want or need to indicate titles as well as a more generic role relative to the use case goal, UML has ways of indicating that multiple titles are variations on a given role.

Anyway, Prashant’s counsel is basic and solid. It will be particularly beneficial to those who are relatively new to writing use cases. While you’re over at Prashant’s blog, his introductory level post on activity diagrams is worth a look as well.