What experience do you have writing requirements for hardware or software components? How do you approach it?
The first brick in the foundation of a successful project is well thought out requirements. These requirements flow down from the project level to the level of individual components. You should be able to articulate how you would decide what these requirements should be, even if you've never had to do it yourself. You can think this one through and come up with a good, logical answer. One key is that the requirements should be quantifiable, so that you know whether or not they have been met.
"I have not been responsible for writing requirements for a project or component so far. I have been the one on the receiving end of the requirements, trying to satisfy the specifications. Looking at it from that perspective, and attending project team meetings, I know that it is important to first write down and have the team agree to the high-level goals of the project. For example, suppose you are responsible for the engine management system for a new powertrain that is supposed to meet LEV III emissions standards. That's one high level goal, and you need to then set the engineering targets for those emissions. There may also be cost goals and other goals that have to be taken into account, hopefully ones that are not inconsistent with each other. But everyone has to acknowledge the primary goal, providing a compliant EMS on the date that the customer has requested. From there the hardware and software subsystems have to develop their own sets of quantifiable functional requirements to meet their parts of the goal. Now, obviously, I am describing how requirements flow from the top level of a project downward into smaller systems. But the same philosophy holds all the way down to, say, fuel control. What are the functional requirements for the fuel control? Should a linear or switching oxygen sensor be used? Does the air/fuel deviation from stoichiometry need to be controlled more tightly than in the past? What is the new number? Many of the requirements will be well known from previous projects, and it will pay to focus on the new and changed requirements. But for sure the only way to avoid disappointment and changes in the middle of the project is to write down all the requirements and track them. And then there will still be changes in the middle of the program, this we know. Structured project management approaches try to formalize efforts to create and track requirements, and even though all that paperwork seems annoying, in the end, it always turns out to be important.
If you like, I could also talk about what goes into the requirements for an individual component or algorithm change."
Unlock all 30 Automotive Emission Systems Engineer questions
Unlock expert responses to technical emission control questions that interviewers prioritize.
Get Started