Collect Downstream Requirements In Design Reviews |
 |
 |
 |
| Written by Graham Stoney | |
|
I recommend that all engineers responsible for downstream subcomponents are involved in the reviews of the upstream components and interfaces, and consciously collect inbound requirements for the parts of the system that they are responsible in the process. It's relatively easy while reading the design description for a higher level component or a system function to identify when a design choice has imposed a requirement on the lower level component for which you are responsible. Sometimes it's even worth pointing out “that design choice imposes a requirement on my module” because the designer may not have realised nor considered the implications of doing so. For example, the design of the USB interface imposes the requirement that all devices supporting it be capable of generating a 5V power supply. That's generally not a big deal, but digital logic no longer routinely uses 5V power supplies. It's simply a design choice that imposes requirements which have both pros and cons. Collecting requirements this way works really nicely when you make each Engineer responsible for codifying their own input requirements. Chances are these Engineers are already attending the design review of related components that impact their design anyway, so you kill two birds with one stone this way. Social Bookmark this page:         
|