
How to write good requirements - micahalles
http://spin.atomicobject.com/2012/02/14/how-to-write-good-requirments/
======
j45
Requirements must use the simplest most accessible language to the greatest
number of readers. I'm not sure that I got that from this article. The essence
of it is something I like a lot, but it focuses on the technical requirements
a little too much. I have come to learn requirements exist beyond the
technical, even though thats where they are implemented.

I have three general rules for requirements that I remind myself of.

First, make sure it's problem-based thinking and not solutions based. Too
often everyone shows up with "do this here" and no one wants to explain what
the problem is or how it's impacting things. It trivializes, causes technical
debt, and lets you evolve your software into a corner so you don't want to
work on it anymore.

Second, Shut up. And learn the business. It's been making money with out me.
I'm here to help the business either make more money with the same or less
effort, or save it money. That's the only value I provide. Don't let my
interpretations and trivialization ruin what competitive advantage they have
in their processes now, no matter how archaic or manual it might be. If they
have no process or system in place, get that created first and let the
software reflect it. DO NOT BUILD SOFTWARE FOR SOMETHING THAT DOESNT HAVE A
REASONABLY WORKING MANUAL PROCESS. Read The Toyota Way to know why.

Third, let everyone know the ultimate goal is to help everyone get more done
without less effort. Overcoming empire builders, insecurity and politics is as
real of a requirement to overcome as anything, be it a small or large project.

To get there, we have the dreaded requirements doc.

For me requirement docs come in two forms. When know know how to solve a
problem, or when we don't. How those are written are quite different.

Writing a document for unknown requirements is most often best approached with
an agile feedback-loop process. Documenting the benefits of this is critical
so everyone knows why we're "trying" instead of "just building it". Miss this,
and the software project is one of the failed 70%.

Writing a document for known requirements (and how to get there) is quite a
bit different. Since we're doing what we know how to do, in situation largely
familar to us, getting very clear language and agreement on the following is
absolutely critical:

\- What needs to be done (functional design),

\- How it needs to be done (technical design / blueprint),

\- Who needs to be doing what, when.

Either way, starting a requirements without a clear explanation of the
problem, nor a clear description of the goal of what the experience should be,
adds tremendous variables and unknowns, without good reason.

------
Silhouette
This article is talking only about functional requirements. There are non-
functional requirements too, and therefore a lot of the advice in the article
is horribly wrong (or at least needs restating with clearer context).

------
ap22213
I was first excited to see a post on requirements. Then, a little saddened,
because as I read it, I noticed that there was little mention of the desired
outcome, the overall vision or context, or stakeholders.

