So why do I say that requirements specifications are waste? After all, I’ve been trying to follow them for more than 25 years. But I never did that well. Sure, I think I understood the business value and created that, but it has been despite the specification.
What defines a system, besides itself, is the test cases. If the test cases are not running without manual intervention, the test protocol is needed as well. But now we are drifting into the fog of documentation.
There is no waste trying to find the requirements, it is the specification that tries to get so formal, that becomes the waste. When you search for requirements, you search for business value. But when you try to write a really good requirements specification, you get so formal, it almost like writing the code.
As I said, I’ve been around for a while. There have been so many attempts to find a way to express requirements in ways that can not be misunderstood and even be executable. But I will refrain from that history lesson.
Again, the point is that the requirements specification is waste. The spec as we know it, I mean.
If the requirements specification is waste, how that does this affect bug reports? I say, they are waste too.
At least, when the bug report is written by a tester that compares the outcome of a test case with the requirements specification. Since the latter is waste, so is the bug report.
You don’t need bug reports from your tester, you only need to know which test case that failed.
So all we have are our user stories (User stories are not use cases and are not requirements, they are not formal enough), which we use to discuss and later throw away, the code and the test cases.
That is all. The rest is waste, unless there is other value to it, such as a design guideline that really helps or an overview of the system architecture that really helps understanding.
First of all; yes I am a viking, and I’ll be looking forward to that glass of mjöd on some Agile Convention in the near future 😉
And more importantly; I agree with you. Completely.
Requirements are waste and we should’nt bother writing them. If we can avoid it.
My blog post was on the topic of finding a means of cooperating with a department that is still working according to waterfall. My idea of delivering the requirement specification incrementally is _only_ a workaround for allowing this cooperation cross departments where one is “agile”* and another is not,.
* Yes I know, not fully Agile until all parts of the software lifecycle are covered.
If it was completely up to me I would immediately put the tester(s) in the same team (cross-functional/-competent teams for the win) and forget about requirements; because you’re right, what really defines a system are the test cases; so even the bug reports are waste.
I’ll continue advocating for this internally here, trust me on that. But until I get my way, I need some path forward.
🙂 Thanks for your comments and this post!