All Entries in the "Requirements" Category

Time Travel for Context-free Use Cases

Yes, sometimes we BA’s need to think of creative ways to help us withhold the technology and implementation detail from our requirements.

More on Separating Rules from Use Cases

Keeping business rules out of the flow of events makes a use case easier to maintain and reuse.

Use Case Basics: Keeping it Simple

A few simple tips for identifying and documenting use cases.

Could requirements analysis be automated?

Could systems and software be used to take the place of the requirements analyst?

Structured Analysis & Big, Thick Documents

Great book on modeling & systems analysis and yet another critique of “big, thick documents.”

What’s in a Signature?

Is there such thing as a peaceful, amicable “sign-off”?

Requirements Are the Keystone

Requirements are the keystone of a successful project implementation.

Bright Idea on Requirement Character Limits?

Adam Feldman, blogging from Bright Green Projects’ “Bright Ideas” blog poses a fun and interesting question. Twitter limits entries to 140 characters. Should we do the same for requirements?

Requirements Elicitation: “Most Valuable” Questions

A few of my favorite requirements elicitation interview questions, and an idea for cataloging them.

Requirement Visualization: Mock-up & Wireframe Goodies

Here are some great product links and quotes on rapid UI prototyping that have helped reinforce the value of visualized requirements in my mind, and that I thought you might find interesting.

Requirements Management Link Love (09-13)

A little linky love this week for those of us who like to read all about requirements management.

Sherlock Holmes on the Necessity of Requirements

During some time off a while back, I went to Project Gutenberg and downloaded The Adventures of Sherlock Holmes. I still haven’t read them all, but I was surprised to see the great detective speak out so strongly in favor of requirements in A Scandal in Bohemia.

Use Cases or User Stories? Read Up!

There have been some really interesting articles in recent days and weeks that have been comparing use cases and user stories, and highlighting the advantages of each. I’ve cherry-picked some of the best from my collection of bookmarks to share with you here.

Regardless of what method you use, it is good to be familiar with the available options and their relative strengths and weaknesses.

Requisite Pro + Doors = ?

What does IBM’s acquisition of Telelogic (Doors) mean to the future of both products? What does it mean for their users? I thought I’d share a recent article I came across that shows that IBM has made some progress in determining how they’ll leverage both products.

Use Case Basics: Distinguishing Between Exception and Alternative Paths

A while back I was involved in a discussion during which someone commented that because exceptions are really just alternatives to the main success path, then there’s really no need to bother distinguishing them from other alternatives to the main success path.

While I knew that idea didn’t feel quite right, and there must be a good (and probably simple) response, I didn’t have one at the tip of my tongue at the time. And I admit, it wasn’t a burning issue that kept me awake at night, so I never thought much about it afterward until I came across this description of why we differentiate between the two.

Is the Solution Animal? Vegetable? Mineral?

Ever taken a “20 questions” approach to requirements elicitation? According to The Bitter Project Manager, there are good reasons for doing so. Querying the user/customer in 20 questions fashion helps to determine s/he wants by eliminating the things s/he doesn’t.

Requirements Management Tool Resources

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.

Looking for Sample Requirement Specifications and Templates?

Quick, simple tips to find sample requirement specs, templates and other sample documents.

Quick Tip to Help Identify Use Case Actors

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

More on User Stories

How are user stories different from use cases and from traditional requirements?

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?

Good Requirements Are More Than Just Accurate

The business analyst’s job is not complete if the requirements are documented and accurate but lack precision.

Requirements Elicitation: Are You the Artist, or the Order-Taker?

Requirements elicitation is an art. Watching a solid business analyst efficiently identify and document business need by using a careful mix of questions is much like watching the work of any other type of artist.

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.

UML Use Case Modeling – A Little Help?

Welcome to Practical Analyst, a site specializing in practical insight for business analysts and project professionals.

If you’re new here, you may want to subscribe to my RSS feed or follow me on Twitter. Thanks for stopping by!
Recently, I’ve been fortunate enough to participate in some very interesting training sessions relating to business process re-engineering, and [...]