Integrating HCI Engineering and Software Engineering: A Call to a Larger Vision

by Elizabeth A. Buie and Antonio Vallone, Computer Sciences Corporation

Presented at HCI '97, August 1997
Copyright © 1997, Computer Sciences Corporation (CSC). Used by permission.

Citation: Buie, E., A., & Vallone, A. (1997). Integrating HCI engineering with software engineering: A call to a larger vision. In Smith, M. J., Salvendy, G., & Koubek, R. J. (Eds.), Design of Computing Systems: Social and Ergonomic Considerations (Proceedings of the Seventh International Conference on Human-Computer Interaction), Volume 2. Amsterdam, the Netherlands: Elsevier Science Publishers, 1997, pp. 525-530.

---

In this paper we discuss the issue currently plaguing the HCI community about its relationship with software engineering and how to integrate the two. We encourage both disciplines to take a larger view, and we present system engineering as a structure for achieving such an integration.

The integration issue

Interaction with human beings is increasingly recognized and promoted as an important aspect of software systems and products. More and more professionals in the computing industry (e.g., Curtis and Hefley, 1994; Kapor, 1996) call for integrating human-computer interaction (HCI) engineering with software engineering. A seminar and panel discussion at the 1994 Annual Meeting of the Human Factors and Ergonomics Society (Hefley, et al., 1994) explored some ideas on integration. Some proposed solutions would integrate HCI engineering into software engineering; others would have HCI as the dominant player.

But just what is the relationship between HCI and software? How do they interact as fields of endeavor? As players in development? Recent conferences and publications indicate that this is a major issue for the HCI community.

Example: In his keynote address to the second annual National Institute of Standards and Technology (NIST) Symposium on Usability Engineering in Government Systems, Software Engineering Institute (SEI) director Steve Cross (1997) noted that "The user is a component of the system" and remarked that the software engineering process must incorporate usability engineering. From the audience, Cognetics Corporation president Charlie Kreitzberg expressed the complementary view, asserting that it is software engineering that should be a component of usability engineering.

Example: CHI’97 panelists Terry Winograd and Jim Faris contended that HCI should be moved from the field of computer science to that of design, arguing that software engineers have a "constructor’s-eye view" that fails to consider the bigger picture. Wendy Kellogg and Paul Dourish argued that this "solution" would continue to view HCI too narrowly (from design instead of software) and would address the symptom rather than the cause.

Example: Within the last two years, at least three new books (Newman and Lamming, 1995; Tognazzini, 1996; Winograd, 1996) have addressed this very topic.

Agreement continues to elude the HCI community. In this paper we argue that this conflict and competition are unnecessary and unproductive. Furthermore, we submit that the treatment of this issue as an either/or condition – as a competition – misses the point.

We fully agree that HCI and software engineering need to be better integrated. Such an integration is essential to the cost-effective development of highly usable software systems and products. We do not agree, however, that it is appropriate to integrate either of these disciplines or processes into the other. Our thesis is this: The fields of HCI and software must interact and collaborate under a larger perspective that encompasses both. Each must develop a larger vision.

Building a larger vision

Depending on the organization and development environment, the perspectives of such disciplines as system engineering, product engineering, industrial engineering, and perhaps even industrial design can provide this larger vision. In this paper we use system engineering as a paradigm for this perspective, because that is the term used in the environment in which we ourselves work (development of large systems under contract to specific clients). It should be clear, however, that when we say "system engineering," we mean "system engineering, product engineering, industrial engineering, or maybe even industrial design" – whichever is appropriate for an organization.

We want to make it clear also that by "engineering" we mean specification, design, and technical oversight of the implementation process. Although some (e.g., Winograd, 1996) argue that the word "engineering" means taking a design and building (or implementing) it, the inclusion of design within engineering appears in most treatments of software engineering throughout its history. According to Newman and Lamming (1996), engineering, like design, "is about creativity and innovation" (p. 10). Furthermore, in its Systems Engineering Capability Maturity Model (SEI, 1996), the SEI defines system engineering to include system design.

Integrating and coordinating HCI engineering and software engineering requires both disciplines to do a paradigm shift – to adopt a larger perspective. As a discipline, system engineering has considerable experience in integrating specific engineering disciplines – such as software, hardware, firmware, and data base engineering – in a coordinated system development process. Within this paradigm shift, the integration effort must start by answering three questions:

1. How are the disciplines distinct? What do HCI and software engineering do? What roles and responsibilities does each have in the system life cycle? Which is in charge of what?
2. How should they cooperate? How do they interact and communicate with each other? What information needs does each one have, and what information does each produce? How does the work of each affect the other?
3. What is the role of system engineering? How does the system engineering process integrate and coordinate the technical contributions of the distinct engineering disciplines?

The answers to these questions depend on the specific organization, the development environment, and the system or product being developed. In the rest of this paper, we consider these questions and provide a few answers from our experience of system engineering in our environment.

Distinctions

The fundamental difference between HCI engineering and software engineering is that they have separate problem domains. HCI engineering focuses on the tasks of people using the system or product, on the information and interactions that the users need to perform their tasks, on the environment in which they work. Software engineering focuses on the software capabilities needed for the system to perform its functions, accomplish its objectives, meet its requirements. Some of the software capabilities are also needed to support the users in performing their tasks and interacting with the system. Their disparate problem domains give these disciplines separate roles and responsibilities in the process of specifying, designing, and developing the system or product.

Unfortunately, calls for integration (e.g., Kapor, 1996; Winograd, 1996) often place HCI within software design or software engineering. Many of the activities involved in the development of interactive systems are often claimed by both software engineers and HCI engineers: The software industry tends to see HCI development as a software engineering activity that can improve software engineering practice, and the HCI community tends to see some aspects of software development as part of HCI engineering (e.g., Curtis & Hefley, 1994; Myers, 1994). Current tools tend to blur the distinction and exacerbate the problem: Many application development tools include HCI layout capabilities, and many interface design tools can automatically generate interface code. However, these two engineering disciplines must be kept distinct, so that each may maintain its own focus and priorities.

Figure 1 (at right, adapted from Curtis & Hefley, 1994, Figure 5, p. 31) lists the activities of HCI engineering and software engineering during system development and shows how they differ.

Our activities list differs from the Curtis and Hefley list in two ways. Curtis and Hefley assigned to HCI engineering the activity of allocating functions to humans and software; we designate it as a system engineering responsibility because it requires a larger view than that of either HCI or software. They assigned to HCI engineering the activity of coding the HCI software; we assign it to software engineering because coding belongs to the software engineering problem domain.

HCI and software engineering must cooperate and communicate, but they are as processes distinct, having very different (and sometimes conflicting) issues and concerns. It takes a larger view, such as provided by system engineering, to revolve the issues.

Cooperation

The HCI and software engineering processes closely cooperate during the design and implementation of interactive systems and products. Figure 2 illustrates the interactions and information exchanges between the processes as they relate to HCI development.

The diagram in the figure indicates that HCI engineering and software engineering are separate but interact very closely. Not only do they exchange information, but each reviews and validates the other’s products to ensure both usability and feasibility.

The HCI engineering process receives input from the definition of the users’ needs with respect to the system/product capabilities. This includes a description of user’s environment, a definition of human-performed and automated activities and information from other relevant sources such as marketing. The HCI process identifies the HCI and usability requirements, designs the interaction, and validates requirements and design by means of initial usability assessment using prototypes. The HCI engineering product that is of interest to software engineering is software requirements*, i.e., the software capabilities and characteristics needed implement the HCI design.

The software engineering process merges the HCI related software requirements with the requirements pertaining to the other parts of the software product, such as computational and information retrieval capabilities, and develops the software to meet the merged requirements. This development may in turn generate additional HCI requirements, which HCI engineering then incorporates into the HCI design. For example, the software development process identifies needs for further interactions with the user, such as specific software-related online help and error messages. Software engineering also imposes constraints on the HCI design, often related to technological limitations and feasibility but also due to delivery schedules and total budget.

Separation and collaboration may sometimes fail. For example, the use of human interface tools that do automatic code generation (e.g., Builder Xcessory) may give the HCI engineer the impression of performing a software engineering role; conversely, the use of application program tools that generate forms and windows (e.g., Visual Basic) may give the software engineer the impression of performing an HCI engineering role. Also, the interaction between the disciplines may create issues and conflicts, as their priorities collide.

In our opinion, the strong interaction between these disciplines and the need to resolve their conflicts are major reasons why each discipline attempts to absorb the other. We contend that such attempts are neither necessary nor advantageous, because neither discipline has a large enough view to accomplish the other’s objectives. It is system engineering’s role and responsibility to optimize the overall system design and thus to identify acceptable tradeoffs and resolve the issues.

The framework of system engineering

According to the Systems Engineering Capability Maturity Model (SE-CMM) developed by the SEI, system engineering aims to "integrate the efforts of all engineering disciplines and specialties into the total engineering effort" (SEI, 1996, p. A-8). Some organizations define a system engineering process that explicitly provides for the separate processes of HCI and software engineering (e.g., Computer Sciences Corporation, 1990).

System engineering can be considered the keeper of the system view, always working to ensure that the system or product meets its overall requirements. System engineering has responsibility for several primary activities:

• Definition of system and operation concepts
• Specification of detailed system requirements
• Requirements allocation and definition of system architecture and design
• Technical oversight of all engineering contributions to system/product implementation
• Technical oversight of testing and verification at the system level
• Technical tradeoff decisionmaking

These system engineering responsibilities provide the framework for the effective integration of HCI and software engineering. The specific integration appropriate for an organization and development environment will depend on a definition of when and how the interactions between HCI engineering and software engineering occur and how issues and conflicts are resolved. This definition should include

• Clear boundaries around HCI and software engineering processes (e.g., responsibilities, inputs, outputs)
• Sources of inputs and destinations of outputs to all participants in design and development
• Specification of the information exchange between activities of the engineering processes
• Process for setting decision criteria (e.g., for tradeoff analyses, usability objectives)

A major contribution of HCI and software engineering to system engineering involves providing their own perspectives to the allocation of system capabilities to humans and software**. HCI participates in the discovery of user needs, tasks, and workloads, and in the decisions about whether or not to allocate a function to a person. Software engineering participates in the evaluation of the feasibility of proposed automation of human activities and in the decisions about whether or not to allocate functions to software. System engineering uses these analyses to develop a system design from tradeoffs of schedule, cost, and the overall benefits that the system/product will provide to its users and to the organization.

Improving the integration framework

We fully recognize that system engineering is not perfect. The specific processes that system engineering tends to mandate for the HCI often may fail to support effective collaboration with software engineering, and they may not provide the most efficient means of achieving usability in interactive systems and products. System engineers need to acquire as deep an understanding of HCI engineering as they tend to have about the other engineering disciplines whose contributions they coordinate. Developing such an understanding will require the collaboration of specialists in system engineering, HCI engineering, and software engineering (Buie & Vallone, 1995).

References

• Buie, E. & Vallone, A. (1995). Human-system interaction development: An integral part of the systems engineering process. Proceedings of the Fifth Annual International Symposium of the National Council on Systems Engineering (NCOSE ‘95). St. Louis. MO: July, 1995, 927-930.
• Computer Sciences Corporation (1990). Digital system development methodology (DSDM™). Falls Church, VA: Computer Sciences Corporation.
• Cross, S. E. (1997). Towards user-centered software engineering. Proceedings of Usability Engineering 2: Measurement and Methods (UE2). Gaithersburg, MD, March, 1997, tbd pages.
• Curtis, B., & Hefley, B. (1994). A WIMP no more: The maturing of user interface engineering. interactions 1:1, 22-34.
• Dourish, P., Faris, J., Kellogg, W., & Winograd, T., (1997). Panel: Design v. computing: Debating the future of human-computer interaction (Salvador, T., & Boyarski, D., Organizers). Human Factors in Computing Systems: CHI’97 Extended Abstracts. Atlanta, GA, March, 1997, 99-100.
• Hefley, W., Lynch, E., Buie, E., Muller, M., Hoecker, D., Carter, J., & Roth, J. T. (1994). "Integrating Human Factors with Software Engineering Practices". In Proceedings of the Human Factors and Ergonomics Society 38th Annual Meeting, 1994, pp. 315-319. Republished in G. Perlman, G. K. Green, & M. S. Wogalter (Eds.) Human Factors Perspectives on Human-Computer Interaction: Selections from Proceedings of Human Factors and Ergonomics Society Annual Meetings, 1983-1994. Santa Monica, CA: HFES,
• Kapor, M. (1996). A software design manifesto. In Winograd, T., (ed.), Bringing design to software. Reading, MA: Addison-Wesley. Originally presented to Esther Dyson’s PC Forum in 1990.
• Myers, B. A. (1994). Challenges of HCI design and implementation. interactions, 1:1, 73-83.
• Newman, W. M., & Lamming, M. G. (1995). Interactive system design. Workingham, UK: Addison-Wesley.
• Software Engineering Institute (SEI) (1996). Handbook SECMM-94-06, CMU/SEI-96-HB-004, A description of the systems engineering capability maturity model appraisal method, version 1.1. Pittsburgh, PA.
• Tognazzini, B. (1996). Tog on software design. Reading, MA: Addison-Wesley.
• Winograd, T. (ed.) (1996). Bringing design to software. Reading, MA: Addison-Wesley.

Back to the top of this page

---

Copyright © 1997, Computer Sciences Corporation (CSC). Used by permission.