Semantics of trace relations in requirements models for consistency checking and inferencing

Requirements traceability is the ability to relate requirements back to stakeholders and forward to corresponding design artifacts, code, and test cases. Although considerable research has been devoted to relating requirements in both forward and backward directions, less attention has been paid to relating requirements with other requirements. Relations between requirements influence a number of activities during software development such as consistency checking and change management. In most approaches and tools, there is a lack of precise definition of requirements relations. In this respect, deficient results may be produced. In this paper, we aim at formal definitions of the relation types in order to enable reasoning about requirements relations. We give a requirements metamodel with commonly used relation types. The semantics of the relations is provided with a formalization in first-order logic. We use the formalization for consistency checking of relations and for inferring new relations. A tool has been built to support both reasoning activities. We illustrate our approach in an example which shows that the formal semantics of relation types enables new relations to be inferred and contradicting relations in requirements documents to be determined. The application of requirements reasoning based on formal semantics resolves many of the deficiencies observed in other approaches. Our tool supports better understanding of dependencies between requirements

META-MODELING CONSTRUCTS FOR REQUIREMENTS REUSE (RR): SOFTWARE REQUIREMENTS PATTERNS, VARIABILITY AND TRACEABILITY

Reuse is a fundamental activity, which increases quality and productivity of software products. Reuse of software artifacts, such as requirements, architectures, and codes can be employed at any developmental stage of software. However, reuse at a higher level of abstraction, for instance at requirements level, provides greater benefits in software development than when applied at lower level of abstraction for example at coding level. To achieve full benefits of reuse, a systematic approach and appropriate strategy need to be followed. Although several reuse approaches are reported in the literature, these approaches lack a key strategy to synergize some essential drivers of reuse, which include reusable structure, variability management (VM) and traceability of software artifacts. In line with this, we make our contribution in this paper by (1) presenting the concepts and importance of software requirements patterns (SRP) for reusable structure; (2) proposing a strategy, which combines three sub-disciplines of Software Engineering (SE) such as Requirements Engineering (RE), Software Product Line Engineering (SPLE) and Model-driven Engineering (MDE); (3) proposing a meta-modeling constructs, which include SRP, VM and traceability and; (4) Relationship amongst the three sub-disciplines of the SE. This is a novel approach and we believe it can support and guide researchers and practitioners in SE community to have greater benefits of reuse during software developments

A CMMI-compliant requirements management and development process

Requirements Engineering has been acknowledged an essential discipline for Software Quality. Poorly-defined processes for eliciting, analyzing, specifying and validating requirements can lead to unclear issues or misunderstandings on business needs and project’s scope. These typically result in customers’ non-satisfaction with either the products’ quality or the increase of the project’s budget and duration. Maturity models allow an organization to measure the quality of its processes and improve them according to an evolutionary path based on levels. The Capability Maturity Model Integration (CMMI) addresses the aforementioned Requirements Engineering issues. CMMI defines a set of best practices for process improvement that are divided into several process areas. Requirements Management and Requirements Development are the process areas concerned with Requirements Engineering maturity. Altran Portugal is a consulting company concerned with the quality of its software. In 2012, the Solution Center department has developed and applied successfully a set of processes aligned with CMMI-DEV v1.3, what granted them a Level 2 maturity certification. For 2015, they defined an organizational goal of addressing CMMI-DEV maturity level 3. This MSc dissertation is part of this organization effort. In particular, it is concerned with the required process areas that address the activities of Requirements Engineering. Our main goal is to contribute for the development of Altran’s internal engineering processes to conform to the guidelines of the Requirements Development process area. Throughout this dissertation, we started with an evaluation method based on CMMI and conducted a compliance assessment of Altran’s current processes. This allowed demonstrating their alignment with the CMMI Requirements Management process area and to highlight the improvements needed to conform to the Requirements Development process area. Based on the study of alternative solutions for the gaps found, we proposed a new Requirements Management and Development process that was later validated using three different approaches. The main contribution of this dissertation is the new process developed for Altran Portugal. However, given that studies on these topics are not abundant in the literature, we also expect to contribute with useful evidences to the existing body of knowledge with a survey on CMMI and requirements engineering trends. Most importantly, we hope that the implementation of the proposed processes’ improvements will minimize the risks of mishandled requirements, increasing Altran’s performance and taking them one step further to the desired maturity level

Traceability of Requirements and Software Architecture for Change Management

At the present day, software systems get more and more complex. The requirements of software systems change continuously and new requirements emerge frequently. New and/or modified requirements are integrated with the existing ones, and adaptations to the architecture and source code of the system are made. The process of integration of the new/modified requirements and adaptations to the software system is called change management. The size and complexity of software systems make change management costly and time consuming. To reduce the cost of changes, it is important to apply change management as early as possible in the software development cycle. Requirements traceability is considered crucial in change management for establishing and maintaining consistency between software development artifacts. It is the ability to link requirements back to stakeholders’ rationales and forward to corresponding design artifacts, code, and test cases. When changes for the requirements of the software system are proposed, the impact of these changes on other requirements, design elements and source code should be traced in order to determine parts of the software system to be changed. Determining the impact of changes on the parts of development artifacts is called change impact analysis. Change impact analysis is applicable to many development artifacts like requirements documents, detailed design, source code and test cases. Our focus is change impact analysis in requirements and software architecture. The need for change impact analysis is observed in both requirements and software architecture. When a change is introduced to a requirement, the requirements engineer needs to find out if any other requirement related to the changed requirement is impacted. After determining the impacted requirements, the software architect needs to identify the impacted architectural elements by tracing the changed requirements to software architecture. It is hard, expensive and error prone to manually trace impacted requirements and architectural elements from the changed requirements. There are tools and approaches that automate change impact analysis like IBM Rational RequisitePro and DOORS. In most of these tools, traces are just simple relations and their semantics is not considered. Due to the lack of semantics of traces in these tools, all requirements and architectural elements directly or indirectly traced from the changed requirement are candidate impacted. The requirements engineer has to inspect all these candidate impacted requirements and architectural elements to identify changes if there are any. In this thesis we address the following problems which arise in performing change impact analysis for requirements and software architecture. Explosion of impacts in requirements after a change in requirements. In practice, requirements documents are often textual artifacts with implicit structure. Most of the relations among requirements are not given explicitly. There is a lack of precise definition of relations among requirements in most tools and approaches. Due to the lack of semantics of requirements relations, change impact analysis may produce high number of false positive and false negative impacted requirements. A requirements engineer may have to analyze all requirements in the requirements document for a single change. This may result in neglecting the actual impact of a change. Manual, expensive and error prone trace establishment. Considerable research has been devoted to relating requirements and design artifacts with source code. Less attention has been paid to relating Requirements (R) with Architecture (A) by using well-defined semantics of traces. Designing architecture based on requirements is a problem solving process that relies on human experience and creativity, and is mainly manual. The software architect may need to manually assign traces between R&A. Manual trace assignment is time-consuming, expensive and error prone. The assigned traces might be incomplete and invalid. Explosion of impacts in software architecture after a change in requirements. Due to the lack of semantics of traces between R&A, change impact analysis may produce high number of false positive and false negative impacted architectural elements. A software architect may have to analyze all architectural elements in the architecture for a single requirements change. In this thesis we propose an approach that reduces the explosion of impacts in R&A. The approach employs semantic information of traces and is supported by tools. We consider that every relation between software development artifacts or between elements in these artifacts can play the role of a trace for a certain traceability purpose like change impact analysis. We choose Model Driven Engineering (MDE) as a solution platform for our approach. MDE provides a uniform treatment of software artifacts (e.g. requirements documents, software design and test documents) as models. It also enables using different formalisms to reason about development artifacts described as models. To give an explicit structure to requirements documents and treat requirements, architecture and traces in a uniform way, we use metamodels and models with formally defined semantics. The thesis provides the following contributions: A modeling language for definition of requirements models with formal semantics. The language is defined according to the MDE principles by defining a metamodel. It is based on a survey about the most commonly found requirements types and relation types. With this language, the requirements engineer can explicitly specify the requirements and the relations among them. The semantics of these entities is given in First Order Logic (FOL) and allows two activities. First, new relations among requirements can be inferred from the initial set of relations. Second, requirements models can be automatically checked for consistency of the relations. Tool for Requirements Inferencing and Consistency Checking (TRIC) is developed to support both activities. The defined semantics is used in a technique for change impact analysis in requirements models. A change impact analysis technique for requirements using semantics of requirements relations and requirements change types. The technique aims at solving the problem of explosion of impacts in requirements when semantics of requirements relations is missing. The technique uses formal semantics of requirements relations and requirements change types. A classification of requirements changes based on the structure of a textual requirement is given and formalized. The semantics of requirements change types is based on FOL. We support three activities for impact analysis. First, the requirements engineer proposes changes according to the change classification before implementing the actual changes. Second, the requirements engineer indentifies the propagation of the changes to related requirements. The change alternatives in the propagation are determined based on the semantics of change types and requirements relations. Third, possible contradicting changes are identified. We extend TRIC with a support for these activities. The tool automatically determines the change propagation paths, checks the consistency of the changes, and suggests alternatives for implementing the change. A technique that provides trace establishment between R&A by using architecture verification and semantics of traces. It is hard, expensive and error prone to manually establish traces between R&A. We present an approach that provides trace establishment by using architecture verification together with semantics of requirements relations and traces. We use a trace metamodel with commonly used trace types. The semantics of traces is formalized in FOL. Software architectures are expressed in the Architecture Analysis and Design Language (AADL). AADL is provided with a formal semantics expressed in Maude. The Maude tool set allows simulation and verification of architectures. The first way to establish traces is to use architecture verification techniques. A given requirement is reformulated as a property in terms of the architecture. The architecture is executed and a state space is produced. This execution simulates the behavior of the system on the architectural level. The property derived from the requirement is checked by the Maude model checker. Traces are generated between the requirement and the architectural components used in the verification of the property. The second way to establish traces is to use the requirements relations together with the semantics of traces. Requirements relations are reflected in the connections among the traced architectural elements based on the semantics of traces. Therefore, new traces are inferred from existing traces by using requirements relations. We use semantics of requirements relations and traces to both generate/validate traces and generate/validate requirements relations. There is a tool support for our approach. The tool provides the following: (1) generation/validation of traces by using requirements relations and/or verification of architecture, (2) generation/validation of requirements relations by using traces. A change impact analysis technique for software architecture using architecture verification and semantics of traces between R&A. The software architect needs to identify the impacted architectural elements after requirements change. We present a change impact analysis technique for software architecture using architecture verification and semantics of traces. The technique is semi-automatic and requires participation of the software architect. Our technique has two parts. The first part is to identify the architectural elements that implement the system properties to which proposed requirements changes are introduced. By having the formal semantics of requirements relations and traces, we identify which parts of software architecture are impacted by a proposed change in requirements. We have extended TRIC for determining candidate impacted architectural elements. The second part of our technique is to propose possible changes for software architecture when the software architecture does not satisfy the new and/or changed requirements. The technique is based on architecture verification. The output of verification is a counter example if the requirements are not satisfied. The counter example is used with a classification of architectural changes in order to propose changes in the software architecture. These changes produce a new version of the architecture that possibly satisfies the new or the changed requirements

Desarrollo integral de aplicaciones domóticas: una perspectiva metodológica

[SPA] Los rápidos avances en electrónica, informática y tecnologías de la comunicación (Solé, 2003.) (Que conduce a la miniaturización y mejora del rendimiento de los ordenadores, sensores y redes) han dado lugar al desarrollo de nuevas tecnologías en el campo de la domótica (Espinoza, 2011). Las aplicaciones domóticas integran funciones de confort, ahorro energético, seguridad y comunicaciones. El objetivo principal de estos sistemas es dotar a las viviendas de un cierto grado de inteligencia que permita mejorar la calidad de vida de sus habitantes. Tareas tales como el encendido y regulación de luces de forma automática, control de la temperatura, corte de agua y gas cuando se detectan fugas o el control de los dispositivos del hogar de forma remota desde el móvil u ordenador con conexión a internet son algunas de las aplicaciones típicas del dominio domótico. Uno de los principales problemas en el desarrollo de sistemas domóticos es el hecho de que no hay un estándar de facto para implementar estas aplicaciones. Existen varios estándares y protocolos adoptados por las empresas que lideran el mercado. Por ejemplo KNX (ISO/IEC14543-3-X), Lonworks (ISO/IEC 14908) y X10. Como se indica en (Aenor, 2009), es improbable que se establezca una única tecnología dominante en el campo de la domótica a corto plaza. Además, cada uno de estos estándares proporciona su propio software con el que crear las aplicaciones domóticas y programar los dispositivos. Por lo tanto se debe seleccionar una tecnología en particular (plataforma) en la etapa de diseño inicial, puesto que las herramientas y dispositivos a usar dependen de esta elección. Estos hechos hacen que el desarrollo de aplicaciones domóticas sea totalmente dependiente de la plataforma, siendo muy complicado incrementar el nivel de abstracción y trabajar con conceptos del dominio domótico en lugar de trabajar con elementos de la tecnología. Por ello, y continuando con la línea de investigación iniciada del Dr. D. Manuel Jiménez en el campo de la domótica (Jiménez, 2009), donde se definió un marco general y los elementos iníciales de un DSL para domótica, se propone aplicar nuevas técnicas de la Ingeniería del Software que permitan la gestión integral del desarrollo del software en todas sus etapas. En concreto para este trabajo de Tesis se propone una metodología que sigue un enfoque de desarrollo dirigido por modelos (MDE) (Bézivin, 2005) (Favre, 2004) junto con un framework de soporte que proporciona los metamodelos y herramientas necesarias en cada nivel. A continuación, en el capítulo 2 se describen los objetivos estimados para el trabajo de Tesis. En el capítulo 3 se presenta el estado del arte, sobre el que se asienta el desarrollo de la nueva metodología propuesta, que se describe en el capítulo 4, haciendo especial hincapié en la gestión de requisitos y el soporte a la trazabilidad. A continuación, en el capítulo 5 se presentan los resúmenes del compendio de artículos incluidos en esta Tesis. Por último, el capítulo 6 resume las aportaciones realizadas por esta Tesis Doctoral y los resultados obtenidos.[ENG] (Solé, 2003) (Leading to miniaturization and improvement of performance of computers, sensor and networking) have given rise to de development of several Home Automation (HA) technologies (Espinoza, 2011). HA applications integrate comfort, energy saving, security and communications functions. The aim of an HA system is to provide homes with a certain degree of intelligence and to improve the quality of life of its inhabitants. Task like automatically switching lights and heating, cutting off the supply when gas or water leaks are detected or controlling the home devices remotely from a mobile or a computer through an Internet connection are typical applications of HA domain. One of the main problems of HA development lies in the fact that there is no agreement in the standard to implement the applications. HA applications and devices currently belonging to different manufactures are isolated from each other thereby creating the main obstacle to HA market growth. Leading companies in this market have adopted several standards and protocols [8]. Some worth mentioning examples are the KNX (ISO/IEC14543-3-X), Lonworks (ISO/IEC 14908) and X10 technologies. Furthermore, as stated in (Aenor, 2009) it is improbable that there will be a single dominant technology for HA in the short term. Each of these technologies provides its own software suite to create HA applications and program the devices. Hence the particular technology (specific platform) must be selected at the initial design stages, inasmuch as the tools and devices to be used depend on this choice. These facts make the development of HA applications strongly platform dependent, making it very difficult to raise the abstraction level and work with HA domain concepts rather than technology elements. Therefore, and continuing the research initiated by Dr. D. Manuel Jimenez in the domain of home automation (Jimenez, 2009), which defined a general framework and initial elements of a DSL for home automation, intends to apply new techniques of software engineering to enable the integrated management of software development in all its stages. Specifically, for this thesis, proposes the use of the approach of modeldriven development (MDE) (Bézivin, 2005) (Fabre,2004) together with a set of management tools models ranging from requirements management, traceability, validation and verification , all integrated in a same methodology. This thesis is structured as follows: Section 2 deals with introducing the objectives. Section 3 presents the state of the art on which rests the development of the proposed new methodology which is described in Section 4, whit particular emphasis on requirements management and traceability support. Later, Section 5 presents the abstracts of the articles included in the compendium. Finally Section 6 summarizes the results and contributions of this thesis.Universidad Politécnica de CartagenaPrograma de doctorado en Técnicas Avanzadas en Investigación y Desarrollo Agrario y Alimentari

Uma proposta para rastreabilidade no desenvolvimento de software

Orientador: Mario JinoTese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de ComputaçãoResumo: Rastreabilidade tem sido um tópico de pesquisa no desenvolvimento de software por pelo menos 40 anos, sendo adicionada a muitos padrões, como o DOD-STD-2167A e o IEEE 830-1998. Este último, por exemplo, afirma que uma boa especificação de requisitos de software deve ser rastreável. A rastreabilidade fornece muitos benefícios para projetos de software, tais como: identificação das razões para decisões de design, prevenção de problemas de dependência, identificação de responsabilidades em um projeto, estimação de impacto e de custo de modificações, e medição do progresso de desenvolvimento. Sucintamente, a rastreabilidade permite a geração de um produto de melhor qualidade. Dois principais focos surgiram na literatura nos últimos anos: desenvolvimento baseado em modelo e geração automática de rastros. O primeiro trata da modelagem de rastreabilidade, definindo relações e elementos de um projeto; o segundo trata da descoberta automática de relações entre elementos. Vários conceitos foram definidos até agora, como rastreabilidade bidirecional, rastreabilidade de especificações pré e pós-requisitos, rastreabilidade horizontal e vertical, e rastreabilidade explícita e implícita. Embora haja um consenso geral sobre a maioria dos conceitos relacionados a rastreabilidade, há uma falta de consenso sobre como, e o quê, deve ser rastreado; não há consenso sobre: quais relações são relevantes para os projetos de desenvolvimento de software, quais elementos devem ser rastreados, como as mudanças nos elementos de um projeto afetam as relações existentes, ou como atualizar as relações dadas certas mudanças. Os modelos de rastreabilidade visam responder a essas questões fornecendo um padrão para ser usado como uma guia em projetos de desenvolvimento de software; entretanto, não há consenso sobre o que um modelo deve conter. Existe uma variedade de modelos, cada um considerando diferentes tipos de relações, elementos, e possuindo diferentes focos. Além disso, a maioria dos modelos possui problemas que tornam o seu uso difícil, ou até mesmo impossível; por exemplo, existem modelos que não descrevem - suficientemente ou em nada - as ligações de rastreabilidade que propõem. Este trabalho visa a ajudar nesta questão, fornecendo uma contribuição dupla: um modelo de referência para criar e avaliar modelos de rastreabilidade, e um metamodelo abrangente, construído em cima do modelo de referência, para adicionar rastreabilidade a projetos de desenvolvimento de software. Nosso Modelo de Referência para rastreabilidade define os elementos básicos em um modelo de rastreabilidade e define conjuntos básicos de: ações, tipos de ligações, tipos de artefatos, e processos. Propriedades necessárias para o conjunto de tipos de ligações e o conjunto de tipos de artefatos também são fornecidas. Nosso Metamodelo para rastreabilidade é composto por: um modelo conceitual descrevendo e organizando os elementos de rastreabilidade; um conjunto de tipos de artefatos representando as atividades definidas no Modelo de Referência, além de um conjunto de tipos de artefatos criados para registrar decisões de design; um conjunto de tipos de ligações que modelam diferentes relações de rastreabilidade; e um conjunto de processos para garantir a consistência de projetosAbstract: Traceability has been a topic of research in software development for at least 40 years, being added to many standards, such as the DOD-STD-2167A and the IEEE 830-1998. The latter, for instance, states that a good software requirements specification should be traceable. Traceability provides many benefits to software projects, such as: identification of the reasons for design decisions, avoidance of dependency issues, identification of accountability in a project, estimation of impact and cost of modifications, and measurement of development progress. Succintly, traceability allows the generation of a better quality product. Two main focuses have emerged in the literature in recent years: model-based development and automated trace generation. The former concerns modeling traceability by defining relations and elements in a project; the latter concerns automatic discovery of relations between elements in a project. Several concepts have been defined so far, such as bidirectional traceability, pre and post-requirements specification traceability, horizontal and vertical traceability, and explicit and implicit traceability. While there is general consensus on most concepts related to traceability, there is a lack of consensus on how, and what, should be traced; there is no consensus on which relations are relevant for software development projects, which elements should be traced, how changes in elements of a project affects existing relations, or how to update relations given certain changes. Traceability models aim to answer these questions by providing a standard to be used as a guide in software development projects; however, there is no consensus on what a model should contain. There is a variety of models, each considering different types of relations, elements, and having distinct focuses. Also, the majority of models have issues which makes them difficult or even impossible to use; for instance, there are models which do not describe - sufficiently or at all - traceability links which they propose. This work aims to help in this issue by providing a twofold contribution: a reference model for creating and evaluating traceability models, and a comprehensive metamodel, built on top of the reference model, to add traceability to software development projects. Our Reference Model for traceability defines the basic elements in a traceability model and defines basic sets of: actions, link types, artifact types, and processes. Necessary properties for the sets of link types and artifact types are also provided. Our Metamodel for traceability is composed of: a conceptual model describing and organizing the elements of traceability; a set of artifact types representing the activities of the Reference Model, plus a set of artifact types created to record design decisions; a set of link types modeling different traceability relations; and a set of processes to ensure project consistencyDoutoradoEngenharia de ComputaçãoDoutor em Engenharia Elétrica1142618CAPE

Contribution to Quality-driven Evolutionary Software Development process for Service-Oriented Architectures

The quality of software is a key element for the successful of a system. Currently, with the advance of the technology, consumers demand more and better services. Models for the development process have also to be adapted to new requirements. This is particular true in the case of service oriented systems (domain of this thesis), where an unpredictable number of users can access to one or several services. This work proposes an improvement in the models for the software development process based on the theory of the evolutionary software development. The main objective is to maintain and improve the quality of software as long as possible and with the minimum effort and cost. Usually, this process is supported on methods known in the literature as agile software development methods. Other key element in this thesis is the service oriented software architecture. Software architecture plays an important role in the quality of any software system. The Service oriented architecture adds the service flexibility, the services are autonomous and compact assets, and they can be improved and integrated with better facility. The proposed model in this thesis for evolutionary software development makes emphasis in the quality of services. Therefore, some principles of evolutionary development are redefined and new processes are introduced, such as: architecture assessment, architecture recovery and architecture conformance. Every new process will be evaluated with case studies considering quality aspects. They have been selected according to the market demand, they are: the performance, security and evolutionability. Other aspects could be considered of the same way than the three previous, but we believe that these quality attributes are enough to demonstrate the viability of our proposal