Applying Design for Six Sigma to Software and Hardware Systems: Requirements Flow-Down
This chapter is from the book
This chapter is from the book
This chapter is from the book
Position within DFSS Flow
Requirements flow-down is aligned with the early part of the Design phase of the RADIOV process, which corresponds to the transition from the Measure to Analyze phases of the DMADV process of DFSS or from the Concept to Design phases of the CDOV process. The DFSS flowchart, which can be downloaded from http://www.sigmaexperts.com/dfss provides a high-level overview (Figure 10.1) of the sequence of steps that can be drilled down to detailed flowcharts, and further drilled down to summaries for key tools and deliverables within each detailed flowchart. Figure 10.2 is the detailed flowchart aligned with this chapter, showing the steps and methods involved in flowing down system requirements.
)
Figure 10.1 Flowchart overview highlighting step for flow-down of critical parameters
)
Figure 10.2 Flowchart, drilled down to detailed flowchart for flow-down of critical parameters
For a system involving both hardware and software, the flow-down for system requirements will result in software and hardware requirements, evolving to subsystem requirements and to subassembly requirements and requirements for components (software components and hardware components). The sequence of steps in the flow-down process is iterative, in the sense that the anticipation of potential problems, measurement system analysis, and initial design capability analysis will be first performed at the system level, then at the subsystem/subassembly level, and then at the component level, as illustrated with the iterative nature of the flowcharts in Figures 10.2 and 10.3.
)
Figure 10.3 Evolution of system requirements
Figure 10.3 starts with a set of high-level system requirements. The process of "systems design" consists of turning these requirements into a specification of the system. First, a concept or architecture must be specified at the system level that identifies the subsystems, the interfaces between them, and any interfaces to the outside of the system—including the user interface and interfaces to or interactions with other systems. For electronics systems, interactions with other systems can be intentional, as in data communication linkages, or unintentional, such as with EMI (electromagnetic interference—unwanted disturbances caused by electromagnetic radiation emitted to or from another electronic system).
- For each subsystem, define the behavior and performance with subsystem requirements. Identify other subsystems and systems with which this system might interface or interact, and define the requirements for the interfaces.
- The team responsible for a subsystem is expected to not only deliver that subsystem so that it meets all of the requirements when isolated, but to meet all of the requirements when it is integrated with the other subsystems.
- The design for a subsystem requires considerations and decisions for how to meet all of the requirements jointly. This design should be documented in a subsystem specification that also contains the architecture for the subsystem, consisting of the components within the subsystem, the interfaces between these components, and the interfaces to other subsystems or other systems with which it can interact (see Chapter 12 for software architecture examples). Furthermore, each component has requirements that define the behavior and performance required for the component to work with the other components and meet requirements jointly. This process continues down to low-level design.