The Case Study: Systems Engineering for HOLIS

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.

• HOLIS will need to support "soft" key switches ”individually programmable key switches used to activate the lighting features in various rooms.

• Homeowners have requested a means to program HOLIS from a remote center so they can simply call in their needs and not be bothered with "programming" HOLIS at all.

• Other prospective buyers have requested that HOLIS be programmable from their home PCs and that they be provided with the ability to do all the installation, programming, and maintenance themselves .

• Still others have requested that the system provide a simple, push-button, control panel “type interface they can use to change HOLIS programming, vacation settings, and so on, without having to use a PC.

• HOLIS needs to provide an emergency-contact system of some kind.

Problem Analysis

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

Element	Description
The problem of . . .	Slowing growth in the company's core professional theater marketplaces .
Affects . . .	The company, its employees , and its shareholders.
And results in . . .	Unacceptable business performance and lack of substantive opportunities for growth in revenue and profitability.
Benefits of a solution . . .	Involving new products and a potential new marketplace for the company's products and services include Revitalization of the company and its employees Increased loyalty and retention of the company's distributors Higher revenue growth and profitability Upturn in the company's stock price

Table 7-2. Problem Statement for the Homeowner

Element	Description
The problem of . . .	The lack of product choices, limited functionality, and the high cost of existing home lighting automation systems.
Affects . . .	The homeowners of high-end residential systems.
And results in . . .	Unacceptable performance of the purchased systems or, more often than not, a decision not to automate.
Benefits of a solution . . .	That comprised the "right" lighting automation solution could include Higher homeowner satisfaction and pride of ownership Increased flexibility and usability of the residence Improved safety, comfort , and convenience

Table 7-3. Problem Statement for the Distributor

Element	Description
The problem of . . .	The lack of product choices, limited functionality, and the high cost of existing home lighting automation systems.
Affects . . .	The distributors and builders of high-end residential systems.
And results in . . .	Few opportunities for marketplace differentiation and no new opportunities for higher-margin products.
Benefits of a solution . . .	That comprised the "right" lighting automation solution could include Differentiation Higher revenues and higher profitability Increased market share

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).

1. The homeowner who uses HOLIS to control the lighting

2. The various lights that HOLIS, in turn , controls

3. Lumenations Services, the manufacturer that has the ability to remotely dial HOLIS and perform the remote programming

4. Emergency Receiver, an undefined actor who will likely receive emergency messages

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

Stakeholder	Comments
External Distributors	Lumenations' direct customer
Builders	Lumenations' customer's customer: the general contractor responsible to the homeowner for the end result
Electrical contractors	Responsible for installation and support
Internal Development team	Lumenations' team
Marketing/product management	Will be represented by Alyssa, product manager
Lumenations' general management	Funding and outcome accountability

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.

• It would be good if we could have common software within both the controller device and the homeowner's PC; we'll pick a PC-based implementation for both elements of the system.

• We're not yet certain what flexibility we are going to need in the remote softkey switches, but it's clear that there will be many of them, that some of them will be a fair distance from the main control unit, and that we'll probably need some intelligent communication between those and the control unit.

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

ID #	Description	Rationale
1	Version 1.0 will be released to manufacturing by January 5.	This is the only product launch opportunity this year.
2	The team will adopt UML modeling, OO-based methodologies, and the Unified Software Development Process.	We believe these technologies will provide increased productivity and more robust systems.
3	The software for the Central Control Unit and PC Programmer will be written in Java. Assembly language will be used for the Control Switch.	These choices provide consistency and maintainability; also, the team knows these languages.
4	A prototype system must be displayed at the December Home Automation trade show.	We want to take distributors' orders for the first quarter of the fiscal year.
5	The microprocessor subsystem for the Central Control Unit will be copied from the professional division's advanced lighting system project (ALSP).	We can use an existing design and an inventoried part.
6	The only PC Programmer configuration supported will be compatible with Windows 2000 and Windows XP.	This way we can better manage the scope for release 1.0.
7	The team will be allowed to hire two new full-time employees, after a successful inception phase, with whatever skill set is determined to be necessary.	The maximum allowable budget expansion limits us to two new hires.
8	The KCH5444 single-chip microprocessor will be used in the Control Switch.	The company already uses this microprocessor.
9	Purchased software components will be permitted as long as there is no continuing royalty obligation to the company.	We want to avoid any long- term cost of goods sold impact for software.