If you’ve written your new product requirements, you probably understand exactly what they mean. But will the other people on your project team? You also probably understand that some unwritten requirements must also be met. They’re just common sense and everyone knows what they are.
What about that new software developer who is a whiz at the computer stuff, but not so savvy about pressure transmitters? Requirements can be subject to interpretation and confusion. Different parts of the organization speak different languages, literally or figuratively. Marketing may know what the customer wants but engineering has to translate this information into a design. A test engineer may have their own opinion of what should be tested. Off-site development teams have infrequent contact with other members of the organization.
An ill-informed choice at any stage of development could delay the project beyond its window of opportunity. But because the requirements phase is so far upstream in the development effort, a mistake there can multiply the effect. A lot more engineering work must be undone and corrected as you determine the full set of requirements. And this effect can be compounded if you were bound by contract to deliver on a specific date… there goes this year’s bonus!
Requirements Review to the rescue! Be sure to allow enough time in your schedule to perform a detailed review of the requirements at each of these stages:
- Product/marketing requirements
- Overall system requirements
- System safety requirements
- Software safety requirements
- Design requirements
Get the right mix of people involved in these reviews. This means product managers, engineering managers, HW and SW developers, testers, functional safety coordinators, and project managers should all be involved. Even bringing in some experts from other areas of the company can help, often providing a broader perspective. Make sure the requirements are specific, measureable, and realistic. Requirements Review won’t solve all your product development problems, but teams who perform this task effectively have a much higher chance of completing a project on time.
Tagged as: John Yozallinas