Information Technologies in Complex Socio-Technical Systems Based on Functional Variability: A Case Study on HVAC Maintenance Work Orders

Abstract

Information technology (IT) systems are known to promote improvements in quality and productivity of the work environments of complex and adaptive socio-technical systems that span hardware, community and software aspects. Systems development lies in eliciting and specifying requirements. However, current requirements of elicitation techniques are limited to correctly understanding the complexity involved in socio-technical systems. Therefore, approaches based on Resilience Engineering can provide concepts and methods for a better understanding of socio-technical systems’ functioning. This study aims to increase the application of the Functional Resonance Analysis Method (FRAM) in the requirements elicitation process. Specifically, understanding variability and its role in enhancing the requirements elicitation and specification process for the design/redesign of IT systems in complex socio-technical systems deployed in building maintenance is the main goal. This study proposes the merging of human factors and ergonomics (HFE) and Resilience Engineering concepts with Software Engineering. A case study was performed with workers to produce requirements specifications for work order issuing activity. This case study indicates the usefulness of the proposed approach for the specification of functional requirements to redesign the IT system examined. FRAM enables inferences to be made from hidden or fuzzy situations that are often not expressed by system users or are not detected by the system designer.

1. Introduction

Complex socio-technical systems [1] involve a multifaceted interaction between humans, machines, and the environmental aspects of the work system [2]; this can comprise some subsystems and subtasks linked in known or unknown ways [3]. A complex system is composed of a system for which it is difficult, if not impossible, to reduce the number of parameters or characterizing variables without losing its essential functional properties [4]. The entire system may be affected by small oscillations occurring in specific tasks, leading to potentially critical consequences [5]. Such systems are known for being prone to unexpected variability, which means that actors will vary their actions in response to situational demands or disturbances to achieve a system’s goal. The functional variability tends to propagate quickly and non-linearly due to tightly coupled processes [6,7].

In socio-technical systems, human, organizational, and software agents rely heavily on each other to fulfill their respective objectives [8]. Information technology (IT) systems can promote the improvement of quality and productivity in the work environment of complex socio-technical systems. Modern developments in IT systems related to the building maintenance activities have been implemented to facilitate maintenance management, including failure analysis, documentation of maintenance, fault location, repair, and reconstruction [9]. For example, in non-residential infrastructures, it would be impracticable to manage adequately the maintenance of heating, ventilation, and air conditioning (HVAC) systems without an IT system. Therefore, there is a need for effective evaluations of IT to ensure that the system requirements meet the needs of users. In this domain, the peculiarities of each organization and the complexity involved in the activity stand out as obstacles for embedding those technologies. In addition, for the adoption of technological devices to support complex activities, understanding how work is done becomes a difficult task because of the interdependence among a large number of variables [10].

Requirements elicitation plays an important role in the information technology design, since it has a cascading effect on subsequent processes; defects introduced at the requirements engineering stage have a negative impact that is significantly higher than defects in the later development stages [11]. An inadequate requirements specification acts as a catalyst to other problems, such as low team productivity and difficulty in maintaining software [12]. Moreover, unclearly describing the requirement specifications may become difficult to develop high-quality software [13]. In addition, it is significantly cheaper to elicit and specify requirements during the requirements engineering stage than during later software development activities [14].

Requirements elicitation aims to identify the requirements of IT systems according to the need of the customers and users, which is not always straightforward [15,16]. For many complex domains, users usually do not have a complete understanding of the problem domain, including the difficulty of describing their needs and expectations to the designer in a systematic way [17,18]. This situation increases the tendency to obtain incomplete and ambiguous data. Therefore, this stage is recognized as the most difficult, error-prone, activities during the software engineering life cycle [19], since requirements engineers are usually not trained to elicit this kind of information [20].

Moreover, current elicitation techniques are limited to gain requirements in socio-technical systems; these are either critically dependent on the selection of experts to ensure the successful elicitation of requirements, which require the wide expertise of analysts with formal methods and techniques, or lack a proper methodological approach to deal with these requirements [8]. Furthermore, typical approaches to elicit software requirements are not always sufficient to correctly understand the complexity of IT devices or to anticipate likely error situations [21]. Hence, they are not well suited for eliciting deeper social and features of socio-technical systems [8], since those are subject to variability (non-linear characteristics), including the inherent complexity. Depending on how requirements are elicited, analysts may not be able to predict variations that emerge when the system is functioning [21]. This situation is often perceived as a major obstacle for knowledge eliciting, which could lead to unclear and incomplete requirements documents [22]. As a result, those systems might become underutilized, which can cause management difficulties and consequently the loss of quality in the system utilization.

Researchers and practitioners in IT systems have long recognized that understanding the business processes that an information system must support is crucial to eliciting the needs of its users [23]. Among the various methods developed for business modeling, it is worthwhile to mention the Structured Analysis and Design Technique (SADT), a functional language [24], which is standardized into the modeling language Integration Definition for Function Modeling (IDEF0) [25]. This technique provides a means for modeling activities, actions, processes, and operations required by a system or enterprise as well as the functional relationships in a structured way [26,27]. However, it excludes an in-depth description when gathering contextual and requirements information [28]. Moreover, IDEF0 presents some drawbacks that affect its suitability for eliciting requirements in complex socio-technical systems once the method provides a static representation of the system, indicating linear functional relationships that conflict with the characteristics of complex socio-technical systems. IDEF0 is more focused on the description of the tasks and their orders than how the tasks are performed [29]. Therefore, approaches providing a depth analysis focusing on human behavior during the task execution and its inherent variability are the most suitable.

To improve requirement elicitation and specification in situations with a high-cognitive workload, Software Engineering can benefit by using practices of human factors and ergonomics (HFE). These practices bring techniques to enhance the understanding of how people work by providing services and tools that can be used to design an IT system [30]. HFE research provides insights and tools that could help developers design IT systems that reliably match “Work-as-Done” (WAD), instead of “Work-as-Imagined”. These approaches have been adopted to facilitate and equip stakeholders involved in the design process with the knowledge necessary to the coupling between traditional engineering and HFE disciplines [31]. Some examples of recent studies, examining the role of HFE in software engineering can be mentioned. Jatobá et al. [10,30] examined the role of cognitive engineering to support the improvement of software requirements specifications, used in the healthcare domain. In addition, Dey et al. [18] proposed a methodology based on repertory grids to help users express their expectation of the IT systems in a socio-technical environment.

Resilience Engineering [32] emerges as a concept that could be understood as managing the preparedness of the organization to respond to unexpected events [33]. These concepts can be applied to produce tools to understand how people work and to proactively manage risk, acknowledging the inherent complexity of system functioning and the need for performance variability [34]. Functional Resonance Analysis Method (FRAM) [21] is a resilience-based tool that emphasizes the investigation of functional aspects, which is a key for modeling dynamic interactions, and performance variability, rather than physical aspects [22]. Moreover, it enables in principle the modeling of any interaction type (e.g., social interactions, the flow of materials, logical dependence) [23], which provides a broader source of information when compared with classic representations of business processes such as the Business Process Management and Notation (BPMN) model [21]. A FRAM model shows the non-linear coupling between functions and their inherent complexity. It illustrates how the variability spreads along with the system, which can lead to positive as well as negative results. Recently, De Carvalho et al. [21] conducted an experimental study comparing the BPMN and FRAM in an attempt to deal with the elicitation and specification of IT requirements in complex socio-technical systems, specifically in the healthcare domain. As such, it seems that FRAM is an adequate methodology to address the activity complexity, thereby contributing to the most reliable elicitation and specification of requirements for IT systems.

Regardless of the advances obtained by including the FRAM in the requirements elicitation process, empirical studies on the specific contributions of Resilience Engineering in the design or redesign process of IT systems are still scarce [35]. Therefore, an approach that integrates Software Engineering, HFE, and Resilience Engineering practices is timely. Given this context, this study aims to increase the application of FRAM in the requirements elicitation process of socio-technical systems. More specifically, the purpose of this study is to find out how variability understanding contributes to the requirements elicitation and specification for the design and redesign of IT systems to support the work in complex socio-technical systems. An empirical case focused on the maintenance of heating, ventilation, and air conditioning (HVAC) systems, specifically in the issuance of work orders (WOs) was addressed by using the FRAM.

The remainder of the paper is organized as follows: Section 2 presents a basic concept on requirements elicitation and specification. Section 3 presents an overall approach to FRAM. Section 4 introduces the details of the proposed method, including the framework used to conduct this study. Section 5 illustrates a case study by using the FRAM to support the process of requirements elicitation and specification. Section 6 presents discussions about the results. Finally, the last section presents the conclusions with the research contributions and possible future directions of research.

2. Requirements Elicitation and Specification

Requirements engineering (RE) is a branch of Software Engineering dedicated to the process of requirements specification that software must solve. The system requirements express the description of what the system should do and the obstacles to its operation. RE should be focused on precisely defining the real problem that the software must solve by describing the requirements in terms of how the proposed software should affect the environment [36].

The RE processes usually include four high-level tasks. These processes focus on assessing if the system is useful to the business (feasibility study), discovering requirements (elicitation and analysis), translating these requirements into some standard form (specification), and checking if the requirements define the system that the customer wants (validation) [36].

After an initial feasibility analysis, the next stage of the requirements engineering process is requirements elicitation and analysis. In this stage, designers seek to discover from stakeholders what services the system should provide, the required performance of the system, and hardware constraints, among others [36]. It is noteworthy that a requirements elicitation process is not trivial. The process needs to handle both needs and requirements. Needs are the goals and wishes of the system from the customers’ perspective, whereas requirements represent perceptions of the system based on the designer’s interpretation [37]. A true elicitation must encompass all the aspects of the context that can affect the system or its use rather than only capturing the customers’ needs [20].

System designers can utilize a set of elicitation techniques to gain relevant information to specify requirements. The applicability of each technique depends on the context in which the elicitation is used. Some traditional techniques include but are not limited to open interviews, structured interviews, ethnography, card sorting/laddering, questionnaires, protocol analysis, repertory grid, brainstorming, Delphi technique, prototyping, focus group, scenarios, and use cases, among others [16,38].

The main action to cope with the user’s extracted requirements is to register them in a standardized way. This standardized documentation assists stakeholders with understanding and organizing data, avoiding the raw data, which in many cases do not contribute to support decisions at the system development stage. Thus, this document so-called software requirements specification (SRS), establishes the basis for a documented agreement between customers and designers. SRS reports what stakeholders expect from the software. It also allows rigorous requirements evaluation before the start of building the software. This step also provides a realistic basis for estimating costs, risks, and product timelines.

The IEEE 830 standard [39] standardizes the SRS process, providing a set of best practices for developing an acceptable document. This document contains the specifications, containing all the technical details, including the functional and non-functional requirements of the system to be developed. The SRS will describe the behavior of the system under various conditions as completely as necessary, as well as the desired system qualities, such as performance, safety, and usability. This study uses the SRS from the point of view of the IEEE 830, focusing on specifying the functional requirements to redesign the IT system used in the issuance of WOs for the maintenance of HVAC systems.

3. Functional Resonance Analysis Method (FRAM)

FRAM [3] is a systemic analysis method that is used to describe the activities of a complex socio-technical system. This method considers the non-linear nature of the system performance rather than build a sequential cause–effect model of events over time [40]. FRAM enables the analysis from past events of a complex system, such as an accident investigation, safety management, and complexity management up to possible future events as a risk assessment [41].

The main purpose of FRAM is to build a model of the functions of a system that describes how performance variability may occur in the work-as-done (WAD) and how the effects may spread through the system. Regarding the graphical appearance of a FRAM model, for professionals who have never seen it, it seems a complex structure, which it is not. Indeed, the outcome analysis is not an algorithmic process, but rather the representation of the non-linear relationship among users working together [42].

FRAM has been extensively applied to the understanding and identification of variability and resilience in complex systems in several domains, such as aviation [43,44,45], construction [46,47], manufacturing [48], environmental [49], healthcare [50,51], the oil industry [42,52,53], and the maritime industry [54]. Other FRAM’s applications are found in extensive mappings, such as in [41,55]. This methodology is based on four principles [3]:

• Equivalence of successes and failures: Failures and successes occur in the same way, i.e., everyday work variability;
• Principle of approximate adjustments: Work-as-done (WAD) never completely correspond to work-as-imagined (WAI). Workers typically adjust their performance to suit existing conditions.
• Principle of emergence: The performance variability of a function is rarely large enough to serve as the only cause of an effect or even to constitute a malfunction. Acceptable and unacceptable results are emergent rather than resultant phenomena, as they cannot be explained just by a cause–effect relationship of the operation of specific components or parts.
• Functional resonance: This latter principle states that the variability of a function may combine with the variability from another function, which causes a functional resonance with a difficult prognosis and significant uncomfortable management. Where it has become a utility to the organizations, the identification of functional resonance phenomena is cited as an instrument to locate management demands, including specific actions. In this case, losses in maintenance quality, delay, or incorrect maintenance are some depictions of undesirable effects.

To build a FRAM model, it is necessary to follow four steps, established by Hollnagel [3]. The first step is the identification and description of the functions, which can be human, technological, or organizational, depending on the nature of the function in the system. This step seeks to describe how the work is done every day, highlighting how the functions interplay with each other, rather than to build an overall flowchart or a function’s structure. FRAM and IDEF0 are similar in terms of decomposing the system functions by using the four aspects of input, output, control, and resources. FRAM extends the number of aspects to include preconditions and a specific aspect representing temporal constraints [29]. The graphic representation of a function is a hexagon, consisting of one output and five inputs. Each vertex of this hexagon is identified as one of the six aspects [3]:

• Input (I): what triggers the function or what is processed or transformed by the function;
• Output (O): what is the result of the function, it can be either a state change or a specific product;
• Precondition (P): mandatory conditions that must exist before the function can be performed;
• Resource (R): what the function needs or must consume when it is carried out to produce the result (the output);
• Control (C): what controls and monitors the function to match the desired output.
• Time (T): temporal requirements or constraints of the function, regarding both duration and time of execution.

In the graphical language of FRAM, multiple hexagons can be displayed together, and the functions are interconnected by a set of lines (or arcs) through single or multiple vertices (or corners). In the FRAM vocabulary, lines or arcs are referred to as couplings [56], which are interpreted as paths for the spreading of variability throughout the system, as it can become the basis for functional resonance [57]. As noted in Figure 1, a function i could be linked with another function j through vertices v(I, O, P, R, C, T). Whilst the vertices v(I, P, R, C, T) represent input aspects that characterize the functioning of the function i, the vertex O feeds a function j or dozens of other system functions from the result produced by the function i. The FRAM Model Visualizer software [58] has been developed to help build FRAM networks as well as track functions and their aspects [59].

The second step is the characterization of the output variability of each function that constitutes the FRAM model. Variability analysis is provided to identify the points that most interfere in the work system performance. To classify the time-related variability, this study uses the following terms: (i) “Too late” when the output of a function does not occur within the exact time specified; (ii) “On time” when the output occurs within the exact time; and (iii) “Too early” when it happens earlier than expected. To classify the variability concerning the precision, this study uses the following terms: (i) “Precise”, for outputs that meet the needs of a subsequent function; (ii) “Acceptable”, for outputs that depend on some degree of regulation; and (iii) “Imprecise”, for incomplete or ambiguous outputs that request additional interpretation or conferencing.

The third step is to analyze how the potential variability of each function can become resonant in the entire system, leading to undesirable outcomes. Hollnagel [3] suggests that looking for functions with multiple couplings may be a first step in determining whether functional resonance can occur. If so, other actions must be taken to evaluate the likelihood and magnitude of variability and how it might affect other functions.

The fourth and last step in the application of FRAM is the monitoring and managing of the performance variability. In this sense, Hollnagel [3] proposes that the most efficient strategy is to adopt actions to damping negative effects, eliminating those that can lead to undesirable outcomes and, conversely, propose actions to enhance positive effects, without losing control of the activities.

4. Materials and Methods

This study proposes the merging of HFE and Resilience Engineering concepts to drive the elicitation and specification of requirements in Software Engineering. The approach proposed in this paper comprises three phases, which can be split into steps, as shown in Figure 2. The preliminary analysis comprises a single step called context description. The remainder phases, i.e., requirement elicitation and requirements specification, must be performed iteratively. Each phase is explained in the next subsections. This approach was used in a case study, as shown in Section 5.

4.1. Phase I: Preliminary Analysis

The goal of this phase is to gain initial knowledge about the organization. This phase consists of the examination of the organizational strategy, vision, and objectives, core business process, identifying process flows, stakeholders involved, resources required, the organizational culture [60], and a broad spectrum of work situations, including the recognition of the physical structure. To perform this phase, the analyst should plan a script including some interviews, collecting documents, procedures, and tools that people use while performing their work. In addition, to constitute a broad understanding of the organization, the analyst should make a walkthrough, identifying agents and recording relevant work situations, aiming to establish synergy to the next phases.

4.2. Phase II: Requirements Elicitation

Requirements elicitation is considered an intensive, complex, and multi-disciplinary process. This task seeks to develop software systems for solving users’ needs and satisfying stakeholders’ objectives [8]. This phase aims to collect and analyze data from the empirical field that enable the construction of a representative model of the WAD with the support of FRAM. It is noteworthy that the analyst should focus on daily tasks to understand how the work is actually performed. In summation, this phase enables us to gather users’ needs and recommendations that become requirements for redesigning the IT system. Strategies used for data collection and modeling of the WAD with FRAM are explained later in the next subsections.

4.2.1. Data Collection

Having as a basic premise the understanding of how the work is done, interview questions were designed and uses to collect data. The interviews were not structured by long questionnaires. The question to the workers and requestors boiled down to: “How do you perform your task?” In addition, a template containing the main topics was designed beforehand as a guide for the semi-structured interviews.

Ethnographic observations [61] were carried out to complement the data collected through interviews. This involved recording relevant details, schemes, and flowcharts to facilitate the understanding of WAD and subsequently support the construction of the FRAM model. A total of 17 visits were made in three months to the site of a Brazilian institution for research and development (R&D) located in the city of Rio de Janeiro. The data collection was achieved using four sources:

• Analysis of existing formal documentation: a documental analysis was undertaken to review the process mapping issued by the managers and policymakers. Although few processes were mapped, in this opportunity, five flowcharts in BPMN concerned with building maintenance were examined;
• Interviews with the maintenance supervisor: semi-structured interviews were held with the maintenance supervisor in three meetings to identify key aspects of maintenance management in the R&D organization to map the main processes;
• Interviews with requestors: semi-structured interviews with ten requestors were undertaken to understand how maintenance is requested, including the role of the current IT system used as a support tool for this specific task;
• Open-ended observations: these observations were used to record the behavior of people while they were performing their activities, aiming to complete data obtained from interviews. During the observations, informal conversations were held with participants to comment on the task being observed.

4.2.2. FRAM Model

In the first step of FRAM [3], the collected data enabled identifying the relevant functions and their couplings in everyday operations. These data were used to build a realistic FRAM model for the issuance of WOs.

In the second step, this study sought to understand the potential variability in the output function using data from experts on the subject and information captured by the analyst. Potential variability regarding timing and precision was disclosed to examine the socio-technical system’s behavior and outcomes. Therefore, the influence of IT on issuing WOs was examined.

The third step sought to analyze how the variability may spread in the entire system, as well as the strategies used by agents to deal with these effects. Finally, the fourth step aimed to describe actions to mitigate the negative effects of variability and to amplify the positive effects, enhancing its occurrence. These actions aim to increase the system’s resilience and improve the user interface, reducing the cognitive workload, and consequently minimizing quality losses in the issuance of WOs for the maintenance of HVAC systems. In addition, this step enabled the requirement elicitation to enhance the IT system.

This study used the software FMV^® [58]—FRAM Model visualizer—to build the graphical representation of the functions and their couplings. The FRAM model contributed with relevant outcomes for specifying requirements in an organized way. The phase of requirements specification is disclosed in the next subsection.

4.3. Phase III: Requirements Specification

The requirements specification refers to detailing in a specific way all the requirements previously gathered as a result of the FRAM model. Representing needs into specifications means expressing precisely the elements of the technical solution to the design team [35].

Identification of Functional Requirements

This step shows how SRS can be strengthened by incorporating results from the approach proposed in this paper. As previously disclosed in Section 2, the IEEE 830 standard [39] standardizes the SRS process, providing a set of best practices for developing an SRS document. This study focused on specific requirements, as recommended in the IEEE 380 standard, as shown in Section 3. Furthermore, this study aimed to specify only the functional requirements to redesign the IT system. The specification of non-functional requirements may be addressed in a future study.

To evolve the traditional approach of requirement specification, this study proposes to add some elements in the frame of requirements recommended by the IEEE 830 standard. Thus, in this study, these elements are aggregated to each stated requirement to constitute a broad description of the user requirements, which is followed by a description of the system requirements in enough detail level to allow the system redesign. These elements consist of a concise title to the requirement, the agent responsible for triggering the requirement, the goal, the description of the requirement, and the outcome performed by the requirement.

5. Results

Fieldwork was undertaken in an R&D organization, especially in the department for building maintenance (DBM), which is responsible for managing the maintenance of the organization buildings. Particularly, this was done by looking at variability and discussing ways to redesign the IT system, highlighting the issues that would lead to positive outcomes while discouraging negative outcomes.

5.1. Phase I: Preliminary Analysis

This phase aims to show a broad vision about the operation of the building maintenance, the work organization, as well as a brief description of the way that workers regularly use to issue a WO. The next section presents the empirical field used in the case study and explains in detail the context involved in this study.

Context Description

The empirical field is a Brazilian institution for R&D located in the city of Rio de Janeiro. This institution is the largest engineering education and research center in Latin America, consisting of 13 graduate programs in engineering, 131 laboratories, 346 professors, and 457 employees. The DBM is a specialized sector in the organizational structure responsible for maintaining acceptable use conditions in the territories of the R&D organization. For this, the work carried out in the DBM comprises six groups: electrical, plumbing, HVAC, civil works, metal works, and carpentry/furniture. The DBM has never undergone any type of sizing to verify the number of workers needed to carry out the maintenance tasks. Currently, the department has twenty-six professionals, being one maintenance supervisor (one civil engineer), one assistant, and twenty-four technicians. Teams are multidisciplinary and perform maintenance in all the R&D territories.

The overall process of building maintenance comprises three great stages: maintenance request, request analysis, and maintenance execution. This study comprises a part of broader research in the building maintenance domain. Particularly, this article focuses on the stage of WOs issuance specifically in requesting for maintenance in HVAC systems. This stage embraces the maintenance requests and the analysis of them. The stage of the maintenance execution has been not included in this article, which may be disclosed in upcoming studies.

Broadly speaking, customers request maintenance using an IT system, namely CISI (Centro de Integração de Serviços de Informática), which is a web-based platform that aims at computerizing requests for building maintenance at R&D territories. To perform the maintenance, the maintenance supervisor should analyze the customers’ requests and issue a WO. The issuance of WOs is carried out in the maintenance management office. Two professionals work in the office: a maintenance supervisor and one assistant. The maintenance supervisor is responsible for allocating the technical team, analyzing, issuing, closing, and filling WOs. It is noteworthy that, also, in these activities, the maintenance supervisor needs to escort the technicians in some maintenance tasks closely. The assistant is responsible for issuing WOs, controlling tools, controlling staff, and answering calls. Eventually, one electrician helps in the office in the absence of the other two employees.

The process manager made available the existing flowchart illustrating the process of issuance of a WO. Figure 3 illustrates the process of issuance of a WO, as designed by the process manager. To trigger a request, the user fills the fields contained in the CISI screen. The screen shows three fields to fill, as follows:

• Cost center: This is the administrative unit to which the requestor is attached;
• Place: This is the laboratory or classroom where the maintenance is located;
• Description of the service: This is the field destined to the user so that it describes, with his words, the required maintenance.

In complex socio-technical systems, the WAD is always different from WAI by those who write guidelines and procedures [62,63]. Therefore, the researcher aimed to understand how the tasks are performed realistically. For this purpose, based on interviews and observations, the researcher engaged in producing an equivalent flowchart representing the WAD. Figure 4 shows the WOs issuance process in BPMN.

5.2. Phase II: Requirements Elicitation

As previously stated in the introduction section, the main problem we intend to approach is the limited consideration of a socio-technical perspective in traditional techniques for requirements elicitation. In this sense, this phase aims to gain the necessary data to enhance the CISI, with a socio-technical perspective that focuses on the functional variability and results in more comprehensive requirements, which reflects the breadth and depth of the problem domain.

5.2.1. Data Collection

For this phase, some experts on the subject were interviewed: the process manager, the maintenance supervisor, one assistant, and ten requestors. The data collected in the interviews were recorded as field notes and compiled by the analyst later. The process manager contributed with information related to the basic flowchart, which was built according to BPMN, as shown in the previous section. The remainder of those data were gained from the maintenance supervisor, assistant, and requestors, who reported the everyday work related to work WO issuance. Moreover, observations helped to build the FRAM model, as detailed in the next subsection.

5.2.2. FRAM Model

The FRAM model, as shown in Figure 5, consists of twenty-three functions, which represent the WAD in the issuance of WOs for the maintenance in HVAC systems. The graph shows how the functions’ outputs (O) are used by other downstream functions, i.e., input (I), precondition (P), resource (R), time (T), or control (C), creating a link that allows variability spread among functions. Functions exhibiting performance variability have the sign of a sine wave into a hexagon. Background functions are represented as rectangles. This model shows how the functions of WOs issuing interplay with the IT system. Functions depicted in blue are functions performed by the requestor. The others highlighted in green are functions performed by the maintenance supervisor. The yellow function is performed by information technology. Functions performed by the information technology do not present variability themselves; however, the system limitations require several adjustments, which can contribute to undesirable outcomes. Functions depicted with sine wave present potential variability.

To request a service, the requestor (customer) accesses the CISI and fills in the data on the screen.

Table 1. Potential variability identified in the work order issuance for the maintenance in HVAC systems.

Nº	Function	Variability
		Regarding Time	Regarding Precision
1	Record place in CISI	On time This function does not vary regarding time	Imprecise Requestors may fill the place of service wrongly.
2	Record service in CISI	On time This function does not vary regarding time	Imprecise Requestors often describe service in an ambiguous or incomplete way because they do have not enough knowledge to describe the service properly
3	Monitor CISI for new requests	Too late The function can be impacted by delays, since the maintenance supervisor has other assignments out of the office.	Precise This function does not vary regarding precision
4	Analyze service description	Too late This function may consume some time due to adjustments to understand and clarify the service description. This scenario may entail delays in downstream functions.	Acceptable The service description may not be comprehensible by the maintenance supervisor. Then, to clarify the service description, he needs to contact the requestor.
5	Select service group	On time This function does not vary regarding time	Imprecise The unsuccessful outcome in upstream function 5 can entail an imprecise decision regarding the service group.
6	Select a working team	Too late The function triggering time often depends on the availability and qualification of technicians. This scenario submits the maintenance supervisor to trade-offs, since he needs to select an alternative technician.	Acceptable In CISI, the field for technicians’ selection does not allow the user to select more than one technician. Then, the maintenance supervisor adapts the WO form, recording the technicians’ names in the field “observation”.
7	Receive additional details and update data in CISI	Too late Using e-mails or calls to receive a reply can entail delays in downstream functions.	Acceptable Once the requestor’s answer is satisfactory, this information is enough to support the service analysis.

shows that the function “record place in CISI” has an imprecise output because the requestor may fill the place of service wrongly, which contributes to spreading disturbances in the whole process. In the same way, the function “record service in CISI” affects downstream functions, since requestors often describe the service ambiguously or incompletely because they do have not enough knowledge to describe the service properly. On this subject, when requestors were asked how they perform their task, a requestor said: “not everyone knows how to fill in the CISI data”. In addition, during the interviews, it was noted that requestors complain a lot about IT architecture. In another interview, the requestor said: “They ask to describe the type of air conditioning failure […] I don’t know how an air conditioning works. They had to send a mechanic here to evaluate the equipment”. A requestor also said that a few years ago, the maintenance workers took a long time to attend to services. In this opportunity, this requestor said: “I prefer to call the office and ask for maintenance by phone […] I don’t like using CISI”.

As shown in Figure 5, the technological function “sync data to maintenance office” receives input from functions 1 and 2 (see Table 1) and feeds the downstream function “monitor CISI for new requests”. This function controls the receiving of new requests. However, as previously disclosed in the preliminary analysis, the maintenance supervisor has other assignments out of the office, which imposes an additional time to achieve the expected result. In the absence of the supervisor, the assistant monitors the CISI and issues WOs. However, he has not the expertise to evaluate the content of the description. This often leads to an adjustment in the way in which these functions are performed. On this subject, during the interview, the assistant said: “I don’t know how to evaluate the type of failure […] I ask technicians for help or I wait for the supervisor”.

In work order issuance, the maintenance supervisor needs to resort to some adjustments during this process due to IT system limitations. For example, the interviewed supervisor reported that the requestor often describes the service in CISI ambiguously or incompletely. In this context, the maintenance supervisor needs to use their expertise and ability to ensure the issuing of WO in the shortest time possible. On this subject, the supervisor said: “If we were to follow the process through CISI, there would be no time to cope with the occurrence […] Sometimes the customer calls for urgent maintenance. I need to move teamwork to the site quickly […] some situations cannot wait a long time, like a defect in an air conditioning for an important laboratory”.

The function “analyze service description” is considered critical because it is prone to spread variability along with the maintenance working of HVAC systems. In the worst scenario, this function may receive an unsatisfying outcome from the upstream function “receive the request from customer”. Table 1 highlights the variability in terms of timing and precision and explains how output variability may lead to resonance in further steps. To damping this outcome, the maintenance supervisor requests additional information about service from the customer. However, using e-mails or phone creates lateness to receive a reply and doubt about whether the requestor received the request for clarification (see Table 1, function 7).

Furthermore, the function “analyze service description” depends on workers’ ability to evaluate the request properly. Data from interviews reveals that only the maintenance supervisor has enough expertise to carry out analysis, i.e., this analysis may not be performed satisfactorily in his absence, which can lead to an imprecise output. Therefore, this outcome affects the downstream function “select service group” (see function 5 in Table 1), inducing to select the service group in the wrong way. Consequently, this function acts as a precondition for the downstream function “select working team”. In this sense, selecting the service group in the wrong way will cause improper technicians’ allocation.

To trigger this function, the maintenance supervisor needs to engage some adjustments during task execution to fill gaps in the information technology and, thus, achieve the desired results. These adjustments are based on their expertise in maintenance activities. As described in Table 1 (function 6), this situation consumes additional time to function triggering, since it submits the maintenance supervisor to trade-offs, due to the need to select an alternative technician. For example, the qualification of each technician, (e.g., a technician trained for working at height), and the balance of workload, acting as criteria for decision-making in allocating team. In this context, the maintenance supervisor uses a spreadsheet on his computer, containing the number of WOs by each technician and the qualification of each one to decide about the team.

As previously stated in the preliminary analysis, in CISI, the field for technicians’ selection does not allow the user to select more than one technician. Then, to deal with this limitation, the maintenance supervisor adapts the WO form, recording the technicians’ names in the field “observation”. However, this scenario can lead to an imprecise output due to misunderstandings or forgetfulness in this step. This may cause further confusion in the maintenance execution.

5.3. Phase III: Requirements Specification

This study aimed to describe the functional requirements for redesigning the IT system (so-called CISI), which is used for issuing WOs for the maintenance of HVAC systems. Then, it presents a level of detail to allow the stakeholders and software developers to understand the SRS document. However, the SRS should not describe any design or implementation details.

Identification of Functional Requirements

As already addressed in the literature, functional resonance concerns the combination of the internal variability of a function with the variability of another function with which it is coupled [64]. Couplings among functions are prone to present variability. Hence, understanding each connection is important for gathering requirements in a better way. Resulting from variability analysis,

Table 2. Mitigating actions proposed for potential variability, aiming to establish requirements for redesigning the Information technology (IT) system.

Nº	Function	Variability	Potential Resonance	Mitigating Action
1	Record place in CISI	The requestor fills out specific places for service in the wrong way.	After the WO is issued, it may affect the service performance, inducing the working team to the wrong place.	Perform a survey on all territories of the R&D organization to register all units in CISI. Link each user (requestor) to the places of its operation. This action will decrease manual fills, and consequently, the incidence of fill errors.
2	Register service in CISI	In most cases, the requestor does not have enough knowledge to describe the service comprehensibly.	The incomplete and imprecise description of the service causes variability in downstream functions, because they induce errors in the task, resulting in delays in the maintenance.	Establish procedures in the CISI to facilitate the service description.
3	Monitor CISI For new requests	Competing activities of the maintenance supervisor cause delays to the visualization of service requests. Consequently, it causes a delay in issuing WOs.	May lead to a delay in starting the service.	Assign and train an employee to be responsible for monitoring the requests in the system and for closing the WOs. This action aims to release the maintenance supervisor so that he can exercise the supervisory function of the technicians’ work.
4	Analyze service description	The maintenance supervisor contacts the requestor, by telephone, because of a misunderstanding of the service description in the system.	The absence of the complementary contact causes the technician to go to the place of service without adequate information, which can cause delays in the execution and/or rework.	Modify the CISI so that the requester can provide the necessary information for maintenance. Modify CISI to create a communication channel through the system. This avoids contacts by phone or e-mail.
		Lacking analysis or improper analysis.	This situation may cause an error in choosing the service group, and consequently, selecting the working team improperly.
5	Select a working team	The working team selection depends on the availability and qualification of each professional.	Delay in the start of work resulting from the unavailability of personnel.	The system must count the WOs per professional and indicate to the administrator the amount of each to assist in the decision making of the allocation of team.

shows the variability identified in the FRAM model, the potential resonance, and mitigating actions.

This study proposes a set of mitigating actions to prevent potential resonance. Nevertheless, not all translate into requirements, since the current investigation has been focused on prioritizing the situations most affecting the maintenance performance. Additional requirements may be addressed in an upcoming study.

This study specified four functional requirements (FR), as described below. As previously stated, these requirements are resulting in mitigating actions proposed to enhance the CISI. For each requirement, we related the agent, the goal, the detailed description of the requirement, and the outcome, as detailed in

Table 3. Specification of functional requirements for the redesign of the information technology system used in the issuance of WOs for the maintenance of HVAC systems.

FR01	Access for the Requestor to the CISI
Agent	Requestor (User authorized)
Goal	Request for login and password of the requester;
Description	The system must link each requestor registered in the system to the locations of its operation; Show these locations to selection by the requestor;
Outcome	To allow access to the system.
FR02	New order for maintenance
Agent	Requestor
Goal	Access to the screen of service request;
Description	By clicking on the “new request” icon, the system must verify the existence of a WO pending final evaluation of the service by the requestor; If there are any WOs, pending final evaluation, the system must communicate this pending WO to the user; The system must display a pop-up notification window for the requester to access the pending WOs and perform the evaluation; When no WO is pending, the system may release the screen for a new request.
Outcome	Release screen of service request.
FR03	Detail of input criteria
Agent	Requestor
Goal	Specify criteria for maintenance of HVAC systems;
Description	The system must display a field with “kind of equipment” with the following selection options for the requester: Air conditioner, Refrigerator, Drinker, Freezer; When selecting the “Air Conditioning”, the system must offer the following selection options for the requester: Split or Window; The system should display a “Service Type” field with the following selection options for the requester: Installation or Repair; If the requestor selects “Installation”, the system must display the options: Do you have wiring? and Do you have a drain system? Each option should exhibit with them checkboxes YES and NO for the requestor’s choice; If the requestor selects “Repair”, the system must display the “equipment height” field with the following selection options: up to 2 m, 2 to 3 m, up to 3 m.
Description	The system must display a “Failure” field with the following options for selection by the requester: lack of refrigeration, freezing, leakage, noise, equipment does not start, cleaning; The system must display a “best service time” field for the requester to write the best option; Link the selection of air conditioning, refrigerator, freezer, or water cooler to the “HVAC” service group;
Outcome	Service criteria detailed.
FR04	Issuance of work order
Agent	Maintenance Supervisor
Goal	Analyze service criteria pointed out by the requestor and issuing work order;
Description	On the details tab, when clicking, the system must display a report with the input criteria indicated by the requestor; The system must display the technical options registered in each service group; To assign a field to fill with service requirements not detailed by the requestor, but on which the maintenance supervisor deems necessary to perform work; The system must provide, to the maintenance supervisor, a function “send to the customer”, which allows the system to notify you of any input criteria not detailed by him, but which were pointed out by the maintenance supervisor during the critical analysis. This communication can be through a message sent to the registered e-mail; The system must account for the quantity of WOs per professional and indicate (to the administrator) the quantity of each one to assist in the decision of allocation of the technicians; The system must allow the WO administrator to select multiple technicians for the work; When the system generates a WO number, it must link this number to the order number of the requestor and display it in the user area; Create a field for the signature of the evaluator of the customer’s criteria.
Outcome	Work Order issued.

.

• FR 01: Access for the requestor to the CISI
• FR 02: New order for maintenance
• FR 03: Detail of input criteria
• FR 04: Issuance of work order

6. Discussion

As per the description of the service, it can be pointed out that the requestor’s inability to describe the problem that requires a maintenance intervention is what causes the most significant effects on the maintenance of HVAC systems because it adds progressive bottlenecks throughout the work. To maintain the work performance, workers engage in several adjustments throughout maintenance, from WO issuance to service end. This explains the reason that overall effects manifest more intensely with work in progress.

In our analysis, the requestor’s inability to describe the service properly, aligned with the need for clarification to feed the WO with pertinent details, make this activity relatively difficult and dependent on additional time. In situations of great service demand, mainly of an unscheduled nature, the maintenance supervisor needs to follow these works closely. Thus, as disclosed previously, the assistants assume the activity of issuing the WOs. This situation leads to weaknesses in the WO issuance, since they do not have enough expertise to analyze the requests properly.

During the observations in the WO issuance, we noted that interruptions are common because other workers interrupt them either to gain information about services or request some tools. These disruptions make it difficult for employees to focus on evaluating incoming requests in the CISI. We also noticed that customers impose time pressure on the maintenance supervisor to attend to a request. They call the maintenance office repeatedly, requesting information about their services. Moreover, technicians deliver the spare part listing to the maintenance supervisor verbally or on an improvised sheet of paper. Several times, this resource was what the technician had at the time of work. This act may result in forgetfulness of parts or misunderstanding, and consequently, the sending of these parts to the requester in the wrong way.

The FRAM application allowed the understanding of WAD in the WO issuance and enables eliciting functional requirements for IT system redesign. Examining the FRAM representation, as shown in Figure 5, it is possible to note that FRAM provides more information when compared to BPMN representation in Figure 4. In summation, it is worthwhile highlighting that FRAM focuses on the functions of the system rather than on the components [65]; thus, it provides not only input/output sequences as a flowchart. Instead, it indicates other relevant relationships, such as resources, controls, preconditions, and temporal constraints, which are unclear in conventional modeling tools for capturing software requirements.

The investigation set out to analyze how people respond to changing conditions, including how variability might lead the system to succeed or fail, aiming therefore to elicit functional requirements to redesign the CISI. However, this study has some limitations. This study exclusively focuses on WO issuance for maintenance in HVAC systems. Although the maintenance of HVAC systems represents an important sample in building maintenance, the participation of only one maintenance type constitutes a major limitation in this investigation. Our findings cannot be generalized to the DBM as a whole. It needs to be extended to the whole DBM to gain additional insights by considering details in the various maintenance types within the DBM.

In terms of analysis, this study has focused on engaging with requestors and the maintenance office workers; however, upcoming research could look at the perspective of other actors who interact with the IT system, e.g., quality manager and IT support, who may point out different functions and features in the IT system. Lastly, the application of FRAM is structurally simple but, due to its theoretical grounding, it requires an initial learning period, summed to a time-consuming application.

7. Conclusions

The research question that motivated this research was how functional variability understanding in the issuance of WOs contributes to the requirements elicitation and specification for the design and enhancement of IT systems that support complex socio-technical systems. This study considered three relevant situations to carry out the redesign of a web-based platform that aims at computerizing requests for building maintenance at R&D territories. The first situation is regarding the service record. The second situation concerns selecting the working team. Finally, the third concerns the WO prioritization. Although three situations were identified, this study focused on the first situation, which is regarding the service description by the requestor, once it was diagnosed as the causal situation most affecting the maintenance performance.

Mainly in socio-technical systems, typical approaches to elicit and specify software requirements are not always sufficient to correctly understand the complexity of IT devices or to anticipate likely error situations. Therefore, this exploratory and empirical study provided a deeper understanding of how the FRAM model can contribute to requirements elicitation and specification. The usefulness of the proposed methodology was demonstrated through a case study in the issuance of WOs for the maintenance of HVAC systems. This study used principles from HFE and Resilience Engineering concepts, mainly regarding the understanding of the variability in complex socio-technical systems. Thus, seeking to describe the WAD as a realistic vision of the process, this approach allowed eliciting and specifying functional requirements for improvement in the IT system. However, this study did not intend to detail the non-functional requirements of the system, which may be addressed in an upcoming study.

Regarding the adopted methodology, the FRAM model was adequate for the research proposal, because it aimed to understand WAD in the context of the study. This study contributes to the development of Software Engineering for application in the work environment. The FRAM model enables us to make inferences from hidden or fuzzy situations that are often not expressed by users of the system or are not detected by the system designer. This study has made evident the need for other studies in the area, allowing the analysis of how the FRAM method can improve the software requirement specifications. Even though the current study has been capable of accomplishing its primary aim, there are suggestions and recommendations for further studies that attempt to improve and broaden this research field. This study may be helpful for other researchers who want to apply the proposed framework for other maintenance types rather than HVAC systems. Moreover, to validate the overall effectiveness of eliciting software requirements with the lens of HFE and resilience engineering, it could be applied in other complex domains, such as healthcare, aviation, and so forth. Finally, we expected that stakeholders in software design and system engineers may use this study to integrate HFE and Resilience Engineering concepts into the design of software as a standard practice.