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.
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).
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.
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.