Article
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

A major determinant of the quality of software systems is the quality of their requirements, which should be both understandable and precise. Most requirements are written in natural language, good for understandability but lacking in precision. To make requirements precise, researchers have for years advocated the use of mathematics-based notations and methods, known as “formal”. Many exist, differing in their style, scope and applicability. The present survey discusses some of the main formal approaches and compares them to informal methods. The analysis uses a set of 9 complementary criteria, such as level of abstraction, tool availability, traceability support. It classifies the approaches into five categories: general-purpose, natural-language, graph/automata, other mathematical notations, seamless (programming-language-based). It presents approaches in all of these categories, altogether 22 different ones, including for example SysML, Relax, Eiffel, Event-B, Alloy. The review discusses a number of open questions, including seamlessness, the role of tools and education, and how to make industrial applications benefit more from the contributions of formal approaches. This is the full version of the survey, including some sections and two appendices which, because of length restrictions, do not appear in the submitted version. This article can be downloaded here: https://arxiv.org/pdf/1911.02564.pdf.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... Various systems and approaches are used with the Raspberry Pi [22]. This will establish machine-to-machine (M2M) communication where Raspberry Pi communicates with cloud infrastructure [23]. ...
... In addition, the cloud acts as a central hub for collecting and analyzing data. Moreover, that will leverage many advantages in the software testing phase, such as the following: [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [22], [23], [24], [25], [26] , [27], [28], [29], [30], [31], [32], [33], [34], [35], [36], [37], [38], [62], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [69] ...
... Software testing with knowledge management 24 27 [12], [13], [14], [15], [16], [17], [43], [51], [52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [70], [72] C3 IoT and Cloud infrastructure 9 10 [15], [18], [19], [20], [21], [23], [34], [44], [67] C4 Raspberry Pi robotic programming 14 16 [22], [23], [25], [32], [35], [36], [39], [66], [68], [71], [73], [74], [75], [76] Sum 88 1. Building a knowledge repository for all test case scenarios and storing data related to each software project component. This will contribute to overcoming the obstacles associated with preparing the test case data, such as redundancy and priority. ...
... Requirements drive system development and deployment. They are the first step on the way from the customer's problem to a technical solution [1]. That is, requirements serve as a translation of user and business needs into an implementable and operational solution. ...
... Most formal approaches focus on requirements per se, not directly connected to design and implementation [1], which makes it difficult to align requirement engineering with other software engineering tasks. Requirement engineering involves upfront and detailed analysis, which can be at odds with agile software development [13] and DevOps. ...
... Bruel et al. in [1] have identified five categories of approaches to specify requirements: natural language, semiformal, automata/graphs, mathematical, and seamless (programming-language-based) that are defined as follows: ...
Chapter
Full-text available
Security requirements vary in nature and form. These requirements may come from compliance checklists, implementation guidelines, corporate standards, and reports from organizations such as NIST, MITRE, and OWASP. Stakeholders may express additional requirements, depending on the context, to address threats and vulnerabilities as quickly as possible. Requirements are usually expressed in natural language, sometimes accompanied by tests, fixes, or descriptions of attack vectors. Analyzing, managing, verifying, validating, and tracing the requirements are therefore challenging as it relies heavily on human activity. Formalizing requirements for automated analysis and reuse can help to reduce human error-prone activities. Seamless Object-Oriented Requirement (SOOR) promotes a paradigm of multi-requirement views. In this paradigm, requirements are classes described in an object-oriented programming (OOP) language that combines representations in natural language with those in formal languages, such as LTL or Eiffel. The embedded formal language representations can provide means for validating requirements. In addition, the major advantage is that OOP supports seamless reuse of requirements classes and extensions through inheritance or associations. RQCODE is a novel approach based firstly on the implementation of SOOR in Java, and secondly on the applicability of SOOR to security requirements. This is done while providing a lightweight formalization through the associated tests that validate and strengthen system security according to the Security Technical Implementation Guide (STIG). We argue that this approach, also known as RQCODE, offers several advantages for formalizing, reusing, analyzing, and validating security requirements by automated means. In this chapter, we discuss the challenges of requirements specification in the cybersecurity domain and present our RQCODE approach.
... The approach for Q2 has two (2) phases. The first phase is a systematic literature review to identify information types or information classifications [70] [104]. The second phase is a comparative analysis of the identified information types and information contained in systems engineering requirement sentences. ...
... The approach for Q4, like Q2 and Q3, has the same two (2) phases. The first phase is a systematic literature review to identify factors that can be reviewed for potential impacts [70] [104]. The Cognition, Quality, and Accountability Factors and their components are drawn from multiple fields of science using keywords and themes established in the research findings of Q1, Q2, and Q3. ...
... Recall from Section 3.4, the approach for Q4 has two (2) phases: 1) systematic literature review to identify factors that can be reviewed for potential impacts [70] [104] and 2) application of the identified factors to the media types to identify potential impacts. The findings provide the rationale to support the potential inclusion of alternate media in systems engineering requirement expressions. ...
Thesis
“Requirements” are often presented as a necessary, if not mandated, component or tool of the systems engineering process. Despite their place in engineering, low quality requirements are the first potential mistakes of an engineering project and their effects are potentially felt downstream in the form of increased costs and schedule overruns. Innovations to improve requirements engineering have historically omitted the requirement media. This research provides the rationale and process heuristics to include alternate media requirement expressions within systems engineering which shifts accountability to higher context requirement expressions that may require less cognitive load while decreasing effort and schedule thereby potentially providing for more efficient systems engineering and more effective systems.
... The approach for Q2 has two (2) phases. The first phase is a systematic literature review to identify information types or information classifications [70] [104]. The second phase is a comparative analysis of the identified information types and information contained in systems engineering requirement sentences. ...
... The approach for Q4, like Q2 and Q3, has the same two (2) phases. The first phase is a systematic literature review to identify factors that can be reviewed for potential impacts [70] [104]. The Cognition, Quality, and Accountability Factors and their components are drawn from multiple fields of science using keywords and themes established in the research findings of Q1, Q2, and Q3. ...
... Recall from Section 3.4, the approach for Q4 has two (2) phases: 1) systematic literature review to identify factors that can be reviewed for potential impacts [70] [104] and 2) application of the identified factors to the media types to identify potential impacts. The findings provide the rationale to support the potential inclusion of alternate media in systems engineering requirement expressions. ...
... The work of Bruel et al. [10] discusses the effectiveness of different existing approaches to specify requirements. First, the work classifies the approaches in five categories: naturallanguage, semi-formal, automata/graphs, mathematical and seamless (programming language-based). ...
... In case the detection of the requirement pattern succeeds, then the translation phase follows (lines [9][10][11][12][13][14][15][16][17][18][19], where the User Layer model is possibly refined by adding new model elements. ...
Article
Full-text available
MDE enables the centrality of the models in semi-automated development processes. However, its level of usage in industrial settings is still not adequate for the benefits MDE can introduce. This paper proposes a semi-automatic approach for the completion of high-level models in the lifecycle of critical systems, which exhibit an event-driven behaviour. The proposal suggests a specification guideline that starts from a partial SysML model of a system and on a set of requirements, expressed in the well-known Given–When–Then paradigm. On the basis of such requirements, the approach enables the semi-automatic generation of new SysML state machines model elements. Accordingly, the approach focuses on the completion of the state machines by adding proper transitions (with triggers, guards and effects) among pre-existing states. Also, traceability modelling elements are added to the model. Two case studies demonstrate the feasibility of the proposed approach.
... Requirements can be encoded through textual or graphical supports (Bruel et al. 2021). Textual requirements lie on a spectrum from informal to semi-formal to formal. ...
Article
Full-text available
Growth in the complexity of advanced systems is mirrored by a growth in the number of engineering requirements and related upstream and downstream tasks. These requirements are typically expressed in natural language and require human expertise to manage. Natural language processing (NLP) technology has long been seen as promising to increase requirements engineering (RE) productivity but has yet to demonstrate substantive benefits. The recent addition of large language models (LLMs) to the NLP toolbox is now generating renewed enthusiasm in the hope that it will overcome past shortcomings. This article scrutinizes this claim by reviewing the application of LLMs for engineering requirements tasks. We survey the success of applying LLMs and the scale to which they have been used. We also identify groups of challenges shared across different engineering requirement tasks. These challenges show how this technology has been applied to RE tasks that need reassessment. We finalize by drawing a parallel to other engineering fields with similar challenges and how they have been overcome in the past – and suggest these as future directions to be investigated.
... Expressing system behavior in calculus notations like CCS is shown to be beneficial as it allows to evaluate the qualitative correctness of system properties, such as deadlock or live-lock. [78,26]. ...
Thesis
Full-text available
The conceptual design and discussion of multi-agents systems (MAS) typically focuses on agents and their models, and the elements and effects in the environment which they perceive. This view, however, leaves out potential pitfalls in the later implementation of the system that may stem from limitations in data models, interfaces, or protocols by which agents and environments exchange information. By today, the research community agrees that for this, that the environment should be understood as well as abstraction layer by which agents access, interpret, and modify elements within the environment. This, however, blurs the the line of the environment being the sum of interactive elements and phenomena perceivable by agents, and the underlying technology by which this information and interactions are offered to agents. This thesis proposes as remedy to consider as third component of multi agent systems, besides agents and environments, the digital medium by which the environment is provided to agents. "Medium" then refers to exactly this technological component via which environment data is published interactively towards the agents, and via which agents perceive, interpret, and finally, modify the underlying environment data. Furthermore, this thesis will detail how MAS may use capabilities of a properly chosen medium to achieve coordinating system behaviors. A suitable candidate technology for digital agent media comes from the Semantic Web in form of Linked Data. In addition to conceptual discussions about the notions of digital agent media, this thesis will provide in detail a specification of a Linked Data agent medium, and detail on means to implement MAS around Linked Data media technologies.
... FORM-L [28,29,31] is a domain-specific language [9] dedicated to properties (e.g. assumptions, objectives and requirements) and behavioural modelling. ...
Article
Full-text available
To correctly formalise requirements expressed in natural language, ambiguities must first be identified and then fixed. This paper focuses on behavioural requirements (i.e. requirements related to dynamic aspects and phenomena). Its first objective is to show, based on a practical, public case study, that the disambiguation process cannot be fully automated: even though natural language processing (NLP) tools and machine learning might help in the identification of ambiguities, fixing them often requires a deep, application-specific understanding of the reasons of being of the system of interest, of the characteristics of its environment, of which trade-offs between conflicting objectives are acceptable, and of what is achievable and what is not; it may also require arduous negotiations between stakeholders. Such an understanding and consensus-making ability is not in the reach of current tools and technologies, and will likely remain so for a long while. Beyond ambiguity, requirements are often marred by various other types of defects that could lead to wholly unacceptable consequences. In particular, operational experience shows that requirements inadequacy (whereby, in some of the situations the system could face, what is required is woefully inappropriate or what is necessary is left unspecified) is a significant cause for systems failing to meet expectations. The second objective of this paper is to propose a semantically accurate behavioural requirements formalisation format enabling tool-supported requirements verification, notably with simulation. Such support is necessary for the engineering of large and complex cyber-physical and socio-technical systems to ensure, first, that the specified requirements indeed reflect the true intentions of their authors and second, that they are adequate for all the situations the system could face. To that end, the paper presents an overview of the BASAALT (Behaviour Analysis and Simulation All Along systems Life Time) systems engineering method, and of FORM-L (FOrmal Requirements Modelling Language), its supporting language, which aims at representing as accurately and completely as possible the semantics expressed in the original, natural language behavioural requirements, and is markedly different from languages intended for software code generation. The paper shows that generally, semantically accurate formalisation is not a simple paraphrasing of the original natural language requirements: additional elements are often needed to fully and explicitly reflect all that is implied in natural language. To provide such complements for the case study presented in the paper, we had to follow different formalisation patterns, i.e. sequences of formalisation steps. For this paper, to avoid being skewed by what a particular automatic tool can and cannot do, BASAALT and FORM-L were applied manually. Still, the lessons learned could be used to specify and develop NLP tools that could assist the disambiguation and formalisation processes. However, more studies are needed to determine whether an exhaustive set of formalisation patterns can be identified to fully automate the formalisation process.
... There are five kinds of approaches for representing requirements: formal, natural-language, semi-formal, automata/graphs, and seamless [51]. ...
Article
Full-text available
Industrial cyber-physical systems (iCPSs) are the backbone of the fourth industrial revolution, facing more safety and security (S&S) challenges compared to traditional industrial systems. One of the most critical challenges is the collaborative analysis of S&S. Considerable efforts have been made towards integrating S&S and resolving their contradictions. However, a significant research gap remains regarding the accurate definition of contradictions in S&S requirements, along with an identification methodology. This study presents a systematical methodology to address this challenge. We propose two sufficient conditions that result in contradictions and provide algorithms to help their identification. Additionally, three measures have been proposed to reduce the difficulty of contradictions identification, including a conceptual model for iCPSs with S&S objectives to constrain objects and interactions within the model, a method for unifying the elicitation of S&S requirements, and a requirements template for coordinating the representation of S&S requirements. To provide insight into the operations of the methodology, we demonstrate its application in a smart factory. The results show that this approach can effectively identify the hidden contradictions in S&S requirements.
... However, they use textual and semi-formal approaches that are laborious to express and comprehend. Security standards are also written in natural language, and requirements specifications are abstract and often ambiguous [6,13,16]. For example, a requirement such as "The ICS shall ensure the security of its critical parameters through the use of cryptography." is abstract and vague since it does not expand the terms such as "critical parameters" and "cryptography". ...
Article
Full-text available
We must explicitly capture relationships and hierarchies between the multitude of system and security standards requirements. Current security requirements specification methods do not capture such structure effectively, making requirements management and traceability harder, consequently increasing costs and time to market for developing certified ICS. We propose a novel requirements repository model for ICS that uses labelled property graphs to structure and store system-specific and standards-based requirements using well-defined relationship types. Furthermore, we integrate the proposed requirements repository with design-time ICS tools to establish requirements traceability. A wind turbine case study illustrates the overall workflow in our framework. We demonstrate that a robust requirements traceability matrix is a natural consequence of using labelled property graphs. We also introduce a compatible requirements change management procedure that aids in adapting to changes in development and certification schemes.
... Firstly, our work has to take advantage of the best practices outlined by [13] and [14]. Secondly, the work has considered existing methods for requirements formalization as described in [15]. The proposed research deals with requirements modeling with OOP concepts and representation of requirements in several notations at once. ...
Preprint
For the last 20 years, the number of vulnerabili-ties has increased near 20 times, according to NIST statistics. Vulnerabilities expose companies to risks that may seriously threaten their operations. Therefore, for a long time, it has been suggested to apply security engineering-the process of accumulating multiple techniques and practices to ensure a sufficient level of security and to prevent vulnerabilities in the early stages of software development, including establishing security requirements and proper security testing. The informal nature of security requirements makes it uneasy to maintain system security, eliminate redundancy and trace requirements down to verification artifacts such as test cases. To deal with this problem, Seamless Object-Oriented Requirements (SOORs) promote incorporating formal requirements representations and verification means together into requirements classes. This article is a position paper that discusses opportunities to implement the Requirements as Code (RQCODE) concepts, SOORs in Java, applied to the Software Security domain. We argue that this concept has an elegance and the potential to raise the attention of developers since it combines a lightweight formalization of requirements through security tests with seamless integration with off-the-shelf development environments, including modern Continuous Integration/Delivery platforms. The benefits of this approach are yet to be demonstrated in further studies in the VeriDevOps project.
... In this section, we survey several RE approaches based on criteria that we define in section 2.1.1. A complementary work to this section can be found in [19]. ...
Thesis
Proving that a system satisfies its requirements is an important challenge of Requirements Engineering. On the one hand, formal approaches provide a way to express requirements mathematically and prove that a system satisfies its requirements. However, if formalization offers additional possibilities such as verification, or even validation, it often proves to be too difficult to use in practice by the stakeholders involved in the development of systems. On the other hand, in most cases, requirements are written and sometimes traced in Natural Language for communication and mutual understanding purposes. Moreover, this remains during the whole development process. Thus, it is necessary to consider the need to address all these stakeholders during the development process. The main objective of this thesis is to provide a seamless methodology that allows benefiting from the formalization of requirements while being understandable by all stakeholders. We propose an approach that considers requirements as parts of the system's code, which, as such, contributes to improving quality assessment. In addition, integrating the requirements into the code guarantees a seamless development. The contributions target three main benefits. First, there is no need to switch from one tool or environment to another: a single framework supports the development from analysis to implementation. Second, changes and reversibility become a regular occurrence, directly supported by the method, language, and tools, facilitating round-trips. Third, the different levels of abstraction remain inside the object-oriented paradigm. We apply this vision to the development process itself with the same expected advantages. The development life-cycle can then benefit from this strong integration of requirements into the code. These artifacts help in software development by providing support and guidelines for analysis or decision support and reinforcing the software quality. Besides, reusability, evolutivity, and maintainability are enhanced. Traceability between requirements and code allows an easy impact analysis when any of these artifacts evolve. However, if this paradigm is familiar to developers and even if we put an effort in providing expressivity, they are not addressed to other stakeholders that used to work with several tools. Since we also want non-experts to use our approach to validate systems in the early stage of their development, we propose a Domain-Specific Language: (i) close to natural language and (ii) based on formal semantics. Using Model-Driven Engineering techniques, this language bridges the gap between the several stakeholders involved in a project (considering their different backgrounds) and between the requirements and the code. We finally put a research effort into defining relationships between requirements. We provide their formal definitions and properties on the propagation of the satisfaction state. These definitions can help engineers verify requirements (by checking the validity of the semantics of the relationships between two requirements) and verify the system compliance (thanks to satisfaction propagation). This work is a step towards introducing formal semantics into traceability, making it possible to automatically analyze requirements and use their relationships to verify the corresponding implementation of the system.
... In our context, formal modeling environments [4] such as USE [5]- [7] or Alloy [8] provide quality-related features to software developers. First, they enable developers to verify correctness properties about models, e.g., whether the model contains contradictory constraints. ...
Conference Paper
Full-text available
This contribution proposes to apply informal ideas for model development within a formal tool. The basic idea is to relax the requirements expressed with particular modeling language elements and allow developers to dynamically customize the level of formality in a visual and intuitive way. For UML and OCL class models, the requirements for usual object typing, role typing, role multiplicity, attribute typing and constraint satisfaction are relaxed in order to achieve flexible object models. The long-term aim is to support flexible, iterative model development with qualified tool feedback.
Article
Technical specifications and intended functionalities are often gathered in documents that include requirements written in constrained natural language, that is, natural‐like language with restricted syntax. In the automotive industry one challenge is the ability to produce safe vehicles, emphasizing the importance of safety by design. In the framework of case studies based on functions of autonomous vehicles, we introduce a systematic process for building formal models from automotive requirements written in constrained natural language, and for verifying them. By allowing formal verification at the earliest stages of the development cycle our aim is to avoid the costly discovery of errors at later stages.
Article
Requirements engineering is a critical activity in developing complex cyber-physical systems. Requirements are usually expressed using natural language, which may be ambiguous, inconsistent, or incomplete. These issues in requirements qualities may introduce errors in system design that lead to high project cost overruns. Hence it is essential to verify the qualities of requirements early. Since formal methods have demonstrated their ability to verify system designs and are increasingly adopted to support requirements engineering for software systems, a question arises about adapting formal methods to account for specific properties of cyber-physical systems. Even if there are many literature reviews concerning requirements engineering, there is a lack of a global view on the reviews that specifically address the issues related to validation and verification (V&V) of requirements. This paper aims to provide an overview of literature reviews related to requirements V&V and mainly investigates the use of formal approaches and models for preventing, detecting, or correcting errors occurring in requirements and identifies the main challenges of adopting formal methods on requirements engineering for cyber-physical systems.
Article
Formal Methods are mathematically-based techniques for software design and engineering, which enable the unambiguous description of and reasoning about a system’s behaviour. Autonomous systems use software to make decisions without human control, are often embedded in a robotic system, are often safety-critical, and are increasingly being introduced into everyday settings. Autonomous systems need robust development and verification methods, but formal methods practitioners are often asked: Why use Formal Methods for Autonomous Systems? To answer this question, this position paper describes five recipes for formally verifying aspects of an autonomous system, collected from the literature. The recipes are examples of how Formal Methods can be an effective tool for the development and verification of autonomous systems. During design, they enable unambiguous description of requirements; in development, formal specifications can be verified against requirements; software components may be synthesised from verified specifications; and behaviour can be monitored at runtime and compared to its original specification. Modern Formal Methods often include highly automated tool support, which enables exhaustive checking of a system’s state space. This paper argues that Formal Methods are a powerful tool for the repertoire of development techniques for safe autonomous systems, alongside other robust software engineering techniques.
Article
Full-text available
Reference to the paper: https://arxiv.org/abs/2004.01099 Context: NLP4RE-Natural language processing (NLP) supported requirements engineering (RE)-is an area of research and development that seeks to apply NLP techniques, tools and resources to a variety of requirements documents or artifacts to support a range of linguistic analysis tasks performed at various RE phases. Such tasks include detecting language issues, identifying key domain concepts and establishing traceability links between requirements. Objective: This article surveys the landscape of NLP4RE research to understand the state of the art and identify open problems. Method: The systematic mapping study approach is used to conduct this survey, which identified 404 relevant primary studies and reviewed them according to five research questions, cutting across five aspects of NLP4RE research, concerning the state of the literature, the state of empirical research, the research focus, the state of the practice, and the NLP technologies used. Results: (i) NLP4RE is an active and thriving research area in RE that has amassed a large number of publications and attracted widespread attention from diverse communities; (ii) most NLP4RE studies are solution proposals having only been evaluated using a laboratory experiment or an example application; (iii) most NLP4RE studies have focused on the analysis phase, with detection as their central linguistic analysis task and requirements specification as their commonly processed document type; (iv) 130 new tools have been proposed by the selected studies to support a range of linguistic analysis tasks, but there is little evidence of adoption in the long term, although some industrial applications have been published; (v) 140 NLP techniques (e.g., POS tagging and tokenization), 66 NLP tools (e.g., Stanford CoreNLP and GATE) and 25 NLP resources (WordNet and British National Corpus) are extracted from the selected studies, but most of them-particularly those novel NLP techniques and specialized tools-are not in frequent use; by contrast, frequently used NLP technologies are syntactic analysis techniques, general-purpose tools and generic language lexicons. Conclusion: There is a huge discrepancy between the state of the art and the state of the practice in current NLP4RE research, indicated by insufficient industrial validation of NLP4RE research, little evidence of industrial adoption of the proposed tools, the lack of shared RE-specific language resources, and the lack of NLP expertise in NLP4RE research to advise on the choice of NLP technologies. 2 CCS Concepts: • Software and its engineering➝ Software creation and management➝ Designing software➝ Requirements analysis KEYWORDS Requirements engineering, software engineering, natural language processing, NLP, systematic mapping study, systematic review
Article
Full-text available
Auto-active verifiers provide a level of automation intermediate between fully automatic and interactive: users supply code with annotations as input while benefiting from a high level of automation in the back-end. This paper presents AutoProof, a state-of-the-art auto-active verifier for object-oriented sequential programs with complex functional specifications. AutoProof fully supports advanced object-oriented features and a powerful methodology for framing and class invariants, which make it applicable in practice to idiomatic object-oriented patterns. The paper focuses on describing AutoProof ’s interface, design, and implementation features, and demonstrates AutoProof ’s performance on a rich collection of benchmark problems. The results attest AutoProof ’s competitiveness among tools in its league on cutting-edge functional verification of object-oriented programs.
Article
Full-text available
FIND THE PREPRINT at http://rdcu.be/HtDi In the railway safety-critical domain requirements documents have to abide to strict quality criteria. Rule-based natural language processing (NLP) techniques have been developed to automatically identify quality defects in natural language requirements. However, the literature is lacking empirical studies on the application of these techniques in industrial settings. Our goal is to investigate to which extent NLP can be practically applied to detect defects in the requirements documents of a railway signalling manufacturer. To address this goal, we first identified a set of typical defects classes, and, for each class, an engineer of the company implemented a set of defect-detection patterns by means of the GATE tool for text processing. After a preliminary analysis, we applied the patterns to a large set of 1866 requirements previously annotated for defects. The output of the patterns was further inspected by two domain experts to check the false positive cases. Additional discard-patterns were defined to automatically remove these cases. Finally, SREE, a tool that searches for typically ambiguous terms, was applied to the requirements. The experiments show that SREE and our patterns may play complementary roles in the detection of requirements defects. This is one of the first works in which defect detection NLP techniques are applied on a very large set of industrial requirements annotated by domain experts. We contribute with a comparison between traditional manual techniques used in industry for requirements analysis, and analysis performed with NLP. Our experience shows that several discrepancies can be observed between the two approaches. The analysis of the discrepancies offers hints to improve the capabilities of NLP techniques with company specific solutions, and suggests that also company practices need to be modified to effectively exploit NLP tools.
Article
Full-text available
Natural language processing (NLP) and requirements engineering (RE) have had a long relationship, yet their combined use isn’t well established in industrial practice. This situation should soon change. The future evolution of the application of NLP technologies in RE can be viewed from four dimensions: discipline, dynamism, domain knowledge, and datasets.
Article
Full-text available
Not only system assurance drives a need for semantically richer relationships across various artifacts, work products, and items of information than are implied in the terms “trace and traceability” as used in current standards and textbooks. This paper deals with the task of working out artifacts in software and system development, their representation, and the analysis and documentation of the relationships between their logical contents—herein referred to as tracing and traceability; this is a richer meaning of traceability than in standards like IEEE STD 830. Among others, key tasks in system development are as follows: capturing, analyzing, and documenting system-level requirements, the step to functional system specifications, the step to architectures given by the decomposition of systems into subsystems with their connections and behavioral interactions. Each of these steps produces artifacts for documenting the development, as a basis for a specification and a design rationale, for documentation, for verification, and impact analysis of change requests. Crucial questions are how to represent and formalize the content of these artifacts and how to relate their content to support, in particular, system assurance. When designing multi-functional systems, key artifacts are system-level requirements, functional specifications, and architectures in terms of their subsystem specifications. Links and traces between these artifacts are introduced to relate their contents. Traceability has the goal to relate artifacts. It is required for instance in standards for functional system safety such as the ISO 26262. An approach to specifying semantic relationships is shown, such that the activity of creating and using (navigating through) these relationships can be supported with automation.
Article
Full-text available
A number of formal methods exist for capturing stimulus-response requirements in a declarative form. Someone yet needs to translate the resulting declarative statements into imperative programs. The present article describes a method for specification and verification of stimulus-response requirements in the form of imperative program routines with conditionals and assertions. A program prover then checks a candidate program directly against the stated requirements. The article illustrates the approach by applying it to an ASM model of the Landing Gear System, a widely used realistic example proposed for evaluating specification and verification techniques.
Article
Full-text available
Existing techniques of Design by Contract do not allow software developers to specify complete contracts in many cases. Incomplete contracts leave room for malicious implementations. This article complements Design by Contract with a simple yet powerful technique that removes the problem without adding syntactical mechanisms. The proposed technique makes it possible not only to derive complete contracts, but also to rigorously check and improve completeness of existing contracts without instrumenting them.
Article
Full-text available
This article describes the Event-B modeling of a landing gear system of an aircraft whose complete description can be found in Boniol and Wiels (The Landing Gear System Case Study, ABZ Case Study, Communications in Computer Information Science, vol 433, Springer, Berlin, 2014). This real-life case study has been proposed by the ABZ’2014 track that took place in Toulouse, the European capital of the aeronautic industry. Our modeling is based on the Parnas and Madey’s 4-Variable Model that permits to consider the different parts of a system. These parts are incrementally introduced using the Event-B refinement technique. The entire development has been carried out with the Rodin toolset. To ensure the correctness of the different components, we use several verification techniques (animation, model checking and proof) depending on the complexity and the kind of the properties to verify. Basically, prior to the proof phase that can be tedious and complex, we use the animator AnimB and the model checker ProB that permit to discover some trivial inconsistencies. Once no error is reported, we start the proof phase by using the Atelier B and SMT provers which we installed on Rodin. We conclude the article by drawing up some key findings of and lessons learned from this experience.
Article
Full-text available
Goal modeling in general, and i∗ in particular, are typically taught in specialized courses that are part of postgraduate programs. In this paper, we report on our experience concerning teaching i∗ and its basic, essential dialect called simple i∗ to over 130 first-year students of a bachelor degree in information science. We present the intended learning outcomes and activities, we introduce the simple i∗ dialect that was used in the labs, we discuss the gained knowledge was tested in the final exam, and we discuss the obtained results.
Article
Full-text available
This paper describes the modeling, done using the Event-B notation, of the aircraft landing gear case study that is proposed in a special track of the ABZ'2014 Conference. In the course of our development, we discovered some problems in our initial modeling approach. This has led us to propose a second approach and then a third one. Each approach is more efficient than the previous one in terms of proof obligations (roughly speaking: 2000, 1000, 500). All this will be described in this paper. We also try to go beyond this specific case study and give some thoughts about large industrial modeling.
Article
Full-text available
One significant problem requirements engineers have to cope with is the management of unclear requirements, ambiguities, and conflicts that may arise between stakeholders. Such issues may be desirable since they may allow for further elicitation of requirements that would have been missed otherwise. Goal models capture the objectives and other intentions of different stakeholders, together with their relationships. They can be used to refine unclear requirements and to detect conflicts and ambiguities early during model validation. However, resolving such ambiguities and conflicts is key for the successful implementation of the goal models. In this paper, we propose a novel approach to validate models in the Goal-oriented Requirement Language and resolve conflicts between the perspectives of intervening stakeholders (and especially between stakeholders of a given group). Our approach is based on a statistical analysis of empirical data that we collect from surveys designed for each group of stakeholders. We apply concept analysis in order to fix goal-model artifacts that are subject to conflict. We illustrate our approach using a case study of a goal model describing the involvement of undergraduate students in university research activities.
Article
Full-text available
Goal models represent interests, intentions, and strategies of different stakeholders. Reasoning about the goals of a system unavoidably involves the transformation of unclear stakeholder requirements into goal-oriented models. The ability to validate goal models would support the early detection of unclear requirements, ambiguities, and conflicts. In this paper, we propose a novel validation approach based on the Goal-oriented Requirement Language (GRL) to check the correctness of GRL goal models through statistical analyses of data collected from generated questionnaires. System stakeholders (e.g., customers, shareholders, and managers) may have different objectives, interests, and priorities. Stakeholder conflicts arise when the needs of some group of stakeholder compromise the expectations of some other group(s) of stakeholders. Our proposed approach allows for early detection of potential conflicts amongst intervening stakeholders of the system. In order to illustrate and demonstrate the feasibility of the approach, we apply it to a case study of a GRL model describing the fostering of the relationship between the university and its alumni. The approach brings unique benefits over the state of the art and is complementary to existing validation approaches.
Conference Paper
Full-text available
[Context and motivation] Stakeholder requirements are notoriously informal, vague, ambiguous and often unattainable. The requirements engineering problem is to formalize these requirements and then transform them through a systematic process into a formal specification that can be handed over to designers for downstream development. [Question/problem] This paper proposes a framework for transforming informal requirements to formal ones, and then to a specification. [Principal ideas/results] The framework consists of an ontology of requirements, a formal requirements modeling language for representing both functional and non-functional requirements, as well as a rich set of refinement operators whereby requirements are incrementally transformed into a formal, practically satisfiable and measurable specification. [Contributions] Our proposal includes a systematic, tool-supported methodology for conducting this transformation. For evaluation, we have applied our framework to a public requirements dataset. The results of our evaluation suggest that our ontology and modeling language are adequate for capturing requirements, and our methodology is effective in handling requirements in practice.
Article
Full-text available
Requirements engineering (RE) has attracted a great deal of attention from researchers and practitioners in recent years. Requirements engineering education (REE) is therefore an important undertaking if the field is to have professionals who are capable of successfully accomplishing software projects. This increasing interest demands that academia should provide software engineering students with a solid foundation in the subject matter. This paper aims to identify and to present the current research on REE that is available at present, and to select useful approaches and needs for future research. A systematic mapping study was therefore performed to classify the selected studies into five classification criteria: research type, empirical type, contribution type, RE activity, and curricula. A total of 79 papers were selected and classified according to these criteria. The results of this systematic mapping study are discussed, and a list of advice obtained from the REE literature for instructors is provided.
Article
Full-text available
Little contemporary data exists that documents software requirements elicitation, requirements specification, document development, and specification validation practices. An exploratory survey of more than 3,000 software professionals was conducted and nearly 250 responses were obtained. Survey data obtained includes characteristics of projects, practices, organizations, and practitioners related to requirements engineering. Selected results are presented along with interpretations of this data.
Article
Full-text available
The success of a number of projects has been shown to be significantly improved by the use of a formalism. However, there remains an open issue: to what extent can a development process based on a singular formal notation and method succeed. The majority of approaches demonstrate a low level of flexibility by attempting to use a single notation to express all of the different aspects encountered in software development. Often, these approaches leave a number of scalability issues open. We prefer a more eclectic approach. In our experience, the use of a formalism-based toolkit with adequate notations for each development phase is a viable solution. Following this principle, any specific notation is used only where and when it is really suitable and not necessarily over the entire software lifecycle. The approach explored in this article is perhaps slowly emerging in practice - we hope to accelerate its adoption. However, the major challenge is still finding the best way to instantiate it for each specific application scenario. In this work, we describe a development process and method for automotive applications which consists of five phases. The process recognizes the need for having adequate (and tailored) notations (Problem Frames, Requirements State Machine Language, and Event-B) for each development phase as well as direct traceability between the documents produced during each phase. This allows for a stepwise verification/validation of the system under development. The ideas for the formal development method have evolved over two significant case studies carried out in the DEPLOY project.
Article
One way to improve the quality of a system level informal requirements document is to check it for goodness properties and fix any checking errors. Several lists of goodness properties are available but they differ by author. And a sound basis for selecting goodness properties is seldom provided. We propose a set of goodness properties which were developed from a larger list of properties using selection criteria as this sound basis. In previous work we established a set of criteria for selecting which properties represent high quality in an informal requirements document. This paper extends that work by applying the selection criteria to a large set of candidate properties. Through a process of refining, combining, splitting, and discarding of candidate properties using the selection criteria, we arrived at the limited set of high quality properties. This paper describes that process.
Article
Formal methods have provided approaches for investigating software engineering fundamentals and also have high potential to improve current practices in dependability assurance. In this article, we summarise known strengths and weaknesses of formal methods. From the perspective of the assurance of robots and autonomous systems (RAS), we highlight new opportunities for integrated formal methods and identify threats to the adoption of such methods. Based on these opportunities and threats, we develop an agenda for fundamental and empirical research on integrated formal methods and for successful transfer of validated research to RAS assurance. Furthermore, we outline our expectations on useful outcomes of such an agenda.
Chapter
Insufficient requirements reusability, understandability and verifiability jeopardize software projects. Empirical studies show little success in improving these qualities separately. Applying object-oriented thinking to requirements leads to their unified treatment. An online library of reusable requirement templates implements recurring requirement structures, offering a starting point for practicing the unified approach.KeywordsObject-oriented requirementsReusable requirementsUnderstandable requirementsVerifiable requirements
Article
Autonomous robotic systems are complex, hybrid, and often safety critical; this makes their formal specification and verification uniquely challenging. Though commonly used, testing and simulation alone are insufficient to ensure the correctness of, or provide sufficient evidence for the certification of, autonomous robotics. Formal methods for autonomous robotics have received some attention in the literature, but no resource provides a current overview. This article systematically surveys the state of the art in formal specification and verification for autonomous robotics. Specially, it identifies and categorizes the challenges posed by, the formalisms aimed at, and the formal approaches for the specification and verification of autonomous robotics.
Article
The considerable effort of writing requirements is only worthwhile if the result meets two conditions: the requirements reflect stakeholders’ needs, and the implementation satisfies them. In usual approaches, the use of different notations for requirements (often natural language) and implementations (a programming language) makes both conditions elusive. AutoReq, presented in this article, takes a different approach to both the writing of requirements and their verification. Applying the approach to a well-documented example, a landing gear system, allowed for a mechanical proof of consistency and uncovered an error in a published discussion of the problem.
Conference Paper
Agile approaches are known by making the use of informal elicitation techniques for requirements specification. The exclusive use of these techniques may cause some issues, such as ambiguous specifications and information lack. In this work we investigate better approaches to specify requirements in agile projects. Thus, we conducted an empirical evaluation about applicability of a formal method as specification technique, using mathematical logic as a possibility to solve limitations of informal specification. Initially, we conducted a survey to obtain the agile team practitioners opinion. Furthermore, we conducted two separated case studies in two agile teams to evaluate the applicability of Z notation in the requirements specification. Our initial results pointed out that formal specification assists on making complex requirements clearer and decreasing the time to understand their meanings.
Book
As requirements engineering continues to be recognized as the key to on-time and on-budget delivery of software and systems projects, many engineering programs have made requirements engineering mandatory in their curriculum. In addition, the wealth of new software tools that have recently emerged is empowering practicing engineers to improve their requirements engineering habits. However, these tools are not easy to use without appropriate training. Filling this need, Requirements Engineering for Software and Systems, Second Edition has been vastly updated and expanded to include about 30 percent new material. In addition to new exercises and updated references in every chapter, this edition updates all chapters with the latest applied research and industry practices. It also presents new material derived from the experiences of professors who have used the text in their classrooms. Improvements to this edition include: • An expanded introductory chapter with extensive discussions on requirements analysis, agreement, and consolidation • An expanded chapter on requirements engineering for Agile methodologies • An expanded chapter on formal methods with new examples • An expanded section on requirements traceability • An updated and expanded section on requirements engineering tools • New exercises including ones suitable for research projects Following in the footsteps of its bestselling predecessor, the text illustrates key ideas associated with requirements engineering using extensive case studies and three common example systems: an airline baggage handling system, a point-of-sale system for a large pet store chain, and a system for a smart home. This edition also includes an example of a wet well pumping system for a wastewater treatment station. With a focus on software-intensive systems, but highly applicable to non-software systems, this text provides a probing and comprehensive review of recent developments in requirements engineering in high integrity systems.
Chapter
Software development projects seeking a high level of accuracy reach out to formal methods as early as the requirements engineering phase. However the client perspective of the future system is presented in an informal requirements document. The gap between the formal and informal approaches (and the artifacts used and produced by them) adds further complexity to an already rigorous task of software development. Our goal is to bridge this gap through a fine-grained level of traceability between the client-side informal requirements document to the developer-side formal specifications using a semi-formal modeling technique, model federation. Such a level of traceability can be exploited by the requirements engineering process for performing different actions that involve either or both these informal and formal artifacts. The effort and time consumed in developing such a level of traceability pays back in the later phases of a development project. For example, one can accurately narrow down the requirements responsible for an inconsistency in proof obligations during the analysis phase. We illustrate our approach using a running example from a landing gear system case study.
Article
The Chord distributed hash table (DHT) is well-known and often used to implement peer-to-peer systems. Chord peers find other peers, and access their data, through a ring-shaped pointer structure in a large identifier space. Despite claims of proven correctness, i.e., eventual reachability, previous work has shown that the Chord ring-maintenance protocol is not correct under its original operating assumptions. Previous work has not, however, discovered whether Chord could be made correct under the same assumptions. The contribution of this paper is to provide the first specification of correct operations and initialization for Chord, an inductive invariant that is necessary and sufficient to support a proof of correctness, and two independent proofs of correctness. One proof is informal and intuitive, and applies to networks of any size. The other proof is based on a formal model in Alloy, and uses fully automated analysis to prove the assertions for networks of bounded size. The two proofs complement each other in several important ways.
Conference Paper
Requirements and code, in conventional software engineering wisdom, belong to entirely different worlds. Is it possible to unify these two worlds? A unified framework could help make software easier to change and reuse. To explore the feasibility of such an approach, the case study reported here takes a classic example from the requirements engineering literature and describes it using a programming language framework to express both domain and machine properties. The paper describes the solution, discusses its benefits and limitations, and assesses its scalability.
Conference Paper
This document presents a landing gear system. It describes the system and provides some of its requirements. We propose this case study as a benchmark for techniques and tools dedicated to the verification of behavioral properties of systems.
Article
Future users of large data banks must be protected from having to know how the data is [sic] organized in the machine (the internal representation). A prompting service which supplies such information is not a satisfactory solution. Activities of users at terminals and most application programs should remain unaffected when the interned representation of data is changed and even when some aspects of the external representation are changed. Changes in data representation will often be needed as a result of changes in query, update, and report traffic and natural growth in the types of stored information. Existing noninferential, formatted data systems provide users with tree-structured files or slightly more general network models of the data. Inadequacies of these models are discussed. A model based on n-ary relations, a normal form for data base relations, and the concept of a universal data sublanguage are introduced.
Book
A formal method is not the main engine of a development process, its contribution is to improve system dependability by motivating formalisation where useful. This book summarizes the results of the DEPLOY research project on engineering methods for dependable systems through the industrial deployment of formal methods in software development. The applications considered were in automotive, aerospace, railway, and enterprise information systems, and microprocessor design. The project introduced a formal method, Event-B, into several industrial organisations and built on the lessons learned to provide an ecosystem of better tools, documentation and support to help others to select and introduce rigorous systems engineering methods. The contributing authors report on these projects and the lessons learned. For the academic and research partners and the tool vendors, the project identified improvements required in the methods and supporting tools, while the industrial partners learned about the value of formal methods in general. A particular feature of the book is the frank assessment of the managerial and organisational challenges, the weaknesses in some current methods and supporting tools, and the ways in which they can be successfully overcome. The book will be of value to academic researchers, systems and software engineers developing critical systems, industrial managers, policymakers, and regulators. © 2013 Springer-Verlag Berlin Heidelberg. All rights are reserved.
Article
As offshore development has become common for software companies, those companies have started to concentrate their engineers' effort upon the early development phase of software. Within this context, it is important to educate professional engineers to master all aspects of requirements engineering. It is not easy to master the various aspect all at once. However, we can expect professional engineers to study methods on their own if they believe that learning the methods is important for them or their projects. We have developed a two-and-a-half-day role-playing workshop for professional engineers that focuses on teaching the importance of requirements engineering, as well as the background, rationale, and purpose of the requirements to guarantee success in their projects. We start this paper with an overview of requirements engineering and its techniques, and then, introduce the instructional design of our course for professional engineers. We also present the results of an actual workshop, which showed engineers could earned clients' mindsets and the importance of the rationale of requirements.
Article
This article describes a formal analysis technique, called consistency checking, for automatic detection of errors, such as type errors, nondeterminism, missing cases, and circular definitions, in requirements specifications. The technique is designed to analyze requirements specifications expressed in the SCR (Software Cost Reduction) tabular notation. As background, the SCR approach to specifying requirements is reviewed. To provide a formal semantics for the SCR notation and a foundation for consistency checking, a formal requirements model is introduced; the model represents a software system as a finite-state automaton, which produces externally visible outputs in response to changes in monitored environmental quantities. Results of two experiments are presented which evaluated the utility and scalability of our technique for consistency checking in a real-world avionics application. The role of consistency checking during the requirements phase of software development is discussed.
Article
The paper presents an approach for rigorous development of safety-critical systems based on the Abstract State Machine formal method. The development process starts from a high level formal view of the system and, through refinement, derives more detailed models till the desired level of specification. Along the process, different validation and verification activities are available, as simulation, model review, and model checking. Moreover, each refinement step can be proved correct using an SMT-based approach. As last step of the refinement process, a Java implementation can be developed and linked to the formal specification. The correctness of the implementation w.r.t. its formal specification can be proved by means of model-based testing and runtime verification. The process is exemplified by using a Landing Gear System as case study.
Article
Templates are effective tools for increasing the precision of natural language requirements and for avoiding ambiguities that may arise from the use of unrestricted natural language. When templates are applied, it is important to verify that the requirements are indeed written according to the templates. If done manually, checking conformance to templates is laborious, presenting a particular challenge when the task has to be repeated multiple times in response to changes in the requirements. In this article, using techniques from Natural Language Processing (NLP), we develop an automated approach for checking conformance to templates. Specifically, we present a generalizable method for casting templates into NLP pattern matchers and reflect on our practical experience implementing automated checkers for two well-known templates in the Requirements Engineering community. We report on the application of our approach to four case studies. Our results indicate that: (1) our approach provides a robust and accurate basis for checking conformance to templates; and (2) the effectiveness of our approach is not compromised even when the requirements glossary terms are unknown. This makes our work particularly relevant to practice, as many industrial requirements documents have incomplete glossaries.
Conference Paper
Auto-active verifiers provide a level of automation intermediate between fully automatic and interactive: users supply code with annotations as input while benefiting from a high level of automation in the back-end. This paper presents AutoProof, a state-of-the-art auto-active verifier for object-oriented sequential programs with complex functional specifications. AutoProof fully supports advanced object-oriented features and a powerful methodology for framing and class invariants, which make it applicable in practice to idiomatic object-oriented patterns. The paper focuses on describing AutoProof's interface, design, and implementation features, and demonstrates AutoProof's performance on a rich collection of benchmark problems. The results attest AutoProof's competitiveness among tools in its league on cutting-edge functional verification of object-oriented programs.
Article
We present a broad extension of the conventional formalism of state machines and state diagrams, that is relevant to the specification and design of complex discrete-event systems, such as multi-computer real-time systems, communication protocols and digital control units. Our diagrams, which we call statecharts, extend conventional state-transition diagrams with essentially three olements, dealing, respectively, with the notions of hierarchy, concurrency and communication. These transform the language of state diagrams into a highly structured' and economical description language. Statecharts are thus compact and expressive--small diagrams can express complex behavior--as well as compositional and modular. When coupled with the capabilities of computerized graphics, statecharts enable viewing the description at different levels of detail, and make even very large specifications manageable and comprehensible. In fact, we intend to demonstrate here that statecharts counter many of the objections raised against conventional state diagrams, and thus appear to render specification by diagrams an attractive and plausible approach. Statecharts can be used either as a stand-alone behavioral description or as part of a more general design methodology that deals also with the system's other aspects, such as functional decomposition and data-flow specification. We also discuss some practical experience that was gained over the last three years in applying the statechart formalism to the specification of a particularly complex system.
Article
This paper suggests that input and output are basic primitives of programming and that parallel composition of communicating sequential processes is a fundamental program structuring method. When combined with a development of Dijkstra's guarded command, these concepts are surprisingly versatile. Their use is illustrated by sample solutions of a variety of a familiar programming exercises.
Conference Paper
The objective of the ongoing OMG standard about a foundational UML subset semantics (fUML) is twofold: providing operational semantics for a UML subset, and ease unambiguous and automatic model exploitations. Its impact could however be limited if usual UML profiling practices do not evolve. Profiles are the traditional way to specialize UML semantics and handle semantic variation points. However, they are usually defined in a way that only informally addresses the semantic issue, potentially limiting the benefits that fUML could bring in UML based methodologies. UML profiling practices must evolve: we propose to explicitly encapsulate operational semantics into stereotype operations, and provide a way to intuitively handle semantic variation points through template parameters. We illustrate the usage of these mechanisms and demonstrate their potential benefits. We also show that no UML metamodel modifications are required to support them, so that their implementation in L3-compliant UML tools is straightforward.
Conference Paper
While all systems have non-functional requirements (NFRs), they may not be explicitly stated in a formal requirements specification. Furthermore, NFRs may also be externally imposed via government regulations or industry standards. As some NFRs represent emergent system proprieties, those NFRs require appropriate analysis and design efforts to ensure they are met. When the specified NFRs are not met, projects incur costly re-work to correct the issues. The goal of our research is to aid analysts in more effectively extracting relevant non-functional requirements in available unconstrained natural language documents through automated natural language processing. Specifically, we examine which document types (data use agreements, install manuals, regulations, request for proposals, requirements specifications, and user manuals) contain NFRs categorized to 14 NFR categories (e.g. capacity, reliability, and security). We measure how effectively we can identify and classify NFR statements within these documents. In each of the documents evaluated, we found NFRs present. Using a word vector representation of the NFRs, a support vector machine algorithm performed twice as effectively compared to the same input to a multinomial naïve Bayes classifier. Our k-nearest neighbor classifier with a unique distance metric had an F1 measure of 0.54, outperforming in our experiments the optimal naïve Bayes classifier which had a F1 measure of 0.32. We also found that stop word lists beyond common determiners had no minimal performance effect.
Article
The features of concurrency provide important concepts for problem solving in a wide range of application areas. Many languages have now been developed to support this approach, with various notations being proposed. Occam is a programming language which supports concurrency using the process as its program structure, and provides synchronous communication between these processes. This paper presents the main features of occam and illustrates its use through various examples.
Article
0. Introduction.- 1. Experimenting on nondeterministic machines.- 2. Synchronization.- 3. A case study in synchronization and proof techniques.- 4. Case studies in value-communication.- 5. Syntax and semantics of CCS.- 6. Communication trees (CTs) as a model of CCS.- 7. Observation equivalence and its properties.- 8. Some proofs about data structures.- 9. Translation into CCS.- 10. Determinancy and confluence.- 11. Conclusion.
Article
Goals play an important role in requirements engineering process, and consequently in systems development process. Whereas specifications allow us to answer the question "WHAT the system does", goals allow us to address the "WHY, WHO, WHEN" ques- tions (5). Up to now, the main software development approaches using formal methods, such as Event-B, begins at the specification level. Our objective is to include require- ments analysis within this process, and more precisely the KAOS method, which is a goal-oriented methodology for requirements engineering. The latter allows analysts to build requirements models and to derive requirements documents. Existing work that combine KAOS with formal methods generate a formal specification model from a KAOS requirements model. We aim at expressing KAOS goal models with a formal language (Event-B), hence staying at the same abstraction level. Thus we take advantage from the Event-B method: (i) it is possible to use the method during the whole development pro- cess and (ii) we can benefit from the industrial maturity of tools supporting the method. For that purpose, we propose a constructive approach in which Event-B models are built incrementally from KAOS goal models, driven by goal refinement patterns.