If the tests in test-driven development (TDD) drive product design, who needs requirements?
Actually, some advocates of agile development contend that the tests are the requirements. Instead of composing a requirements document and then developing tests, they argue, just develop the tests.
One flaw in this approach is that tests do not always directly reflect requirements. As I have argued before, requirements are testable in principle but not always directly testable in practice. A requirement straightforwardly captures and communicates a stakeholder need. Tests may indirectly ensure the product meets these needs, but they don't always do so in a way that communicates the needs in a clear and concise manner.
Actually, some advocates of agile development contend that the tests are the requirements. Instead of composing a requirements document and then developing tests, they argue, just develop the tests.
One flaw in this approach is that tests do not always directly reflect requirements. As I have argued before, requirements are testable in principle but not always directly testable in practice. A requirement straightforwardly captures and communicates a stakeholder need. Tests may indirectly ensure the product meets these needs, but they don't always do so in a way that communicates the needs in a clear and concise manner.
Comments
So while I think TDD is a neat idea, it's not actually going to reduce the effort that goes into requirements development at all.