requirements archives
“Too many CIOs get lost in the thicket of what platforms are hot today, what buzzwords are ascendant, what tool got the reviews here, or there, and never take time to sit down with a user and observe, and listen, and talk.”
From Mark Hurst on Good Experience. Helpful quote as I prepare to host a training session on conducting customer interviews next week. Good dialog illustrating why it’s important for management to buy in to user-centered principles.

posted by ted 2 hours ago · 0 comments

“People don’t want to buy a quarter-inch drill.
They want a quarter-inch hole.”
Theodore Levitt, quoted in The Innovator’s Solution, sequel to The Innovator’s Dilemma, both recommended to me by John as I’m in the early stages of defining what a proposed product should do.

Timely reminder that customers “hire a product to do a job,” not to fill a slot on their shelf reserved for an artificial product category. (Of course they don’t really just want a hole; they want to build something, drain something, see through something, etc. We need to get down to real intents and desired outcomes, or we’ll never understand what we should build to meet real needs.)

posted by ted on Tuesday, Jun 09, 2009 · 1 comment

“If we were to switch off the system, where and what would be the biggest impact?”
One of several Powerful Questions noted on the BDD site Tadd reviewed

posted by ted on Thursday, Jan 24, 2008

Requirements

Today I stumbled across Behavior-Driven Development-BDD for the first time. It’s an evolution of the thinking behind Test-Driven Development-TDD. The theory is intriguing. I like the focus on behaviors rather than tests. It appears to be more user experience and results oriented.

At its core are three principles which really ring true with me:

  1. Business and Technology should refer to the same system in the same way
  2. Any system should have an identified, verifiable value to the business
  3. Up-front analysis, design and planning all have a diminishing return

But the reason I bring this up is because of the “story” model they present for stating requirements:

Model

As a Role
I want Feature
So that Benefit

Example

As a savings account holder
I want to transfer money from my savings account to my checking account
So that I can get cash easily from an ATM

Most requirements or feature requests only have the “what” portion of that statement. How cool would it be to keep the “who” and the “why” right next to the “what” of each requirement?

I don’t know if the cost/benefit is there for this approach. Again, I just read some articles today. It could take a lot of time to gather all of a project’s requirements this way. But there would definitely be some value. Think of the inevitable prioritization discussions. Which feature is most important? I’m certain that keeping the who and why as a part of those discussions would lead to better decisions.

I’m a big Ruby on Rails fan. Because of this BDD reading, I finally took a look at RSpec, a BDD framework for Ruby. I’m equally intrigued here and intend to try this out on my current project.

They expand on the “story” model adding scenarios.

Story: transfer from savings to checking account
  As a savings account holder
  I want to transfer money from my savings account to my checking account
  So that I can get cash easily from an ATM

  Scenario: savings account has sufficient funds
    Given my savings account balance is $100
    And my checking account balance is $10
    When I transfer $20 from savings to checking
    Then my savings account balance should be $80
    And my checking account balance should be $30

  Scenario: savings account has insufficient funds
    Given my savings account balance is $50
    And my checking account balance is $10
    When I transfer $60 from savings to checking
    Then my savings account balance should be $50
    And my checking account balance should be $10


RSpec then allows you to build this story and scenarios right into the actual code. The RSpec site has more on that.

Again, would it be valuable and useful to gather requirements like this prior to coding? We have to get at least some of this information before we can complete this feature. This just seems like an interesting way to document that information. For what its worth, it’s got me thinking new thoughts.

posted by tadd on Wednesday, Jan 23, 2008

“This feature provides the customer with a considerable length of hanging rope and foot-loving ammo.”
Team member, summarizing decisions in a meeting where a potentially dangerous feature request was discussed

posted by ted on Friday, Nov 30, 2007