=Paper=
{{Paper
|id=Vol-3107/paper1
|storemode=property
|title=Requirements engineering for sociotechnical systems that may include mixed initiative interactions between humans and machines
|pdfUrl=https://ceur-ws.org/Vol-3107/paper1.pdf
|volume=Vol-3107
|authors=Steven Alter
|dblpUrl=https://dblp.org/rec/conf/apsec/Alter21
}}
==Requirements engineering for sociotechnical systems that may include mixed initiative interactions between humans and machines==
https://ceur-ws.org/Vol-3107/paper1.pdf
Requirements Engineering for Sociotechnical
Systems that May Include Mixed Initiative
Interactions between Humans and Machines
Steven Alter
School of Management
University of San Francisco
San Francisco, USA
alter@usfca.edu
Abstract—Mixed initiative interactions between humans and view of STSs and MXNs provides a richer basis for RE since
machines pose many challenges for requirements engineering STSs that contain MXNs also include other human activities.
(RE), especially in the broader context of sociotechnical systems
(STSs), a topic that has been studied and debated since the This paper explains how the WSP provides a basis for RE
1950s. This paper builds on the work system perspective (WSP), for an STS and for an MXN that might serve as one of its
which can be used to describe an STS’s operation, structure, subsystems. It expands on a brief summary of the WSP by
purpose, and context in substantial depth regardless of whether highlighting specific WSP-related topics that are useful for
some of its subsystems include mixed initiative interactions. It analyzing MXNs, including portrayals and characteristics of
uses the acronym MXN to refer to systems that contain such WSs and WS elements, performance variables, facets of work,
interactions. This paper explains how aspects of the WSP are functions performed by subsystems, WS design principles,
useful for identifying requirements for STSs in general and for division of responsibilities for specific activities, interaction
the much smaller set of STSs that include mixed initiative patterns, and different degrees of smartness in devices and
interactions, a topic emphasized by the CFP of RESOSY 2021, systems. Failure to consider those topics in RE for an MXN or
the First International Interdisciplinary Workshop on an STS containing an MXN is analogous to engineering a self-
Requirements Engineering for Sociotechnical Systems. driving car without consider the context of use, e.g., weather,
inattentive human drivers, road conditions, obstacles, and
Keywords—sociotechnical system, mixed initiative
interactions with vehicles that may or may not be self-driving.
interaction, work system, work system perspective
II. BACKGROUND ABOUT SOCIOTECHNICAL SYSTEMS
I. BUILDING ON A TRADITIONAL VIEW OF STS
The STS movement began in England in the 1950s. The
Practices and thinking associated with STSs have been essence of the sociotechnical approach is described as follows
applied, debated, and expanded since the 1950s. Traditional by Enid Mumford, a long-term leader in the STS movement
views of STS involve systems whose human participants use (see tribute [4]): “Throughout its history, practitioners have
technologies for their activities. A 1977 article in the first always tried to achieve its two most important values: the need
volume of MIS Quarterly (over four decades ago) viewed an to humanize work through the redesign of jobs and democracy
STS as a combination of separable technical and social at work. In order to realize these goals, the objective of socio-
systems [1]. The title of a 2019 MIS Quarterly article [2] technical design has always been ‘the joint optimization of the
referred to the “sociotechnical axis of cohesion of the IS social and technical systems’. Human needs must not be
discipline.” Those articles use a longstanding concept of STS forgotten when technical systems are introduced. The social
that is much broader than the MXN subsystems that the and the technical should, whenever possible, be given equal
RESOSY 2021 CFP denotes as STSs. weight.”[5, p. 321] … “The most important thing that socio-
Distinguishing between the traditional view of STS and technical design can contribute is its value system.” … “This
the view of STS in CFP is necessary to avoid confusion in this tells us that although technology and organizational structures
paper. The CFP states that STSs are “systems that are built to may change, the rights and needs of the employee must be
aid humans in specific human tasks” and STSs should be given as high a priority as those of the non-human parts of the
addressed as “mixed initiative systems where the computer or system.” [5, p. 338]
the human can take initiative, monitor events, decide what to After summarizing the development and application of
do next, and perform tasks.” That view of STS echoes sociotechnical thinking, [5] expresses disappointment and
Licklider’s 1960 vision of “man-computer symbiosis” as “an doubts about its limited influence in the world of 2006, the
expected development in cooperative interaction between men year when Mumford died. One explanation is that the
and electronic computers. It will involve very close coupling underlying ideas of STS have spread to so many different
between the human and the electronic members of the domains that it has become diluted to “a banner under which
partnership.” [3] In effect, STSs as characterized by the CFP many different concepts and design principles can flourish
are a relatively new type of subsystem of STSs that have been that have little relation to one another.” [6, p. 234]. For
imagined for many decades. This paper does not speculate example, [7] identifies four major variants on STS theory and
about the source of the CFP’s appropriation of the term STS. practice: North American STS, Australian STS, Scandinavian
Goal and organization. This paper shows how a view of STS, and Dutch STS. On the other hand, the diffusion of STS
STS based on the WSP illuminates requirements-related ideas over many decades could be viewed as a success. For
issues that likely would be overlooked by focusing tightly on example, [8, p. 9] notes that “the work design and processes
the CFP’s assumption that STSs are MXNs. A WSP-centric of both STS and flexible manufacturing have been
successfully integrated into most organizations today. It is
Copyright © 2022 by the author. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
difficult to find an organization that does not encourage team is a type of STS regardless of whether it is an IS or is a system
work, employee participation and decision making” even devoted to physical activities.
though “STS began to disappear both academically and in
practice in the late 80s early 90s.” An IS is a WS most of whose activities are devoted to
capturing, transmitting, storing, retrieving, deleting,
Part of the discussion of STS frequently assumes that an manipulating, and/or displaying information. This definition
STS can be divided into a technical system and a social system differs from 20 previous definitions in [12] and was one of 34
(e.g., [1, 5]). That approach has serious shortcomings for RE definitions of IS noted in [13]. It differs from assuming an IS
because the social and technical systems overlap [9]. Many is a tool that is “used” or that an IS exists to produce
processes in STSs are both social and technical because representations of real world systems [14]. An example is a
humans doing some of the work may not conform with sociotechnical accounting IS in which accountants decide how
specifications due to social issues. The information in an STS specific transactions and assets will be handled for tax
is both social and technical because it includes computerized purposes and then produce monthly or yearend financial
information and interactions between humans. Even statements. This is an IS because its activities are devoted to
technologies often have social aspects since many STS processing information. It is also supported by a totally
participants use their own computers, smartphones, and other automated IS that performs calculations and generates reports.
technologies whose selection is partly social in nature. In both cases, an IS that is an integral part of another WS
cannot be analyzed, designed, or improved thoughtfully
The WSP addresses that difficulty by treating a WS as a without considering how IS changes affect that WS. The same
single integrated system, thus eliminating the separation idea applies to MXNs that are subsystems of larger WSs.
between social and technical systems and covering both STSs
with human participants and totally automated systems. Its Projects, service systems, self-service systems, and some
explicit attention to WS participants and their characteristics supply chains (interorganizational WSs) are other important
and concerns recognizes humanistic values instead of special cases. For example, software development projects
focusing primarily on technical specifications. and other projects are WSs designed to produce specific
product/services and then go out of existence. Thus, a project
III. SUMMARY OF THE WORK SYSTEM PERSPECTIVE that creates or improves a MXN is a WS on its own right.
The WSP has evolved over many years. Its development Consistent with other ideas in the WSP, MXNs can be
started with an attempt to create a systems analysis method for viewed as a highly restricted special case of WSs. The fact that
business professionals, which was articulated as the work a WS contains a MXN subsystem does not imply that the WS
system method (WSM) [10]. The ideas underlying WSM were itself should be viewed as a MXN (in the same way that a WS
formalized as work system theory (WST), and subsequent that uses IT typically should not be viewed as an IT system).
developments related to service systems, workarounds, design MXNs may not be ISs because the humans and/or totally
principles, and other topics have been viewed as extensions of automated parts of an MXN may perform physical work.
WST [11]. The core of WSP is work system theory (WST),
which applies equally to WSs in general and to ISs. WST’s Work system framework: a basic understanding of a
three components are the definition of WS, the work system WS. The nine elements of the WS framework (Fig. 1) are the
framework, and work system life cycle model. Since ideas elements of a basic understanding of a WS’s form, function,
related to WST and WSM have been presented many times, and environment during a period when it is stable enough to
this section will focus on key points that minimize retain its identity even though incremental changes may occur,
misunderstanding of the entire approach. The following such as minor personnel substitutions or technology upgrades.
summary includes a WS interpretation of the idea of STS. Processes and activities, participants, information, and
technologies are completely within the WS. Customers and
Definition of work. The WSP assumes that work is the product/services may be partially inside and partially outside
application of human, informational, physical, and other because customers often participate in activities within a WS
resources to produce product/services for internal or external and because product/services take shape within a WS.
customers (or for oneself). Work can occur in businesses, Environment, infrastructure, and strategies are outside of the
governments, homes, and other situations where resources are WS even though they have direct effects within a WS and may
used purposefully to produce outcomes. be affected by major changes in significant WSs.
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) [11]. The first
and/or addresses trends toward automation of work by saying
that WSs may be STSs (with human participants doing some
of the work) or totally automated. A key point is that many of
the same WS ideas apply equally to sociotechnical WSs and
totally automated WSs and to MXNs. Those ideas include
many of the properties of the elements shown in Figure 1.
Special cases. The most important distinction in
describing special cases of WS is the difference between a Fig. 1. The work system framework
sociotechnical WS in which human participants perform some
of the activities vs. totally automated WS where all activities The following clarifications are often useful: Customers
are performed by machines. That distinction says that a MXN refers to people or organizations that receive product/services
produced by a WS. This includes internal and external Coverage of sociotechnical systems. The WSP covers all
customers. The term product/services is used to bypass operational systems in organizations, including STSs that can
controversies about special characteristics of products vs. be viewed as WSs and totally automated systems that can be
services. The term processes and activities is used because the viewed as WSs. Those systems include all ISs, projects, and
activities in some WSs are not structured as processes. other special cases of WS.
Infrastructure refers to human, informational, and technical
resources that are viewed as shared by multiple WSs instead Thus, the WSP covers a much broader domain than the
of being associated primarily with one WS. An example of domain identified in the CFP for RESOSY2021. The CFP
human infrastructure is an IT group that can be viewed as a prioritizes “systems built to aid humans in specific human
resource used by multiple WSs. “Elements of the WS tasks” [in situations that involve] “mixed initiative … where
framework” will be abbreviated as “WS elements” even the computer or the human can take initiative, monitor events,
though the last three elements are viewed as outside of a WS decide what to do next, and perform tasks.” The WSP covers
and often are controlled elsewhere. those situations and many others. It covers “systems built to
aid humans in specific human tasks” but it also covers systems
Work system life cycle model (WSLC): how WSs that use automation to replace people who previously
change over time. ISs and other WSs evolve through a performed specific tasks and also systems that perform totally
combination of planned change through projects and automated tasks that were never performed by people. The
unplanned change through adaptations and workarounds (Fig. WSP covers systems with mixed initiative interactions of
2). WSLC phases (initiation, development, implementation, humans and computers, but also covers systems where
operation and maintenance) may be performed in different responsibilities of humans and computers are structured to be
ways. Typical activities and responsibilities (e.g., designing, completely separate.
debugging, training, etc.) associated with specific phases
apply for waterfall, agile, prototyping, use of off-the-shelf A key issue that bears reiteration is the interpretation of the
applications, and shadow IT, even when several phases terms system and STS in regard to this discussion. Computer
overlap or iterate. science papers often assume that systems are software-
controlled 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.
IV. WSP VIEW OF REQUIREMENTS ENGINEERING
This section uses ideas from a 2021 ACM Tech Talk [15]
by Bertrand Meyer to summarize the nature of requirements
Fig. 2. The work system life cycle model (WSLC) engineering (RE) and to illustrate a WSP view of RE. The
next section will focus on aspects of the WSP that are
Both planned and unplanned changes often affect multiple especially relevant to RE for STSs that contain subsystems
WS elements, not just technologies. The development phase “built to aid humans in specific human tasks” and that involve
creates or acquires and then tests software and other resources “mixed initiative … where the computer or the human can
needed for implementation in the organization. The take initiative, monitor events, decide what to do next, and
implementation phase involves much more than installation of perform tasks.” (the domain described by the CFP).
software on computers. The WSLC’s four idealized phases
According to [15], RE can be described in terms of PEGS
(and related sub-phases) express a waterfall-like approach to
(Project, Environment, System, and Goals) that are equally
identifying things that should happen as a WS evolves
applicable to waterfall projects and to agile projects that
iteratively. Many WSLC topics remain valid when agile
proceed through iterations of sprints. Each element of PEGS
approaches are used for developing software, such as the
is reflected in the WSP. In the WSLC, formal projects occur
importance of WS changes rather than just software
through initiation, development, and implementation phases
development, evolution over time rather than one-time
each of which involves activities mentioned earlier. RE occurs
projects, the simultaneous importance of planned and
during the initiation phase and may continue during the
unplanned change, and the relevance of key activities and
development phase. Goals are set during the initiation phase
responsibilities within each phase. The key activities and
and may be revised in subsequent phases. The surrounding
responsibilities remain even if the phases are partially merged
environment appears as one of nine WS elements (Fig. 1) and
and regardless of whether the WS uses homegrown software,
is reflected in the deliberations during the initiation phase of
commercial application software, or external platforms. For
the WSLC. The system is a WS that may have multiple
example, regardless of whether aspects of development and
sociotechnical or totally automated subsystems, each of which
implementation are partly merged, it is still necessary to
can be analyzed or designed based on WST and WSM.
determine requirements (at an appropriate level of detail),
acquire, produce, or fix software that is needed, test and debug Below are brief descriptions of four WSs that could
software, decide how to implement WS changes, identify involve mixed initiative interactions between a person and an
implementation problems, train WS participants, and so on. 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 identify issues such as whether serious conflicts exist between
effort would need to cover the WS (the system in PEGS terms) different user stories.
within which the MXN exists as a subsystem. Failure to
consider the larger WS would result in requirements that treat V. ASPECTS OF THE WORK SYSTEM PERSPECTIVE THAT ARE
the MXN’s environment too narrowly to permit evaluation of PERTINENT TO REQUIREMENTS ENGINEERING FOR MXNS
its effectiveness for meeting WS goals. Topics within the WSP build outward from the definition
An interactive tutor. The broad class of WSs that provide of WS and include the main ideas in WST, the application of
instruction may or may not include an MXN whose activities those ideas in WSM, and a series of extensions related to
are controlled partly by a student and partly by a robot serving design principles, service systems (in a business sense),
as an automated tutor. The extent of shared control can be workarounds, WS interactions, and other topics. Covering the
described along a dimension that starts with the student merely entire WSP would require a book-length discussion. Since that
answering questions from the robot. Highly interactive is not practical for current purposes, this section emphasizes
learning is more like a dialogue between the student and the WSP topics that are relevant to all WSs but are especially
robot. That dialogue is part of a larger WS that may involve relevant to MXNs. Those topics include portrayals and
other activities such as recording the student’s progress and characteristics of WSs and WS elements, performance
understanding of specific items in the material to be learned, variables for WSs and WS elements, facets of WSs and WS
assignment of students to learning programs, monitoring the elements, functions performed by WS subsystems, WS design
continuity of the student’s attention, and so on. principles, division of responsibilities for specific activities,
interaction patterns, and different degrees of smartness in
A customer service chatbot. The chatbot is part of a devices and systems.
larger WS of providing customer service. For example, a
presentation [16] about the Moveworks capability for IT help A. Portrayals of WSs and WS elements
desks noted that its chatbot answers around 40% of IT help Portrayals of WSs are alternative concepts for visualizing
desk queries and escalates the rest to human customer service the entirety of a WS or WS element. (See Fig. 3.) The
representatives who may escalate queries further if needed. following list identifies alternative portrayals that are relevant
The 40% reduction in queries handled by humans reduces to many WSs. For each portrayal, the list includes a question
customer service costs and eliminates many delays. The extent or issue that could be relevant to RE for a specific MXN.
to which the chatbot is an MXN was not clear from [16].
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 Fig. 3. Portrayals of WSs and WS elements
of WS in which analysts perform activities directed at
producing requirements. Applying the definition of WS, RE is Customers might be portrayed as recipients of
a system (a WS in its own right) in which human participants product/services or as beneficiaries of
and/or machines perform processes and activities using product/services. Does this MXN have any customers
information, technology, and other resources to produce by either portrayal?
specific product/services for internal and/or external
customers. By that definition, some future type of RE might Product/services might be portrayed as outputs that are
be partly or totally automated. The requirements are delivered vs. as results of extensive collaboration.
product/services that are produced, and the customers are What identifiable product/services does this MXN
people or organizations that receive and use the requirements. produce?
Assume (quite optimistically) that knowledge about RE is Processes might be portrayed as idealizations of how
sufficiently codified that an MXN subsystem of a WS for RE work should be done vs. as descriptions of how work
could include a robot that monitors the current state of a is executed. How does RE for this MXN consider the
structured requirements document. The robot could ask possibility of noncompliance with specifications?
human analysts questions such as whether noncompliance via Participants might be portrayed as WS components
human agency has been considered or whether past that follow specifications or as people with human
workarounds have indicated areas where the target WS needs needs and interests. To what extent are both portrayals
to be improved. Conversely, the analyst could ask the robot to used in RE for this MXN?
examine the current state of the requirements document and to
apply codified knowledge about specific aspects of RE to
Information might be portrayed as knowledge, as a Errors and delays in other parts of the WS that an MXN
conveyor of meanings that inform people, or as serves will likely affect the operation of the MXN. Thus,
machine-processed digital objects. How does RE for metrics related to a MXN’s performance at specific times
this MXN apply those different views of information? often might depend on the state and operation of other parts of
the WS in which the MXN exists. For example, downtime or
Technologies might be portrayed as tools used by users errors in processes that provide inputs to the MXN could cause
who perform work vs. as technical components of a the MXN to operate more slowly or to stop operating at all,
WS vs. as automated services that perform work. How which likely would affect the metrics for the MXN and its
does RE for this MXN reflect those portrayals? human participants during that period. Other important
B. Characteristics of WSs and WS elements performance variables that might be overlooked during RE
involve job performance and job satisfaction of participants in
In the WSP, characteristics are properties used for an MXN. For example, participating in the MXN could lead
describing or analyzing WSs, WS elements, or other to better or worse job performance and job satisfaction.
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.
Fig. 5. Performance variables forf WSs and WS elements
D. Facets of WSs and WS elements
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
Fig. 4. Characteristics of WSs and WS elements 18 “facets of work” that can be viewed as facets of the
processes and activities in a WS (see Fig. 6). Those facets
Other characteristics in Fig. 4 also have direct implications apply to both sociotechnical and totally automated systems,
for MXNs. A high degree of structure in a MXN’s processes are associated with specific concepts, brings evaluation
and activities implies that interactions between humans and criteria and design trade-offs, have sub-facets, and bring open-
machines are largely about following scripts, whereas a less ended questions for starting conversations [18]. Some facets
structured MXN would allow much less scripted interactions overlap (e.g., making decisions and communication). Whether
that could require a semblance of smartness or intelligence or not to include a concept as a facet of work was based on
[17]. Information also brings interesting RE questions for that concept’s association with useful concepts, evaluation
MXNs, such as how to describe or limit information-related criteria, and design trade-offs. For example, making decisions,
bias on the part of the human participant or the robot. Realistic communicating, and providing information all are associated
RE analysis should say something about the knowledge and with useful concepts, evaluation criteria, and design trade-
skill that MXN participants need to bring to interactions offs. The 18 facets were the end-product of an iterative design
within the MXN. Assumptions about a participant’s personal process that might have led to 14 or 27 facets. Future research
goals and ambitions should be included in RE because playing might lead to a different set of facets of work.
a role in a MXN might or might not be consistent with those The central contribution of facets of work for RE related
goals and ambitions. to MXNs is that the facets of work provide a way to be specific
C. Performance variables for WSs and WS elements about requirements for many specific types of capabilities that
otherwise might have been overlooked. For example, consider
Performance variables in the WSP (Fig. 5) are concepts
the facets learning, planning, improvising, and maintaining
used for describing or analyzing how well entities or their
security. Having a list of facets makes it less likely that those
constituents operate. Required levels of performance variables
topics will be overlooked in RE related to MXNs and to WSs
would be viewed as “non-functional requirements” in the
in general. Linkage of each element of that list to some version
world of software.
of associated concepts, evaluation criteria, design trade-offs,
sub-facets, and open-ended questions identified in [18] could Fig. 7 uses the format of a “work system snapshot,” a basic
provide further support for RE. 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., [19]). Unlike axioms or laws, design
principles often have exceptions, may be mutually
inconsistent, and may conflict in practice. For example, as
noted in [20], in some cases the principle “please the
customers” may conflict with “do the work efficiently.”
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.
Fig. 6. Facets of WSs and WS elements
E. Functions performed by subsystems
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,
Fig. 7. Design principles for sociotechnical WSs
creating alarms when predefined conditions occur,
controlling or facilitating coordination, G. Division of responsiblities for specific activities
An important design question for MXNs is the division of
suggesting decisions,
responsibilities, i.e., the extent to which the person or the
triggering automated functions, machine is responsible for each activity in a MXN subsystem.
RE for a MXN would be superficial if it did not deal with that
performing totally automated tasks autonomously. question either in a general way or by being explicit about
This list shows that RE for an MXN (or other WS) could whether a human or a machine is responsible for initiating
be supported by a list of common functions even though it each activity, for monitoring each activity, for declaring an
says nothing about whether the person performs those activity complete, and for transitioning to other activities.
functions for the robot or vice versa. Many other functions A WSM tool called a service responsibility table (SRT)
might be included. As with the facets of work, this type of list [21] was designed for other purposes but can be used for
could help analysts make sure they have considered a range of describing the division of responsibilities in a MXN. An SRT
common possibilities. More broadly, some version of a list of applied to a MXN would be a table consisting of at least three
functions potentially helps in realizing that RE for a MXN columns: 1) a list of activities in the MXN, 2) responsibilities
should be specific about functions being performed regardless of a person regarding each of those activities, 3) related
of whether they are initiated by either a human or a robot. responsibilities of an automated entity regarding each of those
F. WS design principles activities. Additional columns could clarify responsibilities
for specific aspects of each activity, such as initiation, quality
Design principles are statements that express desired control, error detection, and declaration of completion. An
properties of designed entities within a domain. Design SRT can also be expanded by adding columns related to topics
principles may apply to all WSs within a domain, to specific such as mutual visibility or at least awareness of non-
types of WS within the domain, and/or to WSs associated with interactive activities performed by the human or machine.
a community of practice.
H. WS interactions and interaction patterns intermediary), actor type (e.g., person or machine), actor
Interactions between WSs include unidirectional, mutual, rights for each role, actor responsibilities for each role, cause
or reciprocal actions, effects, relationships, influences, or or trigger of the interaction, desired outcome, generic process
interplay between two or more WSs. Systems theorists such or activities, possible states of an interaction, and alternative
as Ackoff [22] and Checkland [23] observe that systems enactments. Occasionally relevant elements of interaction
typically exist to serve other systems and that understanding patterns include constraints, risks and risk factors, relevant
or analyzing a system requires understanding whatever concepts, interaction verification, and interaction evaluation
systems are being served and how those systems are being I. Smartness of devices and systems.
served. A thorough analysis needs to go further by considering
planned and unplanned interactions with other systems Finally, RE related to MXNs might consider ideas about
regardless of whether they serve or are served by a focal the smartness of devices and systems since the notion of MXN
system of primary interest. The many types of interactions tends to imply some degree of smartness in a computerized
between systems range from repetitive interactions such as device. An approach to smartness of devices and systems is
supplier-customer transactions to transient interactions related explained in [17], which identifies generic capabilities that
to mishaps or malicious actions. A thorough understanding of might be executed by computerized algorithms. RE might
system interactions should include indirect impacts such as apply that idea without getting entwined in debates about the
effects of inconsistent goals, inconsistent standards, and definition, nature, or limitations of artificial intelligence. [17]
inconsistent treatment of personnel. It also should consider uses four categories to organize numerous capabilities that
direct and indirect impacts when other entities perform might be built into devices or systems:
unexpectedly or inadequately. In general, RE should consider Information processing. Capture information,
system interactions both while also focusing on systems in transmit information, store information, retrieve
isolation and while focusing on the surrounding context. Thus, information, delete information, manipulate
even a superficial look at an MXN in the context of RE should information, display information.
consider its interactions with other WSs, with resources used,
or with other aspects of the WS in which it operates. Action in the world. Sensing, actuation, coordination,
communication, control, physical action.
The idea of interaction patterns can be used when thinking
about the requirements for capabilities within an MXN. Internal regulation. Self-detection, self-monitoring,
Preliminary research [24] identified 19 interaction patterns self-diagnosis, self-correction, self-organization.
within four categories. Those interaction patterns include:
Knowledge acquisition. Sensing or discovering,
One-way patterns are unidirectional interactions that classifying, compiling, inferring or extrapolating from
have been studied in relation to the language action examples, inferring or extrapolating from abstractions,
perspective (LAP). Patterns within this category are inform, testing and evaluating.
command, request, commit, and refuse. All of those patterns As noted in [17], the smartness built into a device or
involve unidirectional interactions.
system (in a MXN) for any of the above capabilities can be
Coproduction patterns are bilateral patterns involving characterized along the following dimension:
jointly produced interactions whose instantiations can be
Not smart at all. Does not perform activities that
observed as sequences of unidirectional interactions, some of
exhibit the capability.
which may be described as speech acts. Coproduction patterns
include converse, negotiate, mediate, share resource, and Scripted execution. Performs capability-related
supply resource. The first three are fundamentally about activities according to prespecified instructions.
bilateral speech situations, whereas the other two are
fundamentally about coordination as described by Formulaic adaptation. Adaptation of capability-
coordination theory [25, 26]. related activities based on prespecified inputs or
conditions.
Access and visibility patterns are unidirectional patterns
concerning one entity obtaining access or visibility related to Creative adaptation. Adaptation of capability-related
another entity and about countermeasures to prevent access activities based on unscripted or partially scripted
and visibility. These patterns include monitor, hide, protect, analysis of relevant information or conditions.
and attack. The first of these involves a typical management Unscripted or partially scripted invention.
activity. The next two involve defensive maneuvers. The last Invention of capability-related activities using
pattern represents a threat. unscripted or partially scripted execution of a
Unintentional impact patterns are the least articulated workaround or new method.
patterns because of the great uncertainty about the sources and
effects of many unintentional impacts. Examples include VI. DISCUSSION AND CONCLUSION
overlap, market-based, spillover, indirect, and accidental This paper started by noting that the CFP of RESOSY
interactions. While it may not be possible to anticipate those 2021 characterizes STSs as “systems that are built to aid
impacts, ignoring the possibility that they will occur is humans in specific human tasks” that should be addressed as
certainly not a beneficial RE practice. “mixed initiative systems where the computer or the human
can take initiative, monitor events, decide what to do next, and
While the ideas in [24] surely could be elaborated further,
perform tasks.” That characterization is much more restricted
it is worth noting that likely elements of typical interaction
than typical characterizations of STS that researchers and
patterns in the first three categories include actor roles (e.g.,
practitioners have used for decades. The acronym MXN
requestor/respondent, initiator/recipient, partner, or
(mixed initiative system) was used to pursue the CFP’s focus [5] E. Mumford, “The story of socio-technical design: Reflections on its
without causing confusion about different views of STS. successes, failures and potential,” Inf. Syst. J., vol. 16, no. 4, 2006, pp.
317–342,
This paper’s contribution used aspects of the WSP to [6] K. Eason, “Afterword: The past, present and future of sociotechnical
identify many topics that should be considered in RE related systems theory,” Appl. Ergon., vol. 45, 2013, pp. 1–8,
to WSs in general and MXNs in particular. It summarized the [7] F. M. v Eijnatten, A. B. Shani, and M. M. Leary, “Sociotechnical
main ideas in the WSP and then focused on aspects of the systems: designing and managing sustainable organization”s,
Handbook of organization development, T.G. Cummings, (Ed.) Sage;
WSP that are especially relevant to RE for MXNs. Those 2008.
aspects of the WSP include portrayals and characteristics of [8] S. Winby, “The adaptive work system: a perspective on the evolution
WSs and WS elements, performance variables, facets of work, of socio-technical systems,” Socio-Technical Roundtable annual
functions performed by subsystems, WS design principles, conference. New Orleans, LA, 2011
division of responsibilities, interaction patterns, and the [9] S. Alter, “Applying socio-technical thinking in the competitive, agile,
characterization of smartness in devices and systems. lean, data-driven world of knowledge work and smart, service-
oriented, customer-centric value creation ecosystems.” Comp. Syst.
This paper illustrated the idea of MXNs by using four Infor. and Mod. Q., Vol. 18, 2019, pp. 1-22,
examples, but did not propose MXN requirements for those [10] S. Alter, The work system method: connecting people, processes, and
examples. Doing so would have required a detailed discussion IT for business results. Larkspur, CA: Work System Press, 2006.
of those situations including description of the WSs in which [11] S. Alter, “Work system theory: overview of core concepts , extensions,
the MXN examples exist. and challenges for the future,” J. Assoc. Inf. Syst., vol. 14, no. 2, 2013,
pp. 72-121.
One of this paper’s important limitations is its focus on a [12] S. Alter, “Defining information systems as work systems: implications
specific set of ideas related to the WSP, aspects of which have for the IS field,” Eur. J. Inf. Syst, Vol. 17, No. 5, 2008, pp. 448-469
been presented in many papers on a range of topics. This [13] S.K. Boell and D. Cecez-Kecmanovic, “What is an information
paper’s highly condensed presentation of many ideas outlines system?” Proceedings of Hawaii International Conference on System
Sciences, HICSS, 2015, pp. 4959-4968, IEEE
an integrated approach to addressing many RE issues related
to STSs and MXNs, but it also leaves many questions that can [14] A. Burton-Jones, J. Recker, M. Indulska, P. Green, and R. Weber.
"Assessing representation theory with a framework for pursuing
only be answered through much more extensive discussion of success and failure." MIS Q., Vol. 41, No. 4, 2017, pp.1307-1333.
specific WSP concepts and assumptions underlying the WSP. [15] B. Meyer, “The four PEGS of requirements engineering,” presentation
This paper necessarily omitted many ideas that could not slides, ACM Tech Talk, 4 March 2021. Accessed on 1 Sept. 2021 at
https://www.youtube.com/watch?v=JaOcWrV75pE
fit in a short paper. Other researchers surely would approach
[16] B. Shah, “How conversational AI will empower one billion knowledge
topics related to MXNs from other viewpoints such as agentic workers, MIT AI conference 2020: AI for a better world,
artifacts [27] or multi-agent systems. Similarly, important https://www.youtube.com/watch? v=bzBZA_2kkNE, last accessed 28
issues related to human autonomy and dignity at work [28] August 2021.
could be approached from many other directions. Even topics [17] S. Alter, "Understanding artificial intelligence in the context of usage:
such as intrusive monitoring at work and the “uncanny valley” Contributions and smartness of algorithmic capabilities in work
[29] (where attempts at social behavior by robots that lack systems." Int. Journal of Inf. Mgt., published online, August 2021.
human emotions seem unnatural and untrustworthy) could [18] S. Alter, “Facets of work: Enriching the description, analysis, design,
and evaluation of systems in organizations,” Communications of the
have been discussed in a much longer paper or even a book. Association for Information Systems (forthcoming), In Press, 2021.
The next step in extending this paper’s ideas is to validate [19] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design
their usefulness by applying those ideas to specific RE Patterns:Elements of Reusable Object-Oriented Software, Reading,
MA: Addison-Wesley. 1995
projects that focus on WSs that contain MXNs or might
[20] S. Alter and R. Wright, “Validating work system principles for use in
contain MXNs in the future. Careful evaluation of documents systems analysis and design, Proceedings of the International
produced in those projects plus interviews of project Conference on Information Systems, 2010.
participants would probably help in describing the extent to [21] X. Tan, S. Alter, and K. Siau. "Using service responsibility tables to
which specific WSP ideas in this paper provide insights or supplement UML in analyzing e-service systems." Dec.Sup.Syst,,
simply seem consistent or inconsistent with existing practices Vol. 51, no. 3, 2011, pp. 350-360.
from previous projects. [22] R. L. Ackoff, “Towards a system of systems concepts,” Mgt.
Sci., Vol. 17, No. 11, 1971, pp. 661-671.
Mixed initiative systems have many potential applications [23] P. Checkland, Systems thinking, systems practice, Chichester, UK:
that go far beyond current practice. Research about whether John Wiley, 1999.
existing RE techniques need to be extended for such situations [24] S. Alter, “System Interaction Patterns,” IEEE Conference on Business
is potentially quite valuable. The WSP-centric ideas presented Informatics, Paris, France, Aug. 2016.
in this paper could be a step forward in that research. [25] T. W. Malone and K. Crowston. "The interdisciplinary study of
coordination." ACM Comp. Surv., Vol. 26, No. 1, 1994. pp. 87-119,
REFERENCES [26] K. Crowston, J. Rubleske, and J. Howison, “Coordination Theory: A
[1] R.P. Bostrom and J. S. Heinen, “MIS problems and failures: a socio- Ten-Year Retrospective”. in Zhang, P. and Galletta, D. (Eds.) Human-
technical perspective, part II: the application of socio-technical Computer Interaction in Management Information Systems, Vol I. M.
theory,” MIS Q., vol. 1, no. 1, 1977, pp.11-28, E. Sharpe, 2006.
[2] S. Sarker, S. Chatterjee, X. Xiao, X. and A. Elbanna, The [27] A. Baird and L. M. Maruping. "The Next Generation of Research on
sociotechnical axis of cohesion for the IS discipline: Its historical IS Use: A Theoretical Framework of Delegation to and from Agentic
legacy and its continued relevance. MIS Q., Vol. 43, No. 3, 2019, IS Artifacts." MIS Q. Vol. 45, no. 1,2021, pp. 315-341.
pp.695-720. [28] D. E. Leidner and O. Tona. "The CARE Theory of Dignity Amid
[3] J.C. Licklider, “Man-computer symbiosis.” IRE transactions on human Personal Data Digitalization." MIS Q., Vol. 45, no. 1, 2021, pp. 343-
factors in electronics, (1), 1960, pp.4-11. 370.
[4] D. Avison, D., N. Bjørn‐Andersen, et al. (19 co-authors)., Enid [29] M. Mori, K. F. MacDorman, and N. Kageki. "The uncanny valley
Mumford: a tribute. Inf. Syst. J.,, Vol. 16, No. 4, 2006. pp.343-382. [from the field]." IEEE Rob. & Autom. Mag. Vol. 19, no. 2, 2012, pp.
98-100.