-Mixed initiative interactions between humans and machines pose many challenges for requirements engineering (RE), especially in the broader context of sociotechnical systems (STSs), a topic that has been studied and debated since the 1950s. This paper builds on the work system perspective (WSP), which can be used to describe an STS's operation, structure, purpose, and context in substantial depth regardless of whether some of its subsystems include mixed initiative interactions. It uses the acronym MXN to refer to systems that contain such interactions. This paper explains how aspects of the WSP are useful for identifying requirements for STSs in general and for the much smaller set of STSs that include mixed initiative interactions, a topic emphasized by the CFP of RESOSY 2021, the First International Interdisciplinary Workshop on Requirements Engineering for Sociotechnical Systems.
Distinguishing between the traditional view of STS and
the view of STS in CFP is necessary to avoid confusion in this
paper. The CFP states that STSs are “systems that are built to
aid humans in specific human tasks” and STSs should be
addressed as “mixed initiative systems where the computer or
the human can take initiative, monitor events, decide what to
do next, and perform tasks.” That view of STS echoes
Licklider’s 1960 vision of “man-computer symbiosis” as “an
expected development in cooperative interaction between men
and electronic computers. It will involve very close coupling
between the human and the electronic members of the
partnership.” [
Goal and organization. This paper shows how a view of STS based on the WSP illuminates requirements-related issues that likely would be overlooked by focusing tightly on the CFP’s assumption that STSs are MXNs. A WSP-centric view of STSs and MXNs provides a richer basis for RE since STSs that contain MXNs also include other human activities.
This paper explains how the WSP provides a basis for RE for an STS and for an MXN that might serve as one of its subsystems. It expands on a brief summary of the WSP by highlighting specific WSP-related topics that are useful for analyzing MXNs, including portrayals and characteristics of WSs and WS elements, performance variables, facets of work, functions performed by subsystems, WS design principles, division of responsibilities for specific activities, interaction patterns, and different degrees of smartness in devices and systems. Failure to consider those topics in RE for an MXN or an STS containing an MXN is analogous to engineering a selfdriving car without consider the context of use, e.g., weather, inattentive human drivers, road conditions, obstacles, and interactions with vehicles that may or may not be self-driving.
The STS movement began in England in the 1950s. The
essence of the sociotechnical approach is described as follows
by Enid Mumford, a long-term leader in the STS movement
(see tribute [
After summarizing the development and application of
sociotechnical thinking, [
Part of the discussion of STS frequently assumes that an
STS can be divided into a technical system and a social system
(e.g., [
The WSP addresses that difficulty by treating a WS as a single integrated system, thus eliminating the separation between social and technical systems and covering both STSs with human participants and totally automated systems. Its explicit attention to WS participants and their characteristics and concerns recognizes humanistic values instead of focusing primarily on technical specifications.
The WSP has evolved over many years. Its development
started with an attempt to create a systems analysis method for
business professionals, which was articulated as the work
system method (WSM) [
Definition of work. The WSP assumes that work is the application of human, informational, physical, and other resources to produce product/services for internal or external customers (or for oneself). Work can occur in businesses, governments, homes, and other situations where resources are used purposefully to produce outcomes.
Definition of WS. A work system is a system in which
human participants and/or machines perform work (processes
and activities) using information, technology, and other
resources to produce specific product/services for internal
and/or external customers (or for themselves) [
Special cases. The most important distinction in describing special cases of WS is the difference between a sociotechnical WS in which human participants perform some of the activities vs. totally automated WS where all activities are performed by machines. That distinction says that a MXN is a type of STS regardless of whether it is an IS or is a system devoted to physical activities.
An IS is a WS most of whose activities are devoted to
capturing, transmitting, storing, retrieving, deleting,
manipulating, and/or displaying information. This definition
differs from 20 previous definitions in [
Projects, service systems, self-service systems, and some supply chains (interorganizational WSs) are other important special cases. For example, software development projects and other projects are WSs designed to produce specific product/services and then go out of existence. Thus, a project that creates or improves a MXN is a WS on its own right.
Consistent with other ideas in the WSP, MXNs can be viewed as a highly restricted special case of WSs. The fact that a WS contains a MXN subsystem does not imply that the WS itself should be viewed as a MXN (in the same way that a WS that uses IT typically should not be viewed as an IT system). MXNs may not be ISs because the humans and/or totally automated parts of an MXN may perform physical work.
Work system framework: a basic understanding of a WS. The nine elements of the WS framework (Fig. 1) are the elements of a basic understanding of a WS’s form, function, and environment during a period when it is stable enough to retain its identity even though incremental changes may occur, such as minor personnel substitutions or technology upgrades.
technologies are completely within the WS. Customers and product/services may be partially inside and partially outside because customers often participate in activities within a WS and because product/services take shape within a WS.
WS even though they have direct effects within a WS and may be affected by major changes in significant WSs.
The following clarifications are often useful: Customers refers to people or organizations that receive product/services produced by a WS. This includes internal and external customers. The term product/services is used to bypass controversies about special characteristics of products vs. services. The term processes and activities is used because the activities in some WSs are not structured as processes. Infrastructure refers to human, informational, and technical resources that are viewed as shared by multiple WSs instead of being associated primarily with one WS. An example of human infrastructure is an IT group that can be viewed as a resource used by multiple WSs. “Elements of the WS framework” will be abbreviated as “WS elements” even though the last three elements are viewed as outside of a WS and often are controlled elsewhere.
Work system life cycle model (WSLC): how WSs change over time. ISs and other WSs evolve through a combination of planned change through projects and unplanned change through adaptations and workarounds (Fig. 2). WSLC phases (initiation, development, implementation, operation and maintenance) may be performed in different ways. Typical activities and responsibilities (e.g., designing, debugging, training, etc.) associated with specific phases apply for waterfall, agile, prototyping, use of off-the-shelf applications, and shadow IT, even when several phases overlap or iterate.
Both planned and unplanned changes often affect multiple WS elements, not just technologies. The development phase creates or acquires and then tests software and other resources needed for implementation in the organization. The implementation phase involves much more than installation of software on computers. The WSLC’s four idealized phases (and related sub-phases) express a waterfall-like approach to identifying things that should happen as a WS evolves iteratively. Many WSLC topics remain valid when agile approaches are used for developing software, such as the importance of WS changes rather than just software development, evolution over time rather than one-time projects, the simultaneous importance of planned and unplanned change, and the relevance of key activities and responsibilities within each phase. The key activities and responsibilities remain even if the phases are partially merged and regardless of whether the WS uses homegrown software, commercial application software, or external platforms. For example, regardless of whether aspects of development and implementation are partly merged, it is still necessary to determine requirements (at an appropriate level of detail), acquire, produce, or fix software that is needed, test and debug software, decide how to implement WS changes, identify implementation problems, train WS participants, and so on.
Coverage of sociotechnical systems. The WSP covers all operational systems in organizations, including STSs that can be viewed as WSs and totally automated systems that can be viewed as WSs. Those systems include all ISs, projects, and other special cases of WS.
Thus, the WSP covers a much broader domain than the domain identified in the CFP for RESOSY2021. The CFP prioritizes “systems built to aid humans in specific human tasks” [in situations that involve] “mixed initiative … where the computer or the human can take initiative, monitor events, decide what to do next, and perform tasks.” The WSP covers those situations and many others. It covers “systems built to aid humans in specific human tasks” but it also covers systems that use automation to replace people who previously performed specific tasks and also systems that perform totally automated tasks that were never performed by people. The WSP covers systems with mixed initiative interactions of humans and computers, but also covers systems where responsibilities of humans and computers are structured to be completely separate.
A key issue that bears reiteration is the interpretation of the terms system and STS in regard to this discussion. Computer science papers often assume that systems are softwarecontrolled entities that operate on computers. In contrast, the WSP covers both sociotechnical WSs (where some of the work is done by humans) and totally automated WSs (where all of the work is automated). Many computer science techniques that focus specifically on software are more effective than the WSP for understanding nuances of software and software development. This paper’s emphasis lies elsewhere, i.e., in explaining how the WSP provides insights for RE for STSs in general and for MXN subsystems of STSs.
This section uses ideas from a 2021 ACM Tech Talk [
According to [
Below are brief descriptions of four WSs that could involve mixed initiative interactions between a person and an automated entity that will be called a robot even though it may or may not have a physical realization (e.g., as in robotic process automation). The sketches distinguish briefly between the main WS and an MXN. In all four cases, a realistic RE effort would need to cover the WS (the system in PEGS terms) within which the MXN exists as a subsystem. Failure to consider the larger WS would result in requirements that treat the MXN’s environment too narrowly to permit evaluation of its effectiveness for meeting WS goals.
An interactive tutor. The broad class of WSs that provide instruction may or may not include an MXN whose activities are controlled partly by a student and partly by a robot serving as an automated tutor. The extent of shared control can be described along a dimension that starts with the student merely answering questions from the robot. Highly interactive learning is more like a dialogue between the student and the robot. That dialogue is part of a larger WS that may involve other activities such as recording the student’s progress and understanding of specific items in the material to be learned, assignment of students to learning programs, monitoring the continuity of the student’s attention, and so on.
A customer service chatbot. The chatbot is part of a
larger WS of providing customer service. For example, a
presentation [
An imagined flight control system. The WS in this instance can be summarized as flying a small personal aircraft from a starting point to a destination. Activities in that WS include deciding on the flight plan, performing a safety check, taking off, flying to the destination, landing, and performing aircraft-related activities that occur after landing. A robotic component of an MXN could inform the pilot about problems related to weather along the flight plan. The pilot could ask the robot to estimate how much fuel will remain when the aircraft reaches its destination. Also, the pilot could ask the robot to suggest a modification of the flight plan if unexpected turbulence occurs. In effect, the robot would offload some of the activities normally performed by pilots and, perhaps, air traffic controllers.
An imagined RE assistant. RE can be viewed as a type of WS in which analysts perform activities directed at producing requirements. Applying the definition of WS, RE is a system (a WS in its own right) in which human participants and/or machines perform processes and activities using information, technology, and other resources to produce specific product/services for internal and/or external customers. By that definition, some future type of RE might be partly or totally automated. The requirements are product/services that are produced, and the customers are people or organizations that receive and use the requirements.
Assume (quite optimistically) that knowledge about RE is sufficiently codified that an MXN subsystem of a WS for RE could include a robot that monitors the current state of a structured requirements document. The robot could ask human analysts questions such as whether noncompliance via human agency has been considered or whether past workarounds have indicated areas where the target WS needs to be improved. Conversely, the analyst could ask the robot to examine the current state of the requirements document and to apply codified knowledge about specific aspects of RE to identify issues such as whether serious conflicts exist between different user stories.
V. ASPECTS OF THE WORK SYSTEM PERSPECTIVE THAT ARE PERTINENT TO REQUIREMENTS ENGINEERING FOR MXNS Topics within the WSP build outward from the definition of WS and include the main ideas in WST, the application of those ideas in WSM, and a series of extensions related to design principles, service systems (in a business sense), workarounds, WS interactions, and other topics. Covering the entire WSP would require a book-length discussion. Since that is not practical for current purposes, this section emphasizes WSP topics that are relevant to all WSs but are especially relevant to MXNs. Those topics include portrayals and characteristics of WSs and WS elements, performance variables for WSs and WS elements, facets of WSs and WS elements, functions performed by WS subsystems, WS design principles, division of responsibilities for specific activities, interaction patterns, and different degrees of smartness in devices and systems.
Portrayals of WSs are alternative concepts for visualizing the entirety of a WS or WS element. (See Fig. 3.) The following list identifies alternative portrayals that are relevant to many WSs. For each portrayal, the list includes a question or issue that could be relevant to RE for a specific MXN.
Product/services might be portrayed as outputs that are delivered vs. as results of extensive collaboration. What identifiable product/services does this MXN produce? Processes might be portrayed as idealizations of how work should be done vs. as descriptions of how work is executed. How does RE for this MXN consider the possibility of noncompliance with specifications? Participants might be portrayed as WS components that follow specifications or as people with human needs and interests. To what extent are both portrayals used in RE for this MXN?
In the WSP, characteristics are properties used for describing or analyzing WSs, WS elements, or other resources. As shown in Fig. 4, characteristics of a WS as a whole include scalability, flexibility, resilience, degree of centralization, and fragility. Characteristics of processes and activities include degree of structure, complexity, integration, and rhythm. Characteristics of information include precision, age, traceability, usability, and bias.
Key characteristics for WSs as a whole (the top of Fig. 4) are also important for MXNs, especially where RE issues related to the level of scalability, flexibility, resilience, capacity, and agility for an entire WS may have direct impacts on RE for a MXN within the WS.
Other characteristics in Fig. 4 also have direct implications
for MXNs. A high degree of structure in a MXN’s processes
and activities implies that interactions between humans and
machines are largely about following scripts, whereas a less
structured MXN would allow much less scripted interactions
that could require a semblance of smartness or intelligence
[
Performance variables in the WSP (Fig. 5) are concepts used for describing or analyzing how well entities or their constituents operate. Required levels of performance variables would be viewed as “non-functional requirements” in the world of software.
Errors and delays in other parts of the WS that an MXN serves will likely affect the operation of the MXN. Thus, metrics related to a MXN’s performance at specific times often might depend on the state and operation of other parts of the WS in which the MXN exists. For example, downtime or errors in processes that provide inputs to the MXN could cause the MXN to operate more slowly or to stop operating at all, which likely would affect the metrics for the MXN and its human participants during that period. Other important performance variables that might be overlooked during RE involve job performance and job satisfaction of participants in an MXN. For example, participating in the MXN could lead to better or worse job performance and job satisfaction.
Facets of entities are alternative faces or aspects of an entity that can be observed or analyzed. The idea of “facet” is like a facet of a cut diamond. It is not a separate component of the diamond, but rather a face or aspect that can be observed or analyzed. Fig. 6 identifies facets of WSs as a whole and of each WS element.
The most useful set of facets for MXN-related RE is the
18 “facets of work” that can be viewed as facets of the
processes and activities in a WS (see Fig. 6). Those facets
apply to both sociotechnical and totally automated systems,
are associated with specific concepts, brings evaluation
criteria and design trade-offs, have sub-facets, and bring
openended questions for starting conversations [
The central contribution of facets of work for RE related
to MXNs is that the facets of work provide a way to be specific
about requirements for many specific types of capabilities that
otherwise might have been overlooked. For example, consider
the facets learning, planning, improvising, and maintaining
security. Having a list of facets makes it less likely that those
topics will be overlooked in RE related to MXNs and to WSs
in general. Linkage of each element of that list to some version
of associated concepts, evaluation criteria, design trade-offs,
sub-facets, and open-ended questions identified in [
The following list identifies a variety of functions that might be performed through interactions between a human participant and a robot within an MXN. This list was first imagined in relation to functions that an IS might perform to support a WS, with the assumption that the list might be expanded through a structured analysis of IS case studies. providing access to information, defining and enforcing rules for collecting or sharing information, providing methods for aggregating information, providing methods for analyzing information, controlling activity sequences in workflows, enforcing compliance with business rules, creating alarms when predefined conditions occur, controlling or facilitating coordination, suggesting decisions, triggering automated functions,
performing totally automated tasks autonomously.
This list shows that RE for an MXN (or other WS) could be supported by a list of common functions even though it says nothing about whether the person performs those functions for the robot or vice versa. Many other functions might be included. As with the facets of work, this type of list could help analysts make sure they have considered a range of common possibilities. More broadly, some version of a list of functions potentially helps in realizing that RE for a MXN should be specific about functions being performed regardless of whether they are initiated by either a human or a robot.
Design principles are statements that express desired properties of designed entities within a domain. Design principles may apply to all WSs within a domain, to specific types of WS within the domain, and/or to WSs associated with a community of practice.
Fig. 7 uses the format of a “work system snapshot,” a basic
tool from the WSM, to organize 24 design principles related
to sociotechnical WSs. Each design principle could be stated
more elaborately, more like a fully specified software design
pattern that is viewed as a reusable solution to a commonly
occurring problem (e.g., [
Many of the design principles in Fig. 7 (or other design principles that have been proposed) could be applied during RE for MXNs. For example, the design principles in the part of Fig. 7 for processes and activities includes design principles related to variability, efficiency, judgment, problem control, quality control, boundaries between steps, and the match between work practices and participants. All of those ideas could be explored as part of an RE effort focused on an MXN.
An important design question for MXNs is the division of responsibilities, i.e., the extent to which the person or the machine is responsible for each activity in a MXN subsystem. RE for a MXN would be superficial if it did not deal with that question either in a general way or by being explicit about whether a human or a machine is responsible for initiating each activity, for monitoring each activity, for declaring an activity complete, and for transitioning to other activities.
A WSM tool called a service responsibility table (SRT)
[
Interactions between WSs include unidirectional, mutual,
or reciprocal actions, effects, relationships, influences, or
interplay between two or more WSs. Systems theorists such
as Ackoff [
The idea of interaction patterns can be used when thinking
about the requirements for capabilities within an MXN.
Preliminary research [
One-way patterns are unidirectional interactions that have been studied in relation to the language action perspective (LAP). Patterns within this category are inform, command, request, commit, and refuse. All of those patterns involve unidirectional interactions.
Coproduction patterns are bilateral patterns involving
jointly produced interactions whose instantiations can be
observed as sequences of unidirectional interactions, some of
which may be described as speech acts. Coproduction patterns
include converse, negotiate, mediate, share resource, and
supply resource. The first three are fundamentally about
bilateral speech situations, whereas the other two are
fundamentally about coordination as described by
coordination theory [
Access and visibility patterns are unidirectional patterns concerning one entity obtaining access or visibility related to another entity and about countermeasures to prevent access and visibility. These patterns include monitor, hide, protect, and attack. The first of these involves a typical management activity. The next two involve defensive maneuvers. The last pattern represents a threat.
Unintentional impact patterns are the least articulated patterns because of the great uncertainty about the sources and effects of many unintentional impacts. Examples include overlap, market-based, spillover, indirect, and accidental interactions. While it may not be possible to anticipate those impacts, ignoring the possibility that they will occur is certainly not a beneficial RE practice.
While the ideas in [
Finally, RE related to MXNs might consider ideas about
the smartness of devices and systems since the notion of MXN
tends to imply some degree of smartness in a computerized
device. An approach to smartness of devices and systems is
explained in [
communication, control, physical action. Internal regulation. Self-detection, self-monitoring, self-diagnosis, self-correction, self-organization.
As noted in [
Scripted execution. Performs capability-related activities according to prespecified instructions.
Unscripted or partially scripted invention. Invention of capability-related activities using unscripted or partially scripted execution of a workaround or new method.
This paper started by noting that the CFP of RESOSY 2021 characterizes STSs as “systems that are built to aid humans in specific human tasks” that should be addressed as “mixed initiative systems where the computer or the human can take initiative, monitor events, decide what to do next, and perform tasks.” That characterization is much more restricted than typical characterizations of STS that researchers and practitioners have used for decades. The acronym MXN (mixed initiative system) was used to pursue the CFP’s focus without causing confusion about different views of STS.
This paper’s contribution used aspects of the WSP to identify many topics that should be considered in RE related to WSs in general and MXNs in particular. It summarized the main ideas in the WSP and then focused on aspects of the WSP that are especially relevant to RE for MXNs. Those aspects of the WSP include portrayals and characteristics of WSs and WS elements, performance variables, facets of work, functions performed by subsystems, WS design principles, division of responsibilities, interaction patterns, and the characterization of smartness in devices and systems.
This paper illustrated the idea of MXNs by using four examples, but did not propose MXN requirements for those examples. Doing so would have required a detailed discussion of those situations including description of the WSs in which the MXN examples exist.
One of this paper’s important limitations is its focus on a specific set of ideas related to the WSP, aspects of which have been presented in many papers on a range of topics. This paper’s highly condensed presentation of many ideas outlines an integrated approach to addressing many RE issues related to STSs and MXNs, but it also leaves many questions that can only be answered through much more extensive discussion of specific WSP concepts and assumptions underlying the WSP.
This paper necessarily omitted many ideas that could not
fit in a short paper. Other researchers surely would approach
topics related to MXNs from other viewpoints such as agentic
artifacts [
The next step in extending this paper’s ideas is to validate their usefulness by applying those ideas to specific RE projects that focus on WSs that contain MXNs or might contain MXNs in the future. Careful evaluation of documents produced in those projects plus interviews of project participants would probably help in describing the extent to which specific WSP ideas in this paper provide insights or simply seem consistent or inconsistent with existing practices from previous projects.
Mixed initiative systems have many potential applications that go far beyond current practice. Research about whether existing RE techniques need to be extended for such situations is potentially quite valuable. The WSP-centric ideas presented in this paper could be a step forward in that research.