Jonathan Babcock

My company has been looking at requirements management solutions, which has provided me with the unique opportunity to play the “user” role for a change, and to do a little research into the attributes that make requirements management successful.

Anyway, what I’d like to do with this post is to share a few items I’ve found on the Web as well as some of my own thoughts on what might be of use to others who might be looking for a requirements management solution.

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.

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!I’ve blogged recently about participating in the business analysis community, [...]

I’ve noticed a recurring discussion around various business analysis-oriented websites of late concerning the relevance and value of the Business Analyst, especially in an agile environment. Some argue that with agile, “business analyst” responsibilities are carried out by software developers or technical architects, eliminating unneeded layers of communication (read; BA’s).
Karl Wiegers, one of my favorite [...]

This post is based on a quote I read and liked from the article, “When Requirements Go Bad: Part II” by Kurt Bittner. The article is available from Dr. Dobb’s Requirements Development e-zine (free subscription required). According to Bittner:

We need to banish the practice of writing requirements that we can “throw over the wall” to developers or testers and instead pursue a more open, communicative approach. What is important to realize is that requirements are what motivate discussions, but it is the discussion that matters most.

Well said. While I’ve taken an occasionally rocky path to get there, my experience as a BA has led me to the same conclusion.

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