Requirements traceability refers to the ease of tracking the relationship of artifacts to product requirements throughout the development process. One form of requirements traceability involves slavishly documenting each design decision and precisely which requirement(s) it addresses. There's got to be a better way. And there is.
If your team isn't communicating well and your process is broken, you are likely to have some of the following problems:
Instead, why not nudge the team into adopting a few simple, lightweight practices?
Realize that test-driven development (TDD) goes a long way towards establishing a de facto requirements traceability. Encourage your team to "document" its requirements and interaction design decisions as test cases.
But you'll want to test frequently. Use demonstration-based agile (DBA), in which the team delivers a demo and submits things to QA for testing on a weekly basis.
Let's examine the effects of adopting these practices.
First, if design and implementation decisions conflict with the requirements, it will show when the tests fail.
Second, when requirements change, the test cases change, and any other changes that must happen will happen, otherwise the tests will fail.
Third, the weekly demos will ensure that product manager is able to trace or track adherence to the requirements.
Finally, and most importantly, your team will communicate frequently, which will likely improve the quality and efficiency of its output.
Rather than imposing requirements traceability in a heavyweight manner, use DBA.
- Features that are "neat" but don't address requirements.
- Designs that don't address requirements.
- Difficulty adjusting to changing requirements, priorities, and scoping.
- QA that doesn't know what to test.
Instead, why not nudge the team into adopting a few simple, lightweight practices?
Realize that test-driven development (TDD) goes a long way towards establishing a de facto requirements traceability. Encourage your team to "document" its requirements and interaction design decisions as test cases.
But you'll want to test frequently. Use demonstration-based agile (DBA), in which the team delivers a demo and submits things to QA for testing on a weekly basis.
Let's examine the effects of adopting these practices.
First, if design and implementation decisions conflict with the requirements, it will show when the tests fail.
Second, when requirements change, the test cases change, and any other changes that must happen will happen, otherwise the tests will fail.
Third, the weekly demos will ensure that product manager is able to trace or track adherence to the requirements.
Finally, and most importantly, your team will communicate frequently, which will likely improve the quality and efficiency of its output.
Rather than imposing requirements traceability in a heavyweight manner, use DBA.
Comments