Do you need a serious requirements document?

Some don’t seem to think so,–did-it-deliver-.html

Getting everyone on board still can be an issue, however. “One of my guys keeps telling me that he would like to have more specified requirements. I keep telling him we’re going faster because we don’t have specified requirements,” Weston says. A hardcore requirements document is a “waste of time,” he adds.

When I see comments like this I immediately want to know

  1. what is the domain?
  2. Is your industry regulated or safety critical?
  3. how large is the overall effort?
  4. what other systems does your product interact with?
  5. who are the customers? How many? how diverse?
  6. who are the other stakeholders?
  7. how long do you expect the product to be in use?

Without context, I don’t now what to make of a statement like “A hardcore requirements document is a “waste of time,”. If, for example you are doing embedded systems in a medical device or changing a component inside a bank’s accounting system  I think I’d want the requirements stated pretty explicitly.

Some documents are a waste of time, sometimes they are part of the delivery.   Often they are tool to make communication precise, persistent, distributable  and reviewable.  Context matters.


About Bill Nichols

PhD in Physics from Carnegie Mellon University I'm a software team coach and instructor with the TSP Team at the Software Engineering Institute
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s