Comments on: The NICE Way To Think About Requirements

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 19 Mar 2008 00:40:40 +0000

Personally, I think time spent correlates positively with understanding. But I believe that the incremental benefit of additional study rapidly decreases – at least until you reach a point where you start to gain spontaneous insights. When doing requirements work, I don’t believe most people reach that level – it comes from years of practice within a domain, while studying other domains.

Each individual will reach the point where additional study is more expensive than “doing stuff” – and each person will reach it at a different time.

By: Yogi - Amature

Yogi - Amature — Mon, 17 Mar 2008 18:46:00 +0000

Eye opening but

I wonder, how time spend in requirement gathering plays any role in level of understanding and level of detail.

By: Mikkel Rasmussen

Mikkel Rasmussen — Wed, 27 Feb 2008 10:30:51 +0000

Nice article.

It is the whole precision vs. accuracy discussion again. (With a small twist).

What is the point of giving a very precise answer, if the answer is not accurate?

Example:
Question: What is the value of PI?
Answer A) 3.14
Answer B) 3.15209265

Answer A is not very precise (as in number of significant digits), but is it is accurate (correct to the level of significant digits).

Answer B is very (or at least more) precise but not accurate (as in wrong!).

In my job I am dealing with huge documents containing way too much detail but without the required understanding. It’s sad, but true. One thing is of course to identify the problem, but how do you propose to change the world of bad requirements specifications? I encounter a “this is how we do it here” answer when I bring this problem up in my organization.

Cheers
Mikkel

By: João Pereira

João Pereira — Wed, 20 Feb 2008 16:13:47 +0000

Obvious as in “Eureka” :) because now I understand why after the product manager put in my hands a 400+ pages documents, I keep asking them: what the solution should solve? Their answer: “it’s all in the spec.” WHERE? I reply. :)

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 20 Feb 2008 15:44:52 +0000

Thanks, João! Welcome to Tyner Blain, I think you’re spot on.

And hopefully, you mean “obvious” as in “Eureka!” not “well, duh!”

By: João Pereira

João Pereira — Wed, 20 Feb 2008 15:08:35 +0000

This is so obvious! Unfortunately 80% of the business analysts can’t see the point. Developers are getting tons of documentation with so many details that are irrelevant for the implementation of the solution.

By: Scott Sehlhorst

Scott Sehlhorst — Sun, 17 Feb 2008 04:47:02 +0000

Thanks Jeff! I’ve been in the same boats. I’m also finding parallels in trying to socialize messages across an organization. One of the things I had to learn, starting out as an engineer and then a developer, was how to share ideas without being too verbose. I knew that I had to know “too much” in order to understand, and I always found myself trying to communicate everything I knew.

It is the elegant message that resonates.

By: Jeff Lash

Jeff Lash — Sat, 16 Feb 2008 17:31:05 +0000

Scott — Brilliant article. I’ve been in all 4 of these situations, and at the time, each of the flawed 3 were clearly wrong, though I couldn’t put my finger on exactly why. It especially clarified for me how throwing more documentation at at unclear problem won’t make it more clear, which is something I think a lot of people don’t really understand.

By: Scott Sehlhorst

Scott Sehlhorst — Tue, 12 Feb 2008 13:51:36 +0000

Oops. Where I wrote “At that point, our client was faced with a tough political situation: admit that the money spent on those docs was wasted, or spend more money to redo the requirements. Neither path was a winner.”

I really meant:
“At that point, our client was faced with a tough political situation: Admit that the money spent on those docs was wasted and spend more money to redo the requirements. – OR – Build a solution based on requirements documents that were known to be incorrect and hope to fix it on the fly in some magical way. Neither path was a winner.