Meaningful Requirements
I simply have to comment on James McGovern's latest post on requirements where he says:
When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?
This is the result of failing to realize that "technical requirements" cannot be made separate from functional requirements since a function includes the notion of acceptable/predictable behavior. This is where the analysts can borrow a technique from developers: Test-Driven Development (TDD). For lack of a better term, let's call it Test-Driven Analysis.
What would TDA include? It would include a description of the function plus sample inputs, outputs and expected results, including expected failures (samples of say, SQL injection attack code that must be rejected). Moreover, this wouldn't just be data-focused. Other properties such as the range of acceptable response times, expected feedback, etc. need to be determined. Now we have embedded those "technical requirements" directly into the functional requirements plus have added measurable quality attributes that further serve as acceptance tests/criteria.
It's not like this can't be done, it's just a lot of hard work.
Posts
3 comments:
It's good to see TDD encroaching into other domains, but ...
I thought that the essence of TDD was not that every function should have a batttery of tests, but that the definition of the tests should precede the writing of the function. The implication here would be you'd need to specify your analytical outputs for a requirement prior to having articulated that requirement. That seems to me to be in the realm of "can't be done" rather than just a lot of hard work.
Let me clarify. Yes, TDD is about defining tests before the function gets written. However, the end result is ALWAYS known. The tests are then used to refine what the result will look like and how it needs to be delivered.
I don't think this philosophy would be hard to implement for requirements management.
It strikes me as a natural quality extension of requirements; that they are testable to a binary measure of whether they are met or not.
In fact, requirements that are simply to test seem commonsense to me.
Giving the analyst the job of deining test caes is one way of getting requirements to this state quickly.
Post a Comment