Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 118 of 229

• Successful designs are usually the result of significant rethinking and reworking. Several iterations of design is the norm, rather than the exception. Design alternatives should be considered. I details of how to get there. Software requireme nts should be th e same way. A software requirements specifi- cation should not contain implemen- tation details. These specifications should describe in suf ficient detail wha t the software will do, but not how. A good se t of requireme nts should be: • Correct-it meets the need • Unambiguous-have only one pos- sible interpretation • Comple te-it cove rs requirements all th e FIGURE 1 • Consistent-the re hould be no confli cts between requirements • Ranked for importance • Verifiable- a test case can be writ- ten • Traceable-refe rring to require- ments should be easy • Modifiable-it hould be easy to add new requirements --- - --- · Soda Button Trying to defin e a large multidi- mensional capabili ty for a complex embedded y tem within the limita- tions of the linear two-dimensional structure of a document becomes almo t impos ible. At the other end of the scale, the u e of a programming language is too detailed. This is noth- ing more than "after the fact specifica- tion" which is just docume nting what was implemented rather than what was required Developing a good set of require- men ts to specify a system can be diffi- cult. In many cases the stakeholders don 't know what they really want. The various stakeholders also tend to express requirements in the ir own terms and may have conflicting requirements that need to be resolved. Organizational and political fac tors may also influence the ystem require- ments. Requirements may also change Change Return , ---- - -- Sold Out light during the analy i process as new stakeholders eme rge. The term "requireme nts enginee ring" has emerged to address the transforma- tion by which vague and, often unre- la ted, custome r requireme nt are transformed into the detailed and pre- cise requirements needed for sys tem implementation. Successful designs are usually the result of significant rethinking and reworking. Seve ra l ite rati ons of design is the norm, rather than the exception. Design alte rnatives should be considered. In general, designs should get simpler rather than more complex. It can be difficul t to specify the total behavior of a complex system because of the total number of possi- ble uses of the system. But this is pre- cisely what needs to be done in order to en ure completeness and consisten- cy in our designs. FIGURE l Natural language requirements for the soda machine .. · :· 1. The soda machine will produce a soda after 75 cents has been entered. The machine will only accept quarters. 2. When the "Change Return" button is pressed, the available change in the input tray is returned . 3. When there is no more soda in the machine, the " Sold Out" light will be illuminated. · Embedded Systems Programming SEPTEMBER 2000 117

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10