Using requirements planning in embedded systems design: Part 1 - Dissecting the requirements document

In the following parts in this series, we will categorize the information, document it in a couple of useful shorthand notations, and check the result for any vague areas or gaps. Only when the designer is sure that all the information is present and accounted for, should the design continue on. If not, then the designer runs the risk of having to start over. The five most frustrating words a designer ever hears are “What I really meant was.”

So what is needed in a requirements document? Taking a note from the previous section, the four basic requirements are:

• Tasks: This includes a list of all the functions the software will be required to perform and any information concerning algorithms.

• Communications: This includes all information about data size, input, output, or temporary storage and also any information about events that must be recognized, and how.

• Timing: This includes not only the timing requirements for the individual tasks, but also the overall system timing.

• Priorities: This includes the priorities for the system, priorities in different system modes, and the priorities within each task.

Together, these four basic requirements for the system define the development process from the system level, through the component level, down to the actual implementation. Therefore, they are the four areas of information that are needed in a requirements document.

Designing a six digit alarm clock
So, where to start? As the saying goes, “Start at the beginning.” We start with the system tasks, which means all the functions that are to be performed by the tasks. And that means building a function list.

To aid in the understanding of the design process, and to provide a consistent set of examples, we will use the design of a simple alarm clock as an example. The following is a short description of the design and the initial requirement document:

Figure 3.1.Requirements Document
The final product is to be a 6-digit alarm clock with the following features:

1. 6-digit LED display, showing hours : minutes : seconds. The hours can be in either a 12 hour or 24 hour format. In the 12 hour format a single LED indicator specifying AM / PM is included.
2. 6 controls, FAST_SET, SLOW_SET, TIME_SET, ALARM_SET, ALARM_ON, SNOOZE.
3. The alarm shall both flash the display, and emit a AM modulated audio tone..

Building a function list
The first piece of documentation to build from the requirements document is a comprehensive function list. The function list should include all of the software functions described in the requirements document, any algorithms that may be specified or implied, and the general flow of the functions operation.

Reviewing the requirements document above, the following preliminary list of functions was compiled:

Figure 3.2 : Preliminary Function List
1. Display functions to output data onto the displays
a. 12-hour display function for time
b. 24-hour display function for time
c. 12-hour display function for alarm
d. 24-hour display function for alarm
e. Display flashing routine for the alarm
2. An input function to monitor and debounce the controls
a. Control input monitoring function
b. Debounce routine
3. A Command decoder function to decode the commands entered by the controls
4. An alarm function to check the current time and generate the alarm when needed.
a. Turn alarm on / off
b. Snooze
c. Generate alarm tone
d. Set alarm
5. Real-time clock
a. Increment time at 1Hz
b. Set Time