Requirements Engineering for Embedded Systems: The REPES Process

Abstract

[Context] Requirements Engineering (RE) for Embedded Systems (ES) is challenging since it has unique properties that make it complex, expensive and error-prone compared with other software categories, such as information systems. Due to their complexity, the risk of undetected requirements errors and deficiencies increases considerably. [Goal] Thus, this paper presents a specific process for requirements development and management named REPES which is tailored for embedded systems. [Method] In this proposal, we used the results of a Systematic Literature Review (SLR), metamodel and RE standards to guide the development of the process. [Results] REPES has four main process areas, 24 sub-processes, and 89 actions. [Conclusion] We argue that the proposed process can help organizations in improving their requirements practices to support completeness and correctness of RE for ES.

Revisitando Processos de Construção de Requisitos: Uma Perspectiva de Transparência

“…Vignette Ref An Initial Analysis on How Software Transparency and Trust Influence each other sim, indiretamente ao tratar de aspectos positivos de transparência de processos e seus efeitos em relação positiva de confiança. [11] Eliciting Requirements for Identifying Workflow Categories indiretamente ao propor questionamentos a serem feitos para tornar mais transparente (conhecer melhor a organização com a perspectiva de workflow) [14] Construcción de uma Taxonomía de Componentes COTS Orientados a la Gestión de Requisitos sim definitivamente, apresenta modelos i* (SD) descrevendo inter-relacionamento entre atores no processo. [15] Ferramenta de Apoio aos Processos da Engenharia de Requisitos, nas Fases de Projeto sim, indiretamente ao prover um guideline de atividades do processo e de tratar especificamente de: " o processo de gestão de qualidade do processo e do produto é suportado pela geração prévia do checklist específico, para o tipo de produto, estruturado pelo supervisor" [12] Abordagem da Engenharia de Requisitos para Software Legado sim, ao suscitar a pergunta: processo de qualidade vs qualidade no processo [16] Medição de Pontos por Função a Partir da Especificação de Requisitos não diretamente, mostra como modelos socioculturais oriundos do Framework da Teoria da Atividade podem fornecer informações que complementam os modelos organizacionais da metodologia TROPOS.…”

A Gray Box-based Approach to Automatic Requirements Specification for a Robot Patrol System

“…If the intruder is detected, the flow goes to [A1]. [3] The RPS reads the current location and checks whether the RPS arrives at the destination.…”

“…Although the service provided by the embedded system results from each event generated by the user, it cannot be observable from the outside of the system which internal action the system performs until the service result is derived. In other words, requirements extractable from visible interactions between an embedded system and environmental factors in which it is used are relatively limited [3,4]. Thus, when the requirements for an embedded system are specified using a use-case model, the amount of information identified in the requirements specification is insufficient as a specification for developers [5].…”