So much for a brief introduction to systems engineering. Now let's try to apply what we have learned to HOLIS, our HOme LIghting automation System. At this point, we haven't spent much time trying to understand the requirements for HOLIS. We'll do that in later chapters of the book. So, in a sense, systems engineering is premature. On the other hand, we probably understand enough to make some first-level system design decisions, based on our experience and our understanding of likely requirements. In any case, we haven't committed anything to hardware or software yet, and we can revisit these decisions later. In addition, in the iterative process described in Chapter 3 we were forewarned that we'll visit systems architecture and system requirements interactively, so this is not a bad time to begin.
Preliminary User Needs
Let's assume that a few reasonably well- understood user needs have already been defined for HOLIS.
In analyzing the problem, the team discovered that there were actually three different groups of stakeholders, each of whom saw the problem differently. The team decided to develop three problem statements, the first of which seemed to state the obvious problem from the company's perspective (Table 7-1).
Next , the team also decided to see whether it could understand the "problem" from the perspectives of a future customer (end user) and potential distributors /builders (Lumenations' customers). The team developed the problem statements shown in Tables 7-2 and 7-3, respectively.
Table 7-1. Problem Statement for Lumenations
Table 7-2. Problem Statement for the Homeowner
Table 7-3. Problem Statement for the Distributor
HOLIS: The System, Actors, and Stakeholders
From a systems perspective, our first impression of the HOLIS system is simply that of a system inside the homeowner's house. Figure 7-5 is a simple systems diagram showing HOLIS in the context of the homeowner's home.
Figure 7-5. System context: HOLIS in its environment
Step 3 of problem analysis requires that we identify the stakeholders and users of the system . Step 4 is to define the system boundary of the solution system . Given the additional user needs data we have just been given, we can now improve our understanding of HOLIS's system context by identifying the four actors that will interact with HOLIS (Figure 7-6).
Figure 7-6. HOLIS with actors
Of course, the team also discovers that a number of "nonactor" stakeholders , both internal and external to the company, care about the requirements for HOLIS, as Table 7-4 shows.
Table 7-4. Nonactor Stakeholders for HOLIS
HOLIS Systems Engineering
Now that we understand the external actors for HOLIS, let's do some systems-level thinking to consider how we might partition HOLIS into subsystems.
This process could well be driven by the following kinds of systems engineering thinking.
With this minimalist thinking, we can come up with a new system perspective, one in which HOLIS, the system, is composed of three subsystems: Control Switch , the programmable remote switching device; Central Control Unit , the central computer control system; and PC Programmer , the optional PC system that some homeowners have requested. Now the block diagram appears as in Figure 7-7.
Figure 7-7. HOLIS with subsystems and actors
Note that we have identified a fifth actor ”the homeowner again ”but this time as an actor using the PC to program HOLIS rather than as an actor turning lights on and off. The latter actor is now called Resident to differentiate the two roles of the homeowner. The new Homeowner/Programmer actor has different needs for the system in that role and therefore is a separate actor to the system. We'll look again later to see the various behaviors that this actor will expect of HOLIS.
The Subsystems of HOLIS
From a systems engineering and requirements perspective, the problem becomes a little more complex. In addition to needing to understand the requirements for HOLIS, the system, we'll now also need to understand the unique requirements for each of HOLIS's three subsystems. We can use our actor paradigm again, at the next level of system decomposition. In so doing, we come up with three new block diagrams: Figures 7-8, 7-9, and 7-10.
Figure 7-8. Control Switch subsystem with actors
Figure 7-9. PC Programmer subsystem with actors
Figure 7-10. Central Control Unit subsystem with actors
In Figure 7-8, when we look at the system perspective from the Control Switch standpoint, we find yet another actor: Central Control Unit (CCU), another subsystem. In other words, from a subsystem perspective, CCU is an actor on Control Switch , and later we'll need to understand what kinds of requirements and use cases CCU will impose on Control Switch. This set of requirements is derived from our system decomposition.
In Figure 7-9, the systems perspective from the viewpoint of the homeowner's PC, we don't seem to learn anything new, at least in terms of actors and subsystems; they've all been identified before. Figure 7-10, however, presents a slightly richer view, and we see that CCU has more actors than anyone else. This seems to make intuitive sense since we have started thinking about CCU as the brains of HOLIS, so it makes sense to think that it has the most stuff to do and the most actors to do it for.
To complete the problem analysis, look at Table 7-5, which itemizes the constraints that the team identified, discussed, and agreed to between the HOLIS development team and Lumenations management.
That's enough problem analysis and systems engineering on HOLIS for now. We'll revisit the case study in subsequent chapters.
Table 7-5. Constraints for the HOLIS project