This chapter is from the book
This chapter is from the book
This chapter is from the book
Flow-Down for Hardware and Software Systems
When developing a system comprised of both hardware and software, the flow-down of requirements to measurable technical requirements (subordinate y's, x's, and noises) might lead to three situations:
- Critical parameters that only involve hardware aspects
- Critical parameters that only involve software aspects
- Critical parameters that involve both hardware and software aspects.
For a hardware intensive system, or a system that involves little or no software, the critical parameters flow down to subsystems and components that are electrical or mechanical. The technical challenges for some products or some subsystems might fall entirely within one engineering discipline. For example, a team of mechanical engineers might flow down or decompose the critical parameters for a lawnmower to subsystem and component requirements. Other hardware intensive products might require a team composed of electrical and mechanical engineers, or the development organization might be structured so that these teams are separate, but a cross-functional team would handle the electrical-mechanical interactions and interfaces.
The flow-down for some requirements of a cell phone is particularly relevant for electrical engineers who are knowledgeable about radio frequency (RF) performance. Figure 10.4 shows part of the system-level House of Quality example discussed in Chapter 7. Two critical parameters, total radiated power (TRP) and turn-on time, are highlighted. In Figure 10.5, a second House of Quality focused on the RF sections of the cell phone indicates that TRP flows down to some measurable requirements for the antenna and for the transmitter. Figure 10.6 shows the flow-down, juxtaposed with some images of the physical layout within the cell phone.
)
Figure 10.4 System-level House of Quality, focusing on two critical parameters, total radiated power from the transmitter and antenna, and turn-on time for the cell phone
)
Figure 10.5 Second or subsystem-level House of Quality, focusing on the radio frequency (RF) subsystems including the antenna, receiver, and transmitter for a cell phone
)
Figure 10.6 Flow-down of the total radiated power requirement for a cell phone to measurable requirements on the antenna and for the transmitter within the transceiver assembly
Figure 10.7 shows the flow-down or decomposition of the critical parameter, cellular phone turn-on time, to hardware and software requirements. A team of system engineers, software engineers, and hardware engineers discussed this flow-down, and developed a simple mathematical model for the turn-on time, which showed that the delays in phone turn-on caused by the hardware requirements such as phase locked loop (PLL) lock time were negligible. The critical parameter for turn-on time then became a software development team focus.
)
Figure 10.7 Flow-down of cell phone turn-on time to hardware and software requirements
Critical parameters that can involve both software and hardware aspects require that initial combined team approach. If software or hardware is totally dominant, then the effort can be handed off to the appropriate team as was the case for the turn-on time for the cellular phone. If neither software nor hardware dominates to such an extent, the effort on the critical parameter can either continue to be addressed by a team consisting of system engineers and software and hardware engineers, or the software aspects can be handed to the software team and the hardware aspects can be handed to the hardware team. In the latter instance, the interfaces and interactions between hardware and software risk "falling in the crack," so an additional effort is required to consider these interactions and to integrate the hardware and software aspects. In many cases, emulation can be used to evaluate the software aspects without the final version of the hardware but, rather, an existing hardware platform modified to behave like and substitute for the hardware.
The second House of Quality, as shown in Figure 10.5, is one of several methods to flow down requirements. Other methods can use a P-diagram, as discussed in the next section, or brainstorming session with a set of engineers, including system engineers, to identify indirect or intermediate requirements (subordinate y's), control factors (x's), and noises (n's) that affect the critical parameter, as discussed in the flow-down section later in this chapter.