ABSTRACT
The blue parts in Figures 2.4 and 2.6 show the visible work and output of the systems engineer. In the design phase, it is the systems engineer’s responsibility to develop the customer’s wish into the requirements and then into a realizable system design as described in §2.3.1. It is here where the systems engineer, system designer, or system architect, (we will use the systems engineer designation in this chapter) has to get input from the customer and other stakeholders. Depending on the type of industry, organization, and product, this means:
• Direct contact with the customer through interviews and/or customer visits
• Market research through interviews with experts and observation [Eger et al., 2013];
• Acquiring input from the marketing department
This input has to be reworked and balanced with other stakeholders’ require-§4.9: FunKey architecting
ments into a balanced set of key drivers [Heemels et al., 2006]. In parallel, the systems engineer has to be up to date with technology inside
and outside the organization and know what can be achieved by the engineers. Both have to be combined into an architecture: a set of representations (like
the ones treated in Chapter 4, but others may be needed) that describes the system to be designed, so that the engineers know what they have to do, and the customers and other stakeholders’ know what they can expect. In fact, the architecture is an interface between the engineering achievements and the stakeholders’ expectations, as shown in Figure 5.1 (such an interface was also described when introducing the key drivers in §4.9 and Figure 4.12). The architecture description should be a combination of functional, physical and quantified models, as already shown in the A3 architecture overviews (§4.10).
