A few thoughts on identifying use case actors and a job-aid that may help simplify the effort.

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.

Building rapport, requirement structure, use case disgruntlement, and RASCI.

UML modeling, outsourcing, and tips to improve requirements management.

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!Recently, I’ve been fortunate enough to participate in some very interesting training sessions relating to business process re-engineering, and UML modeling. Now, I have long understood the value of use cases, but have never fully leveraged them or taken advantage of some of the added …

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:

If you’re new to use case modelling, or just need a refresher, here is an excellent resource; the UML Use Case Diagrams: Tips and FAQ.