The Federal University of São Paulo is developing a low-cost insulin infusion pump in cooperation with a Brazilian company to provide an affordable treatment option for individuals with type 1 diabetes, especially from low-incoming countries. Risk management according to standard ISO 14971 is required for certification and safe use of the insulin pump. This paper describes the risk management performed to include safeguards in the architectural design of the insulin pump in development. The risk management process activities were carried out simultaneously and integrated with equipment development, generating requirements to protect against adverse effects on safety due to physical components failures, development errors, and user errors. Design solutions for the safety requirements, implemented in hardware and software, were incorporated in the low-cost insulin pump architecture. Comparison with applicable standards and certified insulin infusion pumps showed that these safeguards align with the best practices adopted for this type of equipment.

We have conducted in-depth interviews with experienced practitioners in the Safety-Critical Systems (SCS) domain in order to investigate several aspects related to requirements specification and safety analysis for SCS. We interviewed 19 practitioners from eleven SCS companies in different domains with the intention of verifying which approaches they use day-to-day, and what their perceptions are in relation to the approaches used to elicit, analyze, specify and validate safety requirements. The aim of this study is to obtain an in-depth understanding of how requirements engineering is carried out in companies that develop SCS.

Context: Software is an important part in safety-critical system (SCS) development since it is becoming a major source of hazards. Requirements-related hazards have been associated with many accidents and safety incidents. Requirements issues tend to be mitigated in companies with high processes maturity levels since they do their business in a systematic, consistent and proactive approach. However, requirements engineers need systematic guidance to consider safety concerns early in the development process. Goal: the paper investigates which safety practices are suitable to be used in the Requirements Engineering (RE) process for SCS and how to design a safety maturity model for this area. Method: we followed the design science methodology to propose Uni-REPM SCS, a safety module for Unified Requirements Engineering Process Maturity Model (Uni-REPM). We also conducted a static validation with two practitioners and nine academic experts to evaluate its coverage, correctness, usefulness, and applicability. Results: The module has seven main processes, fourteen sub-processes and 148 practices that form the basis of safety processes maturity. Moreover, we describe its usage through a tool. Conclusions: The validation indicates a good coverage of practices and well receptivity by the experts. Finally, the module can help companies in evaluating their current practices.

Context: Requirements issues tend to be mitigated in organizations with high process maturity levels since they do their business in a systematic, consistent and proactive approach. In a Safety-Critical System (SCS), requirements problems have been associated with accidents and safety incidents. Objective: This work investigates which safety practices/actions are suitable to be used in the Requirements Engineering (RE) process of SCS and how to design a safety maturity model for this area. Method: we adopted different empirical techniques to propose Uni-REPM SCS, which consists of a safety module to be included in the Unified Requirements Engineering Process Maturity Model (Uni-REPM). Results: The safety module has seven main processes, 14 sub-processes and 148 safety actions describing principles and practices that form the basis of safety processes maturity. Conclusions: Preliminary validation with two practitioners and nine academic experts indicates that the safety module can help organizations to evaluate their current safety practices with respect to their RE process. Moreover, it also offers a step-wise improvement strategy to raise their safety maturity level.

Self-Adaptive Systems are able to change their behavior at runtime according to the environment where they are. This study presents an approach to specify the requirements for self-adaptive systems based on the concepts of Fuzzy Logic, which deals with factors such as ambiguity, uncertainties and vague information on the solution of problems; and NFR-Framework, which deals with the non-functional requirements which, very often, vaguely and full of uncertainties present themselves. Adaptive systems consist of (functional and non-functional) requirements, which hold the capacity to modify themselves during the runtime with little or no human intervention at all. Requirements that carry out the feature of wide variability are called adaptive requirements. PERSA (acronym from “Processo de Especificação de Requisitos Adaptativos”, in Portuguese) is reported in this work, using the Fuzzy Logic and the NFR-Framework as a basis, since both offers resources to manage uncertainties, an inherent attribute of self-adaptive systems. This process aims the approach of specification of adaptive requirements in a systematic way providing a guide to support requirements engineers. PERSA Process is settled in three mains phases subdivided into several steps. Two case studies were developed to validate it: the first deals with an automated system to prepare steaks, which needs to adapt to its several types; the second relates to a system for automation for canine diets, which must be adapted to different breeds of dogs according to their size, weight and classification. The case studies provide a first approach of the use and benefits of PERSA Process. In these studied the theoretical proposal was evaluated and discussed in order to establish the degree of understanding, the clarity of activities and the necessary adjustments to improve the proposed achievements, thus obtaining a satisfactory though early assessment which answers the purpose of specifying the requirements for self-adaptive systems.

In the last 30 years there have been great advances in technology for diabetes treatment, which facilitated the management of the disease and its complications. Among the advances we can mention the development of insulin infusion pump. However, diabetes treatment using the insulin pump still remains expansive in Brazil, especially because the device and its accessories are imported. The aim of this paper is to report a prototype development of a low-cost insulin infusion pump aimed to benefit Brazilian people suffering with Diabetes Mellitus type 1. The prototype development is a result from a cooperation between Brazilian academy and industry. We comment the development of such a prototype and the lessons learned obtained from it.

State-of-the-art in Requirements Engineering offers many frameworks and techniques to enable requirements engineers in their work. However, for critical systems there are gaps in state-of-the-art, and these can result in dire consequences, potentially putting lives in danger and damage infrastructure and threaten the environment. A well known technique used to help requirements engineers to understand safety hazards situations in the context of safety-critical software is Fault Tree Analysis (FTA). This technique is a good one to decompose hazards identified in the system context into events that may put the system functionalities in risk. However, FTA does not offer a protocol of how to derive safety functional requirements from fault trees. In this paper we present a case study adopting a protocol to help requirements engineers to derive safety functional requirements from FTA. The proposed protocol was based on a study performed in a Brazilian company in the area of electronic medical devices. The development of prototype of a low cost insulin infusion pump, which is a critical system, offered the basis to propose and test a protocol to derive safety functional requirements from FTA. During the case study we collected evidences that help us to discuss if FTA is sufficient to guide software engineers to implement the corresponding control software and also if FTA offers enough information to help requirements engineers to derive safety functional requirements.

Collaborative environments to support design with government are strongly based on right, prohibition, obligation or dispensation rules. These rules can be designed with five dimensions found in any collaborative environment: actors, activities, objects, time and space. This paper presents a framework to construct collaboration policies organized in a set of collaborative rules following a model trigger-condition-action. The model proposed to structure rules can be used for policy specification languages and interchange among collaborative environments in design.

The goal of this work is to show that precepts from activity theory can be used in software requirements elicitation. Thus, we propose an approach to requirements elicitation using principles from this theory. Initially, we mention common problems found in requirements elicitation. Then we explain the main precepts of activity theory. Finally, we present a case study using the suggested approach to requirements elicitation.