Geeks With Blogs
Chris Breisch   .NET Data Practices
Search this Blog!

One of the many reasons for software project failure is failing to meet requirements (well, duh).  But part of that problem is not detailing correctly what the requirements are.

If you think that requirements only fall into the categories of critical success factors and/or must-have/must-be requirements, sprinkled in with a few more-is-better/highly desired requirements, you're missing the boat.

And your projects will fail.

As we learn from Tyner Blain, you have to capture the implicit requirements as well.

Johanna Rothman just wrote an article titled Implicit Requirements are Still Requirements. She points out that her expectations were not met, even though her needs might have been. Johanna also implicitly begs the question - how do we gather implicit requirements?
Johanna’s Experience

Johanna describes the process of installing updated drivers for an all-in-one scanner/fax/printer. The installation process did not live up to her expectations. It took too long, caused additional inconveniences for her, and when she was done, the user interface was inconsistent with her other applications. In short, her expectations, her implicit requirements, were not satisfied.

So, this is a project failure.  That could've been avoided.  As they say, read the whole thing.

Posted on Thursday, February 15, 2007 8:06 AM Architecture | Back to top

Comments on this post: Implicit Requirements Are Still Requirements

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris J. Breisch | Powered by: