Journal of Software Engineering Research and Development, 2021, 9:11, doi: 10.5753/jserd.2021.1892 This work is licensed under a Creative Commons Attribution 4.0 International License. A Requirements Engineering Technology for the IoT Soft- ware Systems Danyllo Valente da Silva [Federal University of Rio de Janeiro | dvsilva@cos.ufrj.br] Bruno Pedraça de Souza [Federal University of Rio de Janeiro | bpsouza@cos.ufrj.br] Taisa Guidini Gonçalves [Federal University of Rio de Janeiro | taisa@cos.ufrj.br] Guilherme Horta Travassos [Federal University of Rio de Janeiro | ght@cos.ufrj.br] Abstract Contemporary software systems (CSS) – such as the internet of things (IoT) based software systems – incorporate new concerns and characteristics inherent to the network, software, hardware, context awareness, in- teroperability, and others, compared to conventional software systems. In this sense, requirements engineering (RE) plays a fundamental role in ensuring these software systems' correct development looking for the business and end- user needs. Several software technologies supporting RE are available in the literature. However, many do not cover all CSS specificities, notably those based on IoT. This paper presents RETIoT (Requirements Engineering Technology for the Internet of Things-based software systems). It aims to provide methodological, technical, and tooling support to produce IoT software system requirements document. In addition, it comprises an IoT scenario description technique, a checklist to verify IoT scenarios, construction processes, and templates for IoT software systems. A feasibility study was carried out in IoT system projects to observe its templates and identify improve- ment opportunities. The results indicate the feasibility of RETIoT templates' when used to capture IoT characteris- tics. However, further experimental studies represent research opportunities, strengthen confidence in its elements (construction process, techniques, and templates), and capture end-user perception. Keywords: Software Engineering, Requirements Engineering, Internet of Things, IoT Software Systems, Software Systems Specification, Software system requirements document, Software technology 1 Introduction Contemporary software systems, such as those inherent to the Internet of Things (IoT) paradigm, are complex com- pared to conventional software systems. This complexity comes from the inclusion of new concerns and characteris- tics related to network, software, hardware, context aware- ness, interface, interoperability, and others (Motta et al., 2019a) (Nguyen-Duc et al., 2019). IoT-based software systems seek to promote the interlace- ment of technologies and devices that, through a network, can capture and exchange data, make decisions, and act. With these actions, they unite the real and virtual worlds through objects and tags. However, building IoT software systems is not a trivial activity due to its specific technolog- ical characteristics. It requires adapted and/or innovative software technologies to create and guarantee the quality of the built product (Motta et al., 2019a). The quality of contemporary software systems' develop- ment depends on software technologies that respond to these systems' new concerns and characteristics. As with any other product built on engineering principles, a key activity in de- veloping IoT software systems is constructing the require- ments document. Defects present in the requirements docu- ment can cause an increased time, cost, and effort for the project; dissatisfied customers and end-users; low reliability of the software system; a high number of failures; among others (Vegendla et al. 2018) (Arif et al. 2009). Requirements engineering (RE) is responsible for the life cycle of the requirements document. It ensures its proper construction (Vegendla et al. 2018) (Pandey et al., 2010). The RE phases and activities may differ according to the ap- plication domain, people involved, processes, and organiza- tional culture. However, we can observe some recurring phases and RE activities, such as conception/design, elicita- tion, negotiation, analysis, specification, verification, valida- tion, and management. The technical literature presents several software technol- ogies to support RE for software systems. However, not all of them cover the different RE phases and, mainly, IoT soft- ware systems' specificities. In this work, the term "software technology" refers to the methodological, technical, and tooling offered by the works to support the construction of requirements document for IoT software systems. Considering the need for appropriate software technolo- gies to develop IoT software systems and understand the im- portance of requirements document for the stability, ade- quacy, and quality of a project, this work proposes the RETIoT (Requirements Engineering Technology for the In- ternet of Things software systems). The RETIoT consists of a requirements specification tech- nique based on IoT scenarios description - SCENARIOT (Silva 2019), an IoT scenario inspection technique - SCE- NARIOTCHECK (Souza 2020), a construction process, and templates to support the processes activities and build the re- quirements document. The SCENARIOT and SCENARIOTCHECK techniques were previously evaluated through experimental studies, which indicated their feasibility (Souza et al. 2019a) and use- fulness (Souza et al. 2019b). Moreover, they have been used in IoT software system projects developed by the Experi- mental Software Engineering (ESE) Group in the context of DELFOS – The Observatory of Engineering Contemporary Software Systems – COPPE/UFRJ. Based on the experiences with these projects, the construc- tion process and templates of RETIoT evolved. This article extends a previous publication of RETIoT (Silva et al. 2020b). The first version (Silva et al. 2019) encompasses many RE activities. It focuses on the definition of Project scope, IoT system, and IoT system requirements. The second version (Silva et al. 2020b) focuses on eight RE phases: Conception, IoT elicitation, IoT analysis, IoT specification, IoT verifica- tion, Negotiation, Validation, and Management. The tem- plates of this version are evaluated through a feasibility study https://orcid.org/0000-0002-1026-1189 https://orcid.org/0000-0002-1502-7703 https://orcid.org/0000-0002-7108-1763 https://orcid.org/0000-0002-4258-0424 A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 (section 4). The third version (Silva et al. 2020a) involves the different RE phases through an engineering cycle divided into eight phases: IoT ideation and conception, IoT elicita- tion, IoT analysis, IoT specification, IoT verification, Nego- tiation, IoT evaluation, and Management. Their templates are evaluated through a proof of concept. The fourth and cur- rent version of the technology includes improvements in the construction process and templates. Optional activities and tasks were analyzed and incorporated into the construction process. The focus and perspective of the process were changed to IoT product and project, including product idea- tion and evaluation concepts. Also, the engineering cycle was compacted to simplify the construction process that in- cludes four phases instead of eight of the third version. The templates were evolved in the current version to include the gaps and improvements identified during the proof of con- cept (Silva et al. 2020a). For the sake of completeness and applicability, this paper presents the current (fourth) version of RETIoT, including a feasibility study comparing three RETIoT templates with reg- ular ones used to build requirements document for conven- tional software systems. The results indicate that RETIoT templates allow capturing the information needed for IoT software systems and that they are mature to be evaluated in constructing such requirements document. Furthermore, it is also possible to observe that the technology covers the main RE phases and activities concerning IoT-based projects. Beyond this introduction, this article presents six other sections. Section 2 describes the technological basis of the RETIoT. Next, Section 3 introduces and details the RETIoT. Section 4 demonstrates the feasibility study. Section 5 pre- sents some related works found in the literature. Section 6 discusses some research opportunities. Finally, section 7 presents future work and concludes the article. 2 The Technological Basis of the RETIoT This section presents the technological basis used to build the RETIoT to support RE in IoT software systems. Such a requirements technology is inserted in the context of a sys- tems engineering approach, which concerns the major devel- opment stages of IoT software systems (Motta et al. 2020). Its technological basis is composed of two empirically eval- uated techniques, the SCENARIOT and SCENARIOTCHECK techniques. 2.1 SCENARIOT Conventional software scenarios can be used in any software system and development stage. They can cover different pur- poses, such as eliciting requirements, specifying require- ments, validating requirements, and testing (Glinz 2000) (Behrens 2002) (Alexander and Maiden 2004). A scenario is a sequence of events describing the system behavior and its environment (Burg and Van de Riet 1996) or an ordered set of interactions between partners - usually systems and exter- nal actors (Glinz 2000). It represents requirements through stories describing the system from the users' perspective when applied to requirements engineering (Glinz 2000) (Al- exander and Maiden 2004). Scenarios offer many advantages: they are based on the users' point of view; ii) the possibility to carry out partial specifications; iii) easy to understand; iv) enable short feed- back loops; and v) provide a basis for testing the system (Glinz 2000). Thus, scenarios constitute a good basis for communication with clients and laypeople (non-technical) because they can be easily understood and do not require prior understanding. Therefore, everyone involved at differ- ent levels and functions can express opinions and identify problems (Glinz 2000) (Behrens 2002) (Alexander and Maiden 2004). The SCENARIOT (Silva 2019) is a specification technique that adapts conventional scenarios to support IoT software systems' specifications. It considers the characteristics (adaptability, connectivity, privacy, intelligence, interopera- bility, mobility, among others) and behaviors (identification, sensing, and actuation) specific to these software systems (Motta et al., 2019b). The combination of characteristics and behaviors led to the creation of nine IoT Interaction Arrange- ments (IIAs). IoT interaction arrangements represent frequent interac- tion flows between things and other non-IoT elements, such as conventional software systems and end-users. Each IIA has a catalog containing all relevant information captured and used in the scenario's description. The cardinality for ar- rangements and scenarios is a many-to-many relationship (M:N). Therefore, many arrangements (isolated or com- bined) relate to one or more IoT scenarios. An IoT scenario can be linked to one or more arrangements. The IIAs, together with their catalogs, guide software en- gineers to capture essential information about the system: i) identification of the "things" and system components; ii) the types of data that will be collected and displayed; iii) the ac- tions that will be performed in the environment; iv) aspects related to decision making on a particular system context; v) the actors (end-users, software systems, things, among oth- ers) who will access the data; among others. Figure 1 shows the "IIA-1: Display of IoT data" arrangement and its catalog. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Figure 1. "IIA-1: Display of IoT data" arrangement (Silva 2019). 2.2 SCENARIOTCHECK The SCENARIOTCHECK is a checklist-based software in- spection technique specialized in verifying IoT software sys- tem scenarios (Souza 2020). This technique aims to assist inspectors in detecting defects in IoT scenario descriptions, guaranteeing their quality. It was created to work together with the SCENARIOT technique since it produces the input to SCENARIOTCHECK. The SCENARIOTCHECK checklist consists of two parts. The first part (general questions) aims to identify defects re- lated to project information and systemic solution such as i) problem domain; ii) interaction and identification among ac- tors, system, hardware, and devices; iii) alternative and ex- ception flow; among others. Table 1 shows the first part of the questionnaire. Table 1. Questions on the SCENARIOT Specification Technique. G e n e r a l Q u e s ti o n s Nº Question 01 Has the overall application domain been established? (Health, leisure, traffic) 02 Is the specific purpose of the system correctly described? (Data visualization, decision making, and/or actuation only) 03 Is the type of data collected specified? (Temperature, humidity, pollution, and so on) 04 Is it possible to identify who or what collects the data? (Sensors, QR code readers, and so on) 05 Is it possible to identify who or what manages the data collected? (Administrator, decision-maker, users, and so on) 06 Is it possible to identify who or what accesses the data collected? (Things, software systems or users) 07 Is the user interface device that displays the data described? (dashboard, smartphone, tablet, and so on) 08 Is it possible to identify who is viewing the data? (Things, software systems, users, and so on) 09 Is it possible to identify the source from which the data is provided? (Chairs, table, automobiles, houses, buildings, and so on) 10 Are the roles involved in the system described? (Things, software systems, users, and so on) 11 Is there any description of each actor in the specified scenarios? 12 Is it possible to identify the source of data provision? 13 Has each action within the scenario been described clearly and contains no extraneous information? 14 Is there a sequence of ambiguous actions in the scenarios? 15 Are the actors described in the scenarios consistent with the actors described in the arrangements? (Things, soft- ware systems, users) 16 Are the scenarios related to the arrangements consistently? 17 Do the scenarios seek to be accurate by presenting title and flows? (Presenting the purpose and actions of the sys- tem directly and explicitly) 18 Are adverbs avoided in order not to generate more than one possibility of interpretation in the scenarios? (proba- bly, possibly, supposedly) 19 Are the condition terms (such as "if", "go to", "while") used correctly? 20 When you use words like "things" "data" in the scenario, do they have the same meaning in other parts of the same scenario? 21 Is it possible to identify "things" described with a function in the arrangements representing another function in the described scenarios? 22 Are the alternative and/or exception flows described? 23 Does the scenario specification identify the matching ID arrangement? (AII1, AII2, ..., AII9) The second part (specific questions) considers the non- functional properties (IoT facets) of IoT software systems discussed in (Motta et al. 2019a). Table 2 presents the ques- tions of the second part of the SCENARIOTCHECK check- list. Table 2. Questions on IoT Facets. S p e c if ic Q u e s ti o n s Nº Question 24 Is it possible to identify the specific context in which the system is embedded? (Smart room, smart greenhouse, au- tonomous vehicle, healthcare, and so on) 25 Are the limitations of the environment described? (e.g., lack of connectivity structure, lack of hardware structure, inadequate infrastructure) 26 Are the technologies associated with system objects de- scribed? (smartphones, smartwatches, wearables) 27 Are the events that the system has identified? (e.g., on/off an object, sending data) 28 What kind of communication technology does the system use in the scenarios? (Bluetooth, intranet, internet ...) 29 Does the proposed communication technology meet the geographic/physical specifications of the system? (Large, medium or small scale) 30 Is it possible to identify how the system will react ac- cording to changes in the environment? 31 Are the interactions between the system and the environ- ment represented in the scenarios? 32 Is it possible to identify the interaction between actors? After specifying IoT scenarios, the inspectors can apply the SCENARIOTCHECK technique to verify the scenario de- scriptions. The identified non-conformities are described in the inspection report. Finally, after the discrimination meet- ing (defects identification), the IoT scenario specification document is corrected. The application process of the two techniques is shown in Figure 2. The SCENARIOTCHECK complements SCENARIOT by providing a template for IoT scenarios specification. This template resembles a use-case description document with some additional fields: i) identification of the IoT software system elements; ii) problem domain description, iii) role description of each actor involved in the scenario; A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Figure 2. Application process of SCENARIOT and SCENARIOTCHECK techniques (Souza et al. 2019a). and iv) descriptions of the interaction between the actors (end-user, things, software system, others) and the IoT soft- ware system. 3 The RETIoT The RETIoT (Requirements Engineering Technology for the Internet of Things based software systems) comprises the techniques described in section 2, a construction process, and templates to build requirements document following RE principles. The requirements document's construction process is based on the main RE phases (Pressman and Maxim 2014) (Sommerville 2015): conception/design, elicitation, analy- sis, specification, negotiation, verification, validation, and management. However, the RETIoT adapts and includes new activities to meet the specificities of IoT software systems. 3.1 Construction process The current version of the technology encompasses product ideation, evaluation concepts, such as low- and high-level prototypes, and MVPs' creation (Minimum Viable Product) for the desired product. In addition, the construction process incorporates aspects and characteristics found in the litera- ture review inherent to IoT software systems. It also involves the different RE phases (Pressman 2014) (Sommerville 2015) through an engineering cycle divided into four phases: IoT ideation, conception, elicitation; IoT analysis and specification; IoT negotiation and evalua- tion; and Management. Figure 3 presents an overview of the construction process engineering cycle with two dimensions: main and transver- sal (performed in parallel). The main dimension corresponds to the activities and tasks required to build the IoT require- ments document. Figure 3. Construction process overview - phases. The transversal dimension (see Figure 4) offers three man- agement activities, and tasks focused on artifacts and process management. The activities and tasks do not have a specific and determined time to be performed. Instead, everything de- pends on the need identified by the user through the main process flow. The technology proposes version control of the artifacts and traceability between requirements, IoT scenarios, IoT interaction arrangements, and IoT use cases in the manage- ment phase. Besides, RETIoT offers change management so that modifications in requirements can be reflected in the generated artifacts. The IoT requirements document construction is performed iteratively and incrementally. Thus, the engineering cycle is executed three times, where each execution is called a stage. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Figure 4. Management phase overview. 3.2 Construction process stages Each stage performs the common phases (see Figure 3 and Figure 4) of the engineering cycle generating intermediate artifacts. The result of Stage 3 is the IoT requirements docu- ment. However, each stage has specific objectives, activities, and tasks. The construction process can be executed for one idea or a set of requirements (see Figure 5). In the first case, the process execution is an intermediated version of the IoT requirements document. Also, the construction process can be adapted to be used in different contexts. For example, we can apply this proposal with any development methodolo- gies. Regarding projects that use an agile methodology, IoT Use cases could be not applicable and demand more cost and ef- fort. In these contexts, IoT Use cases cannot be mandatory, and the activities and tasks that support build them can be skipped. However, on the other hand, it can cause positive impacts (decrease time and effort) and negative (absence of important information). Therefore, the user of the process needs to evaluate these impacts. Besides, the current RETIoT version integrates ten tem- plates – eight of them are defined/adapted from the project templates currently used in projects of the ESE group/PESC/COPPE and other templates used in software engineering group/PESC/COPPE. In addition, two of them were defined by the SCENARIOTCHECK technique (Souza 2020). Figure 6 shows an overview (IDEF0 diagram) of the three stages with their inputs, outputs, templates presented in the next paragraphs, and controls - Management procedures and Feasibility strategy. The Management phase performs the management procedures. The Feasibility strategy represents the milestone of each Stage. 3.2.1 Stage 1 The first stage is to understand the problem. Then, it aims to understand the problem or opportunity, analyze the stake- holders and their needs, elicit the business needs, and carry out the project feasibility analysis. It is composed of 12 ac- tivities and 27 tasks that are distributed throughout the engi- neering cycle. Figure 7 presents an overview of the activities performed in the first stage. This stage offers three templates: IoT Can- vas, IoT Project Feasibility Analysis, and Requirements Checklist. Its milestone is the Feasibility Analysis per- formed by four activities (Analyze market demand, Analyze economic feasibility, Analyze impact and risks, and Analyze technical feasibility). Figure 5. Construction process overview - stages A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Figure 6. IDEF0 diagram of the three stages Figure 7. First stage - Overview of the construction process. 3.2.2 Stage 2 The second stage is to describe the solution. It aims to trans- form business needs, stakeholders' needs, and general re- quirements into detailed, classified, and organized require- ments. IoT scenarios, arrangements, and components are used for the specification and verified during this stage. Subsequently, the requirements are negotiated and evalu- ated, attesting that a common understanding of the system has been reached. This stage is composed of 12 activities and 39 tasks that are distributed throughout the engineering cy- cle. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 The SCENARIOT technique (Silva 2019) supports the re- quirements identification and the system behavior descrip- tion. This technique is executed during the following activi- ties: Define IoT scenarios and Specify IoT scenarios. Figure 8 presents an overview of the activities performed in the second stage. This stage defines three templates: IoT Project Detail, IoT Solution Proposal, and Change Anal- ysis Report. The SCENARIOTCHECK technique (Souza 2020) con- tributes with two templates (Verification Checklist Template and Inspection Record Template) used in this stage during Verify IoT scenarios activity. Its milestone is the Low-level Prototype performed by the activity "Define low-fidelity prototype." This stage pre- sents optional activities since the construction process can be used with any development methodology. 3.2.3 Stage 3 The third stage is to Detail the solution. It transforms IoT requirements and scenarios into IoT Use Cases. The IoT Use Cases diagram, the list of IoT Use Cases, and their descrip- tions are generated during this stage. Subsequently, the generated artifacts are checked and evaluated, attesting that a common understanding of the sys- tem has been achieved. This stage is composed of ten activ- ities and 24 tasks distributed throughout the engineering cy- cle. Figure 9 presents an overview of the activities performed in the third stage. Two templates are defined for it: IoT Use Case Description and IoT Diagram and Use cases Check- list. Also, the Change Analysis Report can be used in this stage. This stage's milestone is the High-level Prototype performed by the activity "Define an evolved prototype." This stage presents optional activities since the construction process can be used with any development methodology. Figure 8. Second stage - Overview of the construction process. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Figure 9. Third stage - Overview of the construction process. 4 Evaluating the RETIoT's Templates Feasibility The RETIoT aims to support software engineers during the RE activities. The main techniques presented in section 2 and used to compose the software technology have already been empirically evaluated and used in IoT software system projects (Souza et al. 2019a) (Souza et al. 2019b). However, new facilities' inclusion to support the RE with the RETIoT requires an initial observation before using them in the pro- jects and conducting further experimental studies. Thus, this section presents a feasibility study of the RETIoT templates. 4.1 Templates In this feasibility study, we considered the structure of two artifacts' templates – Requirements List (RL) and IoT use- cases Description (IoTUCD1) – for conventional software systems but used in IoT software system projects. We com- pared their structure with the structure of the RETIoT tem- plates – Project Scope (PS), Solution Proposal (SP), and IoT use-cases Description (IoTUCD2). The full versions of all templates are available at http://bit.ly/393SgHX. http://bit.ly/393SgHX A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 4.1.1 The RETIoT Templates This section presents three RETIoT templates (Silva et al. 2020b) regarding the activities of elicitation (ELI) – "Pro- ject Scope (PS)" Template (see Figure 10); analysis (ANA) and specification (SPE) – "Solution Proposal (SP)" Tem- plate (see Figure 11) and "IoT use-cases Description (Io- TUCD)" Template (see Figure 12). The conception/design (CON), negotiation (NEG), and validation (VAL) activities are minimally covered by the "Project scope" Template. The "Solution Proposal" and "IoT use-cases Description" templates support the management (MAN) activities, main- taining traceability between requirements and analysis mod- els. Besides, the techniques described in section 2 support the elicitation (ELI), specification (SPE), and verification (VER) activities. The following items will present the tem- plates' global description (Project Scope, Solution Proposal, and IoT use-cases Description) as defined in the RETIoT. • Project Scope Template This template supports the documentation of the project's in- itial activities, the problem to be solved, those involved in the project, the user profiles, user needs, and business needs. In addition, it includes identifying and describing system re- quirements (functional, non-functional, restrictions, others) and business rules. Figure 10. Extract from the "Project Scope template." Also, the requirements document's validation is made through an explicit agreement (signature or email copy). Fi- nally, it provides two (status and priority) fields to support the negotiation of functional and non-functional require- ments. Figure 10 presents an extract of this template. The pro- posed template is used in the activities of conception/design (CON), elicitation (ELI), negotiation (NEG), and validation (VAL). • Solution Proposal Template This template supports the solution description. It identifies and describes, using the SCENARIOT technique, the IoT sce- narios, the IoT components, and the IoT interaction arrange- ments (IIAs) of the system. Also, it provides the details of the IIAs chosen for each IoT scenario via the corresponding catalogs. Thus, the trace- ability between requirements, IoT scenarios, IoT interaction arrangements, and their respective catalogs is maintained. Figure 11 presents an extract of this template. It should be used in the elicitation (ELI), analysis (ANA), specification (SPE), and management (MAN) activities to identify, de- scribe and refine the system's behavior while maintaining re- quirements traceability. Figure 11. Extract from the "Solution Proposal template." • IoT use-cases Description Template This template includes the description of the IoT use-cases. Use cases are identified and described providing a view of the system's behavior. In addition, the use-case diagram is inserted in this template. Traceability between requirements, IoT scenarios, IoT in- teraction arrangements, and IoT use-cases is maintained. Figure 12 presents an extract of this template. It should be A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 used in the analysis (ANA), specification (SPE), verification (VER), and management (MAN) activities. The SCENARIOTCHECK technique is applied during the verification activities to identify inconsistencies in the IoT scenarios description and their components and the choice of IIAs. Figure 12. Extract from the "IoT use-cases Description template." 4.1.2 Projects and Teams The RL and IoTUCD1 artifacts were built by using conven- tional templates in three (3) IoT based software projects: • Project A supports environmental markers' collection (e.g., temperature, humidity, particulates, CO2 level, and toxic gases). • Project B monitors a high-performance computing en- vironment (data center) to collect different information such as temperature, humidity, energy consumption, and energy supply quality. • Project C collects temperature, humidity, wind speed, and wind direction in different city regions. All three projects represent real demand. A stakeholder (totally external to the course and the research group) worked with the developers, including the requirements ac- ceptance. Undergraduate students produced the RL and Io- TUCD1 artifacts during a Software Engineering course at UFRJ. The course had the participation of 21 students of the fourth year of Information and Computer Engineering. The subjects were organized into three development teams, with seven participants each. The teams contained balanced participants with equivalent levels of knowledge and skills regarding software and hardware. Training on dif- ferent topics in Software Engineering and mentoring throughout the project were available. There was no inter- vention by the mentors in the artifact's content. All ethical issues and consent forms were made available. Some of the course's topics included requirements engi- neering, IoT scenarios, verification technique for IoT sys- tems, UML (Unified Modeling Language) diagrams, among others. In addition, the SCENARIOT and SCENARI- OTCHECK techniques were presented to the participants, alt- hough they were not conditioned to use them. The teams were free to organize their projects. The re- quirements document represented one of the design mile- stones. A minimum viable product (MVP) represents one of the concrete results delivered at the end of the course. 4.2 Execution The researchers (paper's authors) analyzed the requirements document (RL and IoTUCD1 artifacts) after the three teams constructed them. The information found in the generated artifacts was com- pared with the requested information in the Project Scope (PS), Solution Proposal (SP), and IoT use-cases Description (IoTUCD2) templates structure. A working checklist was used to compare the templates, which will be presented in the next subsection. Three researchers carried out the comparison – two mas- ter's students and one Ph.D. that work in Software Engineer- ing and IoT domains. After that, a fourth researcher (Ph.D. and expert in Software Engineering and IoT domains) re- viewed the analysis of the results. 4.3 Results and Discussion Table 3 presents the checklist used to compare the template structure (conventional and RETIoT) and the analysis result. It indicates that: • The RL template does not address the project/system ob- jective and problem domain. However, knowing the problem domain is essential for building an IoT software system (Motta et al. 2019) (Nguyen-Duc et al., 2019). • The RL template presents a partial description of the stakeholders. However, it does not include profiles de- scriptions of the different users important for the system development and the user interface design. • The RL template does not address the description of business/stakeholder needs. The identification of busi- ness/stakeholder needs represents the initial stage of the project. In this step, we seek to understand the client's real need, which will be transformed into system require- ments in the future. • RETIoT allows identifying the requirements that will guide the IoT solution from the beginning (Project Scope template), unlike the RL template that does not identify the IoT requirements. Table 3. Mapping checklist of the template structure. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Project/system information Conventional templates RETIoT templates RL IoTUCD2 PS SP IoTUCD2 Project name/Project responsible T T T T T Version control T T T T T Explicit agreement T T Project/system objective N T Problem domain N T Project scope T T Glossaire T T Stakeholders description P T Business and Stakeholders needs a description N T Functional requirements P T Non-functional requirements T T Requirements negotiation (prioritization) T T Business rules N T T T Project analyses N P IoT scenarios P T IoT components description N T T IoT interaction arrangements P T T IoT use-cases diagram N T IoT use-cases description N T Requirements traceability P - P T References (others project documents) T N P - Partially collected; T - Totally collected; N - Does not collect information; Gray - Not applicable for this template. • The IoTUCD1 template treats IoT scenarios and IoT ar- rangements partially but does not address IoT compo- nents' description. In contrast, the RETIoT treats this in- formation entirely in the Solution Proposal (SP) and IoT use-cases Description (IoTUCD 2) templates. • Conventional templates are not treat the IoT use-cases diagram and IoT use-cases description, but RETIoT fully treats them. • The requirements traceability is partially treated by the IoTUCD1template, partially treated by RETIoT in SP template, and fully treated IoTUCD2 template. • The RL template presents a field for references (other documents), which RETIoT does not address. The different convergence and divergence points between conventional systems templates (RL and IoTUCD1) and RETIoT templates (PS, SP, IoTUCD2) offer indications that the RETIoT can be more robust because it deals with IoT in- formation since the beginning of the project According to the results, RETIoT can present (Silva et al. 2020a) (Silva et al. 2020b) a good potential for supporting IoT software systems' specifications because of its templates' specific IoT information, differently from conventional ones. 4.4 Templates' evolution This study allowed us to evolve the existing templates re- garding the reorganization of sections and insert new sec- tions and new fields. First, we identified the lack of infor- mation and redundancies on templates. Then some fields were added, moved, or removed. Besides that, we started to think about MVP and prototypes applied on IoT projects that caused changes in some templates, and we added the "IoT Canvas" template to the technology. In the second version, we started to think about require- ments negotiation, reuse, and traceability. Consequently, we identified the need to insert new fields to attend to these points better. Also, the templates of the second version did not cover the project feasibility and requirements verifica- tion. It is because the technology does not cover these points. To fill these gaps, we propose "Project Feasibility Analy- sis," "Requirements Checklist," and "IoT Diagram and Use cases Checklist" templates. At least, we identified the need to register and track requirements changes. The second ver- sion presented activities and tasks to support it, but no tem- plate was defined. In that sense, one more template, named "Change Analysis Report," was defined to support these ac- tivities. In addition, the Project Scope template was re- named to IoT Project Detail and the Solution Proposal template to IoT Solution Proposal. In the IoT Project Detail template, we included a new field, "Project description." The "Glossary" and "Stakehold- ers" sections have been changed to include fields to support the capturing of specific information. The "Potential stake- holders" section has been changed to "Stakeholders" to in- clude two new fields to capture each stakeholder's interest and its influence in the system. The "Project scope" section has been removed from the template. The "Canvas IoT" sec- tion was added, allowing the insertion of an image or photo of the IoT Canvas built in Stage 1. New fields ("Reused requirement?" and "Related require- ment ID") have been added to the "System requirements" section to enable requirements traceability (functional and non-functional). In addition, for functional requirements, two fields ("Cost" and "Effort") were added to make negoti- ation feasible. In its previous version, requirements were classified into IoT requirements and non-IoT requirements. In this new version, this classification has been removed, and the "IoT Characteristic" field has been included. Therefore, when describing a non-IoT requirement, this field should not be filled. Instead, the IoT characteristic must be described as identification, sensing, performance, connectivity, and pro- cessing in an IoT requirement. In addition, the "Dependency A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 between requirements" field has also been added to the "Functional requirements" section. The non-functional requirement "scalability" was added to the new template. The requirements "portability and com- patibility" and "security and privacy" have been adapted. The section "Annex - Non-functional requirements" has been added to support the identification of non-functional re- quirements. The section "Scope not covered by the project" has been added, and the section "Project analysis" has been removed. In the "Business rules" section, the "Related needs ID" field has been added to allow business rules' traceability. In the IoT Solution Proposal template, the fields "Ac- tors," "Actions," "Interaction Arrangements" were added in the "IoT Scenarios" section. The section "IoT system com- ponents" was removed because it had a redundancy of the arrangement catalogs' information. The "Related functional requirements," "Precedencies," and "Dependencies" fields have been added in the "IoT scenarios description" section to enable the traceability of IoT scenarios. The field "Col- lected data and Actions performed" was divided into two fields: "Collected data" and "Actions performed." The "In- teraction sequence" field was changed because it is like a use-case structure (main, alternative, and exception flows). Finally, the "Environment" and "Connectivity" fields have been removed. In the IoT use-cases Description template, the "Business rules" field was moved from the "Interaction sequence" sec- tion to a separate section. In addition, the section "Customer or customer representative agreement" has been added to this template. Five new templates were also defined to support the con- struction process activities that had not yet been contem- plated. The new models (see section 3) correspond to IoT Canvas, IoT Project Feasibility Analysis, Requirements Checklist, Change Analysis Report, and IoT Diagram and Use cases Checklist. Table 4 shows each change and the rationale for them. However, to ensure the technology validity, further exper- imental evaluation is necessary to verify whether the RETIoT construction process with the templates is useful, complete, correct, and intuitive. 4.5 Threats to Validity Internal validity is the study itself, even though experi- mental studies have evaluated part of the RETIoT technol- ogy. However, the results indicate that the RETIoT templates can capture relevant information than conventional tem- plates regarding project artifacts. An external validity issue concerns the participants (un- dergraduate students) who have been invited to participate in the study. We cannot claim that the information provided is complete from the project's point of view, nor did the partic- ipants understand all the topics taught during the course. To mitigate this threat, the projects treated in the study repre- sented real problems. Besides, each team had contact with a stakeholder of each addressed problem. There was no control over the artifact's creation during the course and used in the study regarding their construct valid- ity. However, the projects were equivalent in size, complex- ity and used IoT technologies to mitigate this threat. Also, it can be highlighted that the teams received equivalent train- ing and mentoring in RE. Finally, the conclusion validity concerns the study inter- pretation and sample size. We had a small and inhomogene- ous sample size. Therefore, it was impossible to apply statis- tical tests to carry out a deeper analysis of the results ob- tained. Also, the study conclusion is limited to the research- ers' interpretation. These items limit the study results gener- alization. To mitigate this threat, we aim to perform future experimental studies to collect feedback from the RETIoT. 5 Literature analysis 5.1 RE phases This section presents related works found in the technical lit- erature, which address technologies for the different RE phases mentioned above. Table 5 presents a comparison of seventeen (17) technologies found in the technical literature. We can observe that conception, negotiation, verification, validation, and management phases need more attention re- garding IoT concepts and characteristics. Figure 13 synthesizes the information presented in Table 5, showing the number of technologies per RE phase. Again, we can highlight that a high number permeate elicitation (nine), analysis (ten), and specification (eight) phases. In contrast, a small number is concentrated in the concep- tion/design (four), negotiation (one), verification (five), val- idation (three) and management (three) phases. Figure 13. Technologies x RE phases. Regarding the conception phase (CON), GSEM-IoT (Zambonelli 2017) (Laplante et al. 2018) and Ignite (Giray et al. 2018) technologies carry out the stakeholders' analysis involved in the system. In addition, the feasibility analysis is partially addressed by IoT Methodology (Giray et al., 2018). Also, the Ignite and CORE (Hamdi et al. 2019) technologies provide business analysis mechanisms. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Table 4. Templates' evolution. Template name Previous element New element Change description Rationale IoT Project Detail - Project description. Included new field Allow getting a simple and brief description of the project. Glossary and Stakeholders - Included fields to support the capturing of specific infor- mation Enable to capture specific information about terms used in the project and stakeholders. Potential stakeholders Stakeholders Change section name and included two new fields to cap- ture interest and influence Simplify this section and capture more data about the stakeholders. Project scope - Removed from the template Allows avoiding redundancy. The described requirements can identify the project scope. - Canvas IoT Included new field Allow the insertion of an image or photo of the IoT Canvas built in Stage 1 - Reused requirement? And Related require- ment ID Included new field added to "System requirements" section Enable requirements' reuse and traceability. - Cost and Effort Included new field Make negotiation feasible. IoT requirements and non- IoT requirements IoT Characteristic (only to IoT requirements) This classification has been removed, and the "IoT Charac- teristic" field has been included Simplify this section and enable to capture identification, sensing, perfor- mance, connectivity, and processing characteristics on requirements. - Dependency between requirements This field has also been added to the "Functional require- ments" section Enable requirements' traceability. - Non-functional requirements "scalability", "portability and compatibility" and "secu- rity and privacy" The section has been improved This field's description of this section has been adapted and improved to at- tend IoT systems better. - Annex - Non-functional requirements Included new section Support the identification of non-functional requirements. - Scope not covered by the project Included new section Enable to capture and describe the Project analysis - The section has been moved to another template A new template (IoT Project Feasibility Analysis) has been created. As a re- sult, the information presented in this section has been adapted and moved to a specialist template. - Related needs ID A new field has been added to the "Business rules" section Allow business rules' traceability. IoT Solution Proposal - Actors, Actions, and Interaction Arrange- ments Included new field added in the "IoT Scenarios" section Enable traceability between IoT Scenarios information. IoT system components - This section has been removed Avoid redundancy of the arrangement catalogs' information. - Related functional Requirements, Precedencies and Depend- encies Included new fields have been added in the "IoT scenarios description." Enable traceability between IoT scenarios. Collected data and Actions performed Collected data and Actions performed The field "Collected data and Actions performed" was di- vided into two fields Simplify this section and separate specific information. Interaction sequence - Remove alternative and exception flows. Simplify this section because it is like a use-case structure (main, alternative, and exception flows). Environment and Connec- tivity - These sections have been removed Simplify this section. We believe this information is not relevant at this point. In this way, they must be collected during the design projects' phase. IoT use-cases Description Business rules - The business rules field was moved from the "Interaction sequence" section to a separate section Simplify this section. - Customer or customer representative agreement This section has been added Enable to get an explicit agreement about IoT Diagram and Use cases. IoT Canvas - - This template has been added Enable to support projects' description and idea validation through the easy and fast way. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Template name Previous element New element Change description Rationale IoT Project Feasibility Analysis - - This template has been added Enable to support projects' decision-making about feasibility in market de- mand, cost, impact, risks, and technology. Requirements Checklist - - This template has been added Enable to verify if requirements are correct, understandable, and consistent. Change Analysis Report - - This template has been added Enable to manage requirements' change through the project life cycle. IoT Diagram and Use cases Checklist - - This template has been added Enable to verify if IoT Diagram and Use cases are correct, understandable, and consistent. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Table 5. Technologies x RE phases. Technology/RE Phase CON ELI NEG ANA SPE VER VAL MAN (Aziz et al. 2016) x x x (Mahalank et al. 2016) x (Takeda and Hatakeyama 2016) x x (Touzani and Ponsard 2016) x IoT-RML (Costa et al. 2017) x x x (Yamakami 2017) x GSEM-IoT (Zambonelli 2017) x x (Carvalho et al. 2018) x (Curumsing et al. 2019) x x x x IoT System Development Methods Ignite (Giray et al. 2018) x x x x x x IoT Methodology (Giray et al. 2018) x x x (Laplante et al. 2018) x x x x IoTReq (Reggio 2018) x x x CORE (Hamdi et al. 2019) x x SCENARIOT (Silva 2019) x x x SCENARIOTCHECK (Souza 2020) x TrUStAPIS (Ferraris and Fernandez-Gago 2020) x x x Several technologies address the elicitation phase (ELI): Ignite (Giray et al. 2018), IoT Methodology (Giray et al. 2018), (Laplante et al. 2018), IoTReq (Reggio 2018), (Curumsing et al. 2019), CORE (Hamdi et al. 2019), SCE- NARIOT (Silva 2019) and TrUStAPIS (Ferraris and Fernan- dez-Gago 2020) that offer resources for collecting require- ments. In addition, GSEM-IoT (Zambonelli 2017), IoTReq, and IoT Methodology propose mechanisms to transform us- ers' needs into requirements. For the negotiation phase (NEG), Ignite (Giray et al., 2018) addresses the impact and risk analysis but does not provide further details on conducting this activity. In the analysis phase (ANA), (Takeda and Hatakeyama 2016) and (Touzani and Ponsard 2016) technologies, Ignite (Giray et al. 2018), (Laplante et al. 2018), IoTReq (Reggio 2018), (Curumsing et al. 2019) and CORE (Hamdi et al. 2019) use UML diagrams to develop the analysis models. The SCENARIOT technology (Silva 2019) comprises the scenario analysis based on IoT interaction arrangements. The works of (Aziz et al. 2016) and IoT-RML (Costa et al., 2017) address artifacts and models' reuse. The specification phase (SPE) is addressed by several technologies: (Takeda and Hatakeyama 2016), IoT-RML (Costa et al. 2017), IoTReq (Reggio 2018), and TrUStAPIS (Ferraris and Fernandez-Gago 2020) that use formal models for specifying requirements. Technologies proposed by (Aziz et al. 2016), (Mahalank et al. 2016), and (Giray et al. 2018) – Ignite provide templates for specifying require- ments. The SCENARIOT (Silva 2019) proposes the scenario specification using IoT interaction arrangements. In the verification phase (VER), we found that (Car- valho et al. 2018) and SCENARIOTCHECK (Souza 2020) propose mechanisms to verify requirements. The technolo- gies proposed by (Yamakami 2017), (Costa et al. 2017) - IoT-RML (Carvalho et al., 2018), and (Curumsing et al. 2019) offer mechanisms for checking conflicts between re- quirements. The validation phase (VAL) is addressed by Ignite (Giray et al., 2018), IoT Methodology (Giray et al., 2018), and (Laplante et al., 2018), which propose a prototyping technique to ensure that the product meets users' needs. For the management phase (GER), (Aziz et al. 2016), (Curumsing et al. 2019), and TrUStAPIS (Ferraris and Fer- nandez-Gago 2020) offer mechanisms to enable traceability. In addition, TrUStAPIS also provides a mechanism for re- quirements change management. 5.2 Techniques and methods A quasi-systematic literature review (Lim et al. 2018) iden- tified 12 relevant publications and 37 elicitation techniques normally applied in IoT systems development. The most fre- quently used techniques are interviews and prototypes, where the latter can also be used to validate requirements. We can also highlight other techniques and methods ap- plied during the elicitation phase: scenarios, use cases, and frameworks. This work also presents a brief contribution re- garding the conflict resolution of the stakeholders. The au- thors emphasize using interview and prototyping techniques to encourage discussions and find alternative ways to iden- tify conflicts. In this way, we analyzed the 17 technologies to identify which techniques/methods are used and where (RE phases) in IoT systems development. Figure 14 shows our findings where we can observe 14 items and the most used: process (thirteen), use cases (eight), and models (seven). Figure 14. Technologies x Techniques/Methods. Table 6 shows where (RE phases) the techniques/meth- ods found are applied. The elicitation (28), analysis (30), and specification (22) phases offer a greater number of tech- A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 niques/methods. It is important to highlight that some tech- nologies offer more than one technique for one or more RE phases. RETIoT permeates the eight phases previously described offering methodological and technical support through con- struction, techniques, and templates. Analyzing the RETIoT current version (see section 3), we can say that it proposes and integrates some tech- niques/methods: prototyping, IoT canvas, IoT scenarios based on IoT scenarios specification technique - SCENAR- IOT (Silva 2019), use cases diagram and description, tem- plates, and IoT scenario inspection technique - SCENARI- OTCHECK (Souza 2020), and a construction process. 6 Research Opportunities Analyzing the technologies found in the technical literature, we can observe that only one technology discusses the Ne- gotiation phase. It represents a research opportunity. Few technologies offer project management, validation, test case elaboration, and decision-making related to the system's de- sign and architecture. These topics can be explored through future research. We can also observe that not all technologies cover all RE activities and present gaps regarding the differ- ent activities necessary to build IoT system requirements document. Among these gaps, we can observe the lack of i) method- ological support for the design and ideation of IoT products (Nguyen-Duc et al. 2019); ii) stakeholder identification and description and business needs (Silva et al. 2020b); iii) IoT system characteristics and behaviors (Motta et al. 2019a), as well as the requirements refinement; iv) high-level (new IoT interaction arrangements) and low-level (IoT use-case dia- gram) analysis models; v) project feasibility analysis (Silva et al. 2020); vi) prototypes as suggested by (Nguyen-Duc et al. 2019) (Lim et al. 2018); and vii) explicit agreements with the client (Silva et al. 2020). These technologies also do not fully meet the IoT software system specificities and characteristics: i) the components and actors' description (Curumsing et al. 2019) (Aziz et al. 2016); ii) the behaviors description of different levels of each object - (Curumsing et al. 2019) (Reggio 2018); iii) the iden- tification of the systemic characteristics (sensing, identifica- tion, performance, processing, and connectivity); and iv) the detailed specification of each feature. 7 Conclusion and Future Works This paper presented the RETIoT. It provides a construc- tion process, techniques (IoT scenario specification and ver- ification techniques), and tools (templates) to support IoT software's Requirements Engineering systems. Besides, this work seeks to accomplish an initial observation about this technology that focuses on analyzing and evaluating only the templates. A feasibility study was performed to compare three templates defined in the second version of RETIoT with conventional software systems templates (not specific to IoT software systems). Their comparison provided indications that the artifacts generated by RETIoT may be complete re- garding the capture of IoT information. Table 6. Techniques/Methods x RE phases. Techniques-Methods /RE Phase CON ELI NEG ANA SPE VER VAL MAN Interview 2 Prototyping 3 Canvas 1 1 Scenarios 1 3 Use cases 2 2 7 1 Class Diagram 1 Activity Diagram 1 State Diagram 1 SysML Language 1 1 1 Formal Models 2 4 2 1 1 Templates 2 3 5 1 2 Goal model 2 4 1 1 Framework 2 3 1 2 1 2 Catalogs 1 1 1 Process 3 11 1 9 7 3 3 3 Total 9 28 2 30 22 7 9 7 The experimental study was planned to analyze the pro- cess and templates of RETIoT. However, it was not possible to conduct this study due to COVID 19 pandemic. Some of the future work reserved for the RETIoT are: i) (re)design and execution of experimental studies to evaluate the technology in more robust IoT software system projects (both academic and industrial contexts); A comparative study of the RETIoT with traditional technologies will be carried out to verify the efficiency and effectiveness of the RETIoT in terms of cap- turing system and project relevant information. Such a study should also evaluate the RETIoT usefulness and suitability ac- cording to the user's perception; ii) integrating RETIoT with a testing technique to support software engineers with the specification of context-aware test cases - CATS# Context- Aware Test Suite Design (Doreste and Travassos 2020); and iii) developing tooling support integrating the construction process, IoT scenario specification, and verification tech- niques templates. The tool will facilitate the traceability among IoT requirements, IoT Interaction Arrangements, IoT scenarios, and IoT use-cases. A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Acknowledgments The authors would like to thank the National Council for Sci- entific and Technological Development - CNPq. Taisa Gon- çalves received a postdoctoral scholarship (154004 / 2018- 9). Prof. Travassos is a CNPq researcher (304234/2018-4). References Alexander I, Maiden N (2004) Scenarios, stories, and use cases: the modern basis for system development. Computing and Control Engineering 15:24–29. https://doi.org/10.1049/cce:20040505 Arif S, Khan Q, Gahyyur SAK (2009) Requirements engi- neering processes, tools/technologies, & methodol- ogies. International Journal of Reviews in Compu- ting 2:41–56 Aziz MW, Sheikh AA, Felemban EA (2016) Requirement Engineering Technique for Smart Spaces. In: Inter- national Conference on Internet of things and Cloud Computing. ACM Press, Cambridge United King- dom, p 54:1-54:7 Behrens H (2002) Requirements Analysis Using Statecharts and Generated Scenarios. In: Doctoral Symposium at IEEE Joint Conference on Requirements Engi- neering Burg JFM, Van de Riet RP (1996) A Natural Language and Scenario based Approach to Requirements Engi- neering. In: Proceedings of Workshop in Natuer- lichsprachlicher Entwurf von Infor- mationssystemen Carvalho RM, Andrade RMC, Oliveira KM (2018) Towards a catalog of conflicts for HCI quality characteristics in UbiComp and IoT applications: Process and first results. In: 12th International Conference on Re- search Challenges in Information Science (RCIS). IEEE, Nantes, pp 1–6 Costa B, Pires PF, Delicato FC (2017) Specifying Functional Requirements and QoS Parameters for IoT Sys- tems. In: 15th Intl Conf on Dependable, Autonomic and Secure Computing, 15th Intl Conf on Pervasive Intelligence and Computing, 3rd Intl Conf on Big Data Intelligence and Computing and Cyber Sci- ence and Technology Congress. IEEE, Orlando, FL, pp 407–414 Curumsing MK, Fernando N, Abdelrazek M, et al (2019) Emotion-oriented requirements engineering: A case study in developing a smart home system for the elderly. Journal of Systems and Software 147:215–229. https://doi.org/10.1016/j.jss.2018.06.077 Doreste AC de S, Travassos GH (2020) Towards Supporting the Specification of Context-Aware Software Sys- tem Test Cases. In: XXIII Ibero-American Confer- ence on Software Engineering. Springer, Curitiba, Brazil (Online), p S10 P1:8 pages Ferraris D, Fernandez-Gago C (2020) TrUStAPIS: a trust re- quirements elicitation method for IoT. International Journal of Information Security 19:111–127. https://doi.org/10.1007/s10207-019-00438-x Giray G, Tekinerdogan B, Tüzün E (2018) IoT System De- velopment Methods. In: Hassan Q, Khan AR, Madani SA (eds) Internet of Things. CRC Press/Taylor & Francis, New York, pp 141–159 Glinz M (2000) Improving the Quality of Requirements with Scenarios. In: Proceedings of the second world con- gress on software quality. pp 55–60 Hamdi MS, Ghannem A, Loucopoulos P, et al (2019) Intel- ligent Parking Management by Means of Capability Oriented Requirements Engineering. In: Wotawa F, Friedrich G, Pill I, et al. (eds) Advances and Trends in Artificial Intelligence - From Theory to Practice - IEA/AIE 2019. Springer International Publishing, Cham, pp 158–172 Laplante NL, Laplante PA, Voas JM (2018) Stakeholder Identification and Use Case Representation for In- ternet-of-Things Applications in Healthcare. IEEE Systems Journal 12:1589–1597. https://doi.org/10.1109/JSYST.2016.2558449 Lim T-Y, Chua F-F, Tajuddin BB (2018) Elicitation Tech- niques for Internet of Things Applications Require- ments: A Systematic Review. In: VII International Conference on Network, Communication and Computing. ACM Press, Taipei City, Taiwan, pp 182–188 Mahalank SN, Malagund KB, Banakar RM (2016) Non Functional Requirement Analysis in IoT based smart traffic management system. In: International Conference on Computing Communication Control and Automation. IEEE, Pune, India, pp 1–6 Motta RC, Oliveira KM, Travassos GH (2019a) On chal- lenges in engineering IoT software systems. Journal of Software Engineering Research and Develop- ment 7:5:1-5:20. https://doi.org/10.5753/jserd.2019.15 Motta RC, Oliveira KM, Travassos GH (2020) Towards a Roadmap for the Internet of Things Software Sys- tems Engineering. In: Proceedings of the 12th In- ternational Conference on Management of Digital EcoSystems. ACM, Virtual Event United Arab Emirates, pp 111–114 Motta RC, Silva VM, Travassos GH (2019b) Towards a more in-depth understanding of the IoT Paradigm and its challenges. Journal of Software Engineering Research and Development 7:3:1-3:16. https://doi.org/10.5753/jserd.2019.14 A Requirements Engineering Technology for the IoT Software Systems Silva et al. 2021 Nguyen-Duc A, Khalid K, Shahid Bajwa S, Lønnestad T (2019) Minimum Viable Products for Internet of Things Applications: Common Pitfalls and Prac- tices. Future Internet 11:Paper 50. https://doi.org/10.3390/fi11020050 Pandey D, Suman U, Ramani AK (2010) An Effective Re- quirement Engineering Process Model for Software Development and Requirements Management. In: International Conference on Advances in Recent Technologies in Communication and Computing. IEEE, Kottayam, India, pp 287–291 Pressman RS, Maxim B (2014) Software Engineering: A Practitioner’s Approach, 8 edition. McGraw-Hill Education, New York, NY Reggio G (2018) A UML-based proposal for IoT system re- quirements specification. In: 10th International Workshop on Modelling in Software Engineering. ACM Press, Gothenburg, Sweden, pp 9–16 Silva DV da, Goncalves TG, Rocha ARC da (2019) A Re- quirements Engineering Process for IoT Systems. In: XVIII Brazilian Symposium on Software Qual- ity. ACM Press, Fortaleza, Brazil, pp 204–209 Silva DV da, Gonçalves TG, Travassos GH (2020a) A Tech- nology to Support the Building of Requirements Documents for IoT Software Systems. In: XIX Bra- zilian Symposium on Software Quality. ACM Press, São Luís, Brazil (Online), p Article No 4 Pages 1-10 Silva DV da, Souza BP de, Gonçalves TG, Travassos GH (2020b) Uma Tecnologia para Apoiar a Engenharia de Requisitos de Sistemas de Software IoT. In: XXIII Ibero-American Conference on Software En- gineering. Curitiba, Brazil (Online), p S09 P3:14 pages Silva VM (2019) SCENARIoT Support for Scenario Speci- fication of Internet of Things-Based Software Sys- tems. Master’s Dissertation, Federal University of Rio de Janeiro Sommerville I (2015) Software Engineering, 10 edition. Pe- arson, Harlow Souza BP (2020) SCENARIOTCHECK: Uma Técnica de Leitura Baseada em Checklist para Verificação de Cenários IoT. Master’s Dissertation, Federal Uni- versity of Rio de Janeiro Souza BP de, Motta RC, Costa D, Travassos GH (2019a) An IoT-based Scenario Description Inspection Techni- que. In: XVIII Brazilian Symposium on Software Quality. ACM Press, Fortaleza, Brazil, pp 20–29 Souza BP de, Motta RC, Travassos GH (2019b) The first version of SCENARIotCHECK: A Checklist for IoT based Scenarios. In: XXXIII Brazilian Sympo- sium on Software Engineering. ACM Press, Salva- dor, Brazil, pp 219–223 Takeda A, Hatakeyama Y (2016) Conversion Method for User Experience Design Information and Software Requirement Specification. In: Marcus A (ed) De- sign, User Experience, and Usability: Design Thinking and Methods - DUXU 2016. Springer, Cham, pp 356–364 Touzani M, Ponsard C (2016) Towards Modelling and Anal- ysis of Spatial and Temporal Requirements. In: 24th International Requirements Engineering Con- ference. IEEE, Beijing, China, pp 389–394 Vegendla A, Duc AN, Gao S, Sindre G (2018) A Systematic Mapping Study on Requirements Engineering in Software Ecosystems: Journal of Information Technology Research 11:4:1-4:21. https://doi.org/10.4018/JITR.2018010104 Yamakami T (2017) Horizontal Requirement Engineering in Integration of Multiple IoT Use Cases of City Plat- form as a Service. In: 2017 IEEE International Con- ference on Computer and Information Technology (CIT). IEEE, Helsinki, Finland, pp 292–296 Zambonelli F (2017) Key Abstractions for IoT-Oriented Software Engineering. IEEE Software 34:38–45. https://doi.org/10.1109/MS.2017.3 A Requirements Engineering Technology for the IoT Software Systems 1 Introduction 2 The Technological Basis of the RETIoT 2.1 SCENARIOT 2.2 SCENARIOTCHECK 3 The RETIoT 3.1 Construction process 3.2 Construction process stages 3.2.1 Stage 1 3.2.2 Stage 2 3.2.3 Stage 3 4 Evaluating the RETIoT's Templates Feasibility 4.1 Templates 4.1.1 The RETIoT Templates 4.1.2 Projects and Teams 4.2 Execution 4.3 Results and Discussion 4.4 Templates' evolution 4.5 Threats to Validity 5 Literature analysis 5.1 RE phases 5.2 Techniques and methods 6 Research Opportunities 7 Conclusion and Future Works Acknowledgments References