Eliciting and analyzing embedded systems requirements

Read this expert response for Sue Burk's suggestions for what techniques developers can use in embedded systems requirements gathering and analysis.

Are there special considerations for eliciting and analyzing requirements for embedded systems?

Embedded systems provide a cohesive set of behaviors in response to specific triggering events. The systems that control a dialysis machine, a copier, a programmable thermostat, the antilock brakes in your car or a missile are examples of embedded systems, each housed in the equipment it controls.  

You’ll find that the requirements elicitation and analysis techniques described in the Business Analysis Body of Knowledge (BABOK)[1] are applicable for understanding embedded systems as well as for business application systems.   

To analyze functional requirements and design embedded systems, developers often use state diagrams, also known as state machines. Here’s why. Very often, the relevant states in an embedded system are real-time, transient states rather than states that are persistently stored. For example, for a copier, the states of interest might be “ready,” “warming up,” “printing,” and “energy-saving.” A state diagram helps you visualize the transitions between states that are triggered by events. You can use a state diagram to show that a copier will transition from  “warming up” to “ready,” and from “ready” to “printing” or to “energy-saving,” based on triggering events. Your diagram can also reveal the events that trigger those transitions and show you how the corresponding behaviors may depend on state. For example, if the copier is in the “ready” state, pressing the Copy button transitions the copier to printing; when the copier is in the energy-saving state, that same trigger transitions the copier to warming up and then  to printing. If the stakeholders want a copier with a “locked” state to prevent unauthorized use, perhaps nothing happens when the Copy button is pressed while the copier is in the locked state.

In addition to -- or instead of -- state diagrams, you can work with context diagrams and use cases[2] or user stories to elicit functional requirements for embedded systems. Also, class models and data models help you understand the underlying structure of the embedded system. Some folks use sequence diagrams to understand how the structure and behavior relate to each other; others prefer state diagrams for this purpose. Your best bet is to choose elicitation techniques that inform and relate to each other and enable clear communication between your stakeholders, subject matter experts, and project team members.

Of course, it’s also vital to specify the system’s applicable nonfunctional requirements -- the external interfaces, quality attributes and design and implementation constraints. For any embedded system, you have to pay special attention to external interface requirements because of the number and complexity of interfaces to consider: embedded software can communicate and collaborate with hardware, application software, direct users and other embedded systems, and it may be embedded within other embedded systems. Embedded systems that support health, safety or military activities have very stringent quality attributes, especially those related to performance, reliability and availability. The design constraints imposed by the device in which the software is embedded -- such as its physical size or capacity or the way it transmits messages to the software -- will heavily influence the software design of an embedded system and need to be clearly understood.

[1] International Institute of Business Analysis, Guide to Business Analysis Body of Knowledge ® (BABOK®), 2nd edition
[2] Ivar Jacobson’s original work with use cases at Ericsson was focused on embedded systems (telephone switching systems).

Dig Deeper on Topics Archive