Jonathan Babcock

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!Wikipedia (with help from Ivar Jacobson) defines actors as:

[S]omething or [...]

In my business analysis group, we identify user requirements through use cases, but we don’t use user stories. As I am not extremely well-versed when it comes to some of the agile methods, I thought I’d do some research to learn more about user stores and to determine how user stories are different from use cases and from traditional requirements.

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.

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?

In Requirements, Accuracy Isn’t Enough
Allow me to reflect and maybe even toot my own horn here for just a second. Since I’ve been a business analyst, I think it’s fair to say that I’ve written accurate requirements. By this I mean that they have accurately represented what a user needed to be able to do, [...]

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, [...]

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 features inherent in tools designed specifically for UML modeling. In [...]