Requirements Tracking |
 |
 |
 |
| Written by Graham Stoney | |
|
Nobody really knows absolutely all the requirements a system and all its subcomponents has until the system is completely built. Requirements emerge and change over time. In a complex system, requirements tracking is a big deal; especially when you start doing it systematically. Having a tool to help with requirements tracking can help. I've used Telelogic's DOORS with mixed success. My current suggestion is a lightweight tool like RMTrak, where you can cross-link requirements and design documents in your existing Office tools. I can't say I've actually used it myself, but it looks promising to me. Another approach which can work really well is to use your issue tracking system to track your functional requirements. Just enter each requirement into the issue tracking system as an enhancement request, keep the issues up to date as the requirements evolve, and use the issue tracking tool's usual issue state and work-flow procedures to action and track progress on requirement changes all in the one hit. This approach has very low bureaucratic overheads, and on software projects where your issue tracking system is linked to your source control system, also gives complete traceability to source code level for free. Ideally, your organisation should have a system engineering process incorporating reviews of design input requirements. Requirements for all system components flow down to subcomponents via functional designs which are reviewed as the project progresses. If a designer is uncertain of his input requirements, the first task in the design process is to codify and review their input requirements. Even if they are just the designer's best guess as to what he thinks the requirements are, it's better than just designing blindly. In development environments where requirements handling is lax, designers who take the responsibility of codifying and reviewing their own input requirements show valuable leadership. Social Bookmark this page:         
|