Make each Engineer responsible for their Input Requirements |
 |
 |
 |
| Written by Graham Stoney | |
|
One of the challenges of requirements management when developing a complex system is the question: Who should be responsible for codifying the requirements? The System Engineer generally gets the job of managing the System Requirements, but what about all the requirements that flow as design inputs to the various system components? There are three potential answers to this question:
I don't like the first option, because the System Engineer immediately becomes a bottleneck, and also a scapegoat for undisciplined designers who don't bother reviewing their requirements before they start. It gives them the excuse "Well, the System Engineer didn't give me the requirements, and I had a deadline to meet, so I just started designing anyway. What else was I supposed to do?" I don't like the second option, because requirements for each system component typically flow from more than one place and so a designer can't describe all the requirements for a downstream component just based on their own work. However, it does have the advantage that designers become mindful of the fact that the design choices they make impose requirements on other system components or subcomponents. If you are leaning this way, I'd suggest making each designer add a table of out-bound requirements in their design descriptions, but still make the downstream designer responsible for collecting all these together to form their in-bound requirements. So I recommend option 3. This boils down to engineers being given responsibility for gathering, codifying and reviewing their own input requirements. If requirements aren't being tracked via some form of automated tool, make the first chapter in your design description a list of the design input requirements, and review it before the design has progressed too far. Social Bookmark this page:         
|