Embedded System Design Cycle Questions and Answers

Answer: A

Correct answer: specifying how the software is to be structured internally

The requirements document says what the product must do and under what constraints; how it is built is the business of the design documents. Keeping the two separate matters because requirements are traced to acceptance tests and negotiated with the customer, while the internal structure may be revised freely so long as the requirements are still met.

Answer: B

Almost everything except the board-specific bring-up can be written and tested on an evaluation board with the same processor, which takes the hardware off the software's critical path. It is the standard mitigation for exactly this risk.

Answer: C

The assessor asks how each requirement is known to be met, and the answer must be recorded rather than remembered. Reconstructing it afterwards is far more work than keeping it, and a reconstruction carries much less weight.

Answer: D

Building something small and showing it is the fastest way to discover what the customer actually meant, which a document review often fails to reveal. Requirements are still written down, and the hardware iterates in fewer and larger steps than the software.

Answer: A

Correct answer: a check that every interface responds

A production test asks one question: was this unit built correctly? Checking that every interface responds does that, quickly and on every unit. The other three are design verification or qualification activities, done once on samples - emissions testing, re-verifying the design against its requirements, and accelerated life testing all prove the design rather than the individual unit.