writing good requirements

Passionate Requirements

Posted on: September 27, 2010

Writing passionate requirements is not about writing with passion. It is about writing the requirements that cause people to be passionate about your product. Find the most important problem, for your most important customers. Understand the essence of what is important to solve that problem, for only those people. Then […]

Atomic Requirements

Posted on: September 14, 2010September 14, 2010

Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements […]

Business Analysis / Ishikawa Diagram / Kano Analysis / Product Management / Requirements / Requirements Models

Verifiable Requirements

Posted on: August 30, 2010

Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what […]

Agile / Business Analysis / Ishikawa Diagram / Product Management / Requirements / Requirements Models / Software development / Use Cases / User Stories

Concise Requirements

Posted on: August 3, 2009August 3, 2009

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things: Identify the problems that need to be solved. Explain why those problems are worth solving. Define when those problems are solved.

Business Analysis / Product Management / Requirements / Requirements Models / Software development / Software requirements specification

Broken Requirements Ecosystem

Posted on: June 21, 2007June 22, 2007

There’s an interesting thread on Seilevel’s requirements forum about why developers don’t read the specs and how to fix this problem. Sometimes the developers throw away the requirements. And that’s bad. But it is a symptom. Something is broken at a higher level.

Flashback