Requirements for Devices Around Us: Embedded Systems

Most discussions about software requirements deal with business information systems and similar projects. The world is also full of products that use software to control hardware devices, broadly called embedded systems. Among countless examples are cell phones, television remote controls, kiosks of all sorts, Internet routers, and robot cars. Embedded and other real-time systems contain sensors, controllers, motors, power supplies, integrated circuits, displays, and other mechanical, electrical, and electronic components that operate under software control. This is the first article of two that will discuss some of the requirements issues that are especially important to embedded and other real-time systems.

It’s important to have a good understanding of requirements before getting too far into development on embedded systems projects, even more than on most software development projects. Excessive requirements churn that dictates hardware changes is much more expensive than comparable volatility on software-only projects. It’s also essential to know about constraints that both hardware and software engineers must respect: physical object sizes; electrical components, connections, and voltages; standard communication protocols; the sequence in which certain operations must take place; timing requirements; and the like. Hardware components that have already been selected for the design impose constraints on those yet to be chosen.

When specifying a complex system, many teams first create a system requirements specification, abbreviated SyRS. (see http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171). The SyRS describes the capabilities of the system as a whole, including capabilities that could be provided by hardware components, software components, and/or humans. It also describes all of the inputs and outputs associated with the system. In addition to functionality, the SyRS should specify the critical performance, safety, and other quality attribute requirements for the product.

All this information feeds into the preliminary design analysis that will guide the team when it is choosing architectural components and allocating capabilities to them. The SyRS could be a separate deliverable from the software requirements specification, or the SRS could be embedded within the SyRS, particularly if most of the system complexity lies within the software.

Requirements analysis of a complex system is tightly intertwined with the system’s architecture. Requirements thinking and design thinking become more commingled in real-time systems than in other types of software projects. The architecture represents the top level of design, often depicted by using simple box-and-arrow diagrams. A system’s architecture consists of three elements:

• Components of the system, where a component could be a software object or module, a physical device, or a person
• Externally visible properties of the components
• Connections (interfaces) between the system components

The architecture is developed in a top-down, iterative fashion. The person who takes the lead role in this type of analysis typically is a systems analyst, requirements engineer, systems engineer, or systems architect with a strong technical background. The analyst partitions the system into appropriate software and hardware subsystems and components that will accommodate all of the inputs and produce the outputs. Certain system requirements might turn directly into software requirements if software is deemed to be the correct medium for providing a certain capability. In other cases, the analyst will decompose individual system requirements into numerous derived software, hardware, and/or manual requirements to be performed by humans (Figure 1).

Deriving software requirements from system requirements can expand the volume of requirements several-fold, partly because that derivation generates interface requirements between the components. The analyst allocates the individual requirements to the most appropriate components, iteratively refining the architectural partitioning and the requirement allocations. The ultimate outcome is a set of requirements for each of the software, hardware, and human components that will collaborate to provide the necessary system services.

Figure 1. System requirements are decomposed into software, hardware, and manual requirements, then allocated to appropriate components.

It’s a good idea to establish trace links between system requirements, the software and hardware requirements derived from them, and the architectural components to which they were allocated. Tracing lets you verify that each system requirement was addressed in the downstream deliverables. It also facilitates modifying the system in the future, as you can see how a proposed new or altered system requirement will ripple change throughout the system.

Poor requirements allocation decisions can result in:

• The software being expected to perform functions that hardware could have performed easier, cheaper, or faster (or the reverse).
• A person being expected to perform functions that hardware or software could have performed easier, cheaper, faster, or more safely (or the reverse).
• Inadequate performance.
• The inability to easily upgrade or replace components.

For example, performing a certain function in software could require a faster processor than if a specialized piece of hardware were to perform that function. There are always trade-offs. Although software is easier to change than hardware, engineers shouldn’t use that flexibility as a reason to skimp on hardware design. The people who perform the requirements allocation must understand the capabilities and limitations of the software and hardware components, as well as the costs and risks of implementing the functionality in each.

As with business information systems, visual modeling is a powerful analysis technique for specifying real-time systems. One useful model is an architecture diagram. Figure 2 shows a portion of a simple architecture diagram for an exercise treadmill. Each rectangle represents one of the major subsystems that will provide all of the treadmill’s functions. The arrows between the boxes illustrate the data and control interfaces between the subsystems, at a high level of abstraction. Richer architecture description languages are available if a simple block diagram like this doesn’t meet your needs.

The subsystems shown in Figure 2 can be further elaborated into specific hardware components (such as motors and sensors) and software components as architectural analysis proceeds. A preliminary architectural analysis can reveal and refine functional, interface, and quality requirements that might not have been evident from other elicitation activities.

Figure 2. Partial architecture diagram for an exercise treadmill.

Drawing architecture models during requirements analysis is clearly taking a step into design. It’s a necessary step. Iterating on the architectural partitioning and the allocation of system capabilities to subsystems and components is how an architect devises the most appropriate and effective solution. You’ll need to perform further requirements elicitation, though. Functional requirements such as the following examples will guide the developers in both choosing appropriate hardware components and designing user interface controls:

Incline.Angle.Range: The Exerciser shall be able to increase and decrease the incline angle of the treadmill from 0 degrees through 10 degrees, inclusive, in 0.5- degree increments

Incline.Angle.Limits: The treadmill shall stop changing its angle and provide audible feedback when it has reached the minimum or maximum limit of its incline range.

In addition to the functionality represented by the architecture, the treadmill designers must know about the business rules that provide necessary algorithms. An example is calculating the number of calories the Exerciser has burned from the combination of his or her weight and the workout program (a series of segments of specified duration, incline angle, and belt speed). It might seem peculiar to speak of “business rules” in conjunction with an embedded system, but they pertain there just as they do to information systems.

The second article (Requirements for Embedded Systems - Part 2) in this series will explore some of the quality attribute categories that are of particular importance to embedded and other real-time systems.

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.