DOCSLIB.ORG

Requirements Engineering

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Requirements Engineering ESPOO 2003 VTT PUBLICATIONS 508 VTT PUBLICATIONS 508 VTT VTT PUBLICATIONS 490 Vaskivuo, Teemu. Software architecture for decentralised distribution services in spontaneous Päivi Parviainen, Hanna Hulkko, Jukka networks. 2003. 99 p. 491 Mannersalo, Petteri. Gaussian and multifractal processes in teletraffic theory. 2003. 44 p. + Kääriäinen, Juha Takalo & Maarit Tihinen app. 109 p. Requirements engineering. Inventory of technologies. 492 Himanen, Mervi. The Intelligence of Intelligent Buildings. The Feasibility of the Intelligent Building Consept in Office Buildings. 2003. 497 p. Requirements engineering 493 Rantamäki, Karin. Particle-in-Cell Simulations of the Near-Field of a Lower Hybrid Grill. 2003. 74 p. + app. 61 p. 494 Heiniö, Raija-Liisa. Influence of processing on the flavour formation of oat and rye. 2003. Inventory of technologies 72 p. + app. 48 p. 495 Räsänen, Erkki. Modelling ion exchange and flow in pulp suspensions. 2003. 62 p. + app. 110 p. 496 Nuutinen, Maaria, Reiman, Teemu & Oedewald, Pia. Osaamisen hallinta ydinvoima- laitoksessa operaattoreiden sukupolvenvaihdostilanteessa. 2003. 82 s. 497 Kolari, Sirpa. Ilmanvaihtojärjestelmien puhdistuksen vaikutus toimistorakennusten sisäilman laatuun ja työntekijöiden työoloihin. 2003. 62 s. + liitt. 43 s. 498 Tammi, Kari. Active vibration control of rotor in desktop test environment. 2003. 82 p. 499 Kololuoma, Terho. Preparation of multifunctional coating materials and their applications. 62 p. + app. 33 p. 500 Karppinen, Sirpa. Dietary fibre components of rye bran and their fermentation in vitro. 96 p. + app. 52 p. 501 Marjamäki, Heikki. Siirtymäperusteisen elementtimenetelmäohjelmiston suunnittelu ja ohjel- mointi. 2003. 102 s. + liitt. 2 s. 502 Bäckström, Mika. Multiaxial fatigue life assessment of welds based on nominal and hot spot stresses. 2003. 97 p. + app. 9 p. 503 Hostikka, Simo, Keski-Rahkonen, Olavi & Korhonen, Timo. Probabilistic Fire Simulator. Theory and User's Manual for Version 1.2. 2003. 72 p. + app. 1 p. 504 Torkkeli, Altti. Droplet microfluidics on a planar surface. 2003. 194 p. + app. 19 p. 505 Valkonen, Mari. Functional studies of the secretory pathway of filamentous fungi. The effect of unfolded protein response on protein production. 2003. 114 p. + app. 68 p. 508 Parviainen, Päivi, Hulkko, Hanna, Kääriäinen, Jukka, Takalo, Juha & Tihinen, Maarit. Re- quirements engineering. Inventory of technologies. 2003. 107 p. 509 Sallinen, Mikko. Modelling and estimation of spatial relationships in sensor-based robot workcells. 2003. 218 p. Tätä julkaisua myy Denna publikation säljs av This publication is available from VTT TIETOPALVELU VTT INFORMATIONSTJÄNST VTT INFORMATION SERVICE PL 2000 PB 2000 P.O.Box 2000 02044 VTT 02044 VTT FIN–02044 VTT, Finland Puh. (09) 456 4404 Tel. (09) 456 4404 Phone internat. +358 9 456 4404 Faksi (09) 456 4374 Fax (09) 456 4374 Fax +358 9 456 4374 ISBN 951–38–6245–3 (soft back ed.) ISBN 951–38–6246–1 (URL: http://www.vtt.fi/inf/pdf/) ISSN 1235–0621 (soft back ed.) ISSN 1455–0849 (URL: http://www.vtt.fi/inf/pdf/) VTT PUBLICATIONS 508 Requirements engineering Inventory of technologies Päivi Parviainen, Hanna Hulkko, Jukka Kääriäinen, Juha Takalo & Maarit Tihinen VTT Electronics ISBN 951–38–6245–3 (soft back ed.) ISSN 1235–0621 (soft back ed.) ISBN 951–38–6246–1 (URL: http://www.vtt.fi/inf/pdf/) ISSN 1455–0849 (URL: http://www.vtt.fi/inf/pdf/) Copyright © VTT Technical Research Centre of Finland 2003 JULKAISIJA – UTGIVARE – PUBLISHER VTT, Vuorimiehentie 5, PL 2000, 02044 VTT puh. vaihde (09) 4561, faksi (09) 456 4374 VTT, Bergsmansvägen 5, PB 2000, 02044 VTT tel. växel (09) 4561, fax (09) 456 4374 VTT Technical Research Centre of Finland, Vuorimiehentie 5, P.O.Box 2000, FIN–02044 VTT, Finland phone internat. + 358 9 4561, fax + 358 9 456 4374 VTT Elektroniikka, Kaitoväylä 1, PL 1100, 90571 OULU puh. vaihde (08) 551 2111, faksi (08) 551 2320 VTT Elektronik, Kaitoväylä 1, PB 1100, 90571 ULEÅBORG tel. växel (08) 551 2111, fax (08) 551 2320 VTT Electronics, Kaitoväylä 1, P.O.Box 1100, FIN–90571 OULU, Finland phone internat. + 358 8 551 2111, fax + 358 8 551 2320 Technical editing Marja Kettunen Otamedia Oy, Espoo 2003 Parviainen, Päivi, Hulkko, Hanna, Kääriäinen, Jukka, Takalo, Juha & Tihinen, Maarit. Requirements engineering. Inventory of technologies. Espoo 2003. VTT Publications 508. 106 p. Keywords Requirements engineering (RE), RE methods, RE techniques, RE tools, system and software engineering Abstract The purpose of this publication is to describe existing systems and software requirements engineering techniques, methods and tools based on a literature study. This publication covers a wide range of requirements engineering methods and theoretical issues and thus provides a broad view of the field. Also, some RE tools are described. Requirements engineering is also described in general and RE processes introduced to provide background information about RE and help to understand the method descriptions. The main processes of RE as seen in this publication include: System requirements development, requirements allocation and flow- down, software requirements analysis and specification and continuous processes including requirements documentation, requirements validation and verification and requirements change management. Requirements Management (RM) activities are understood to begin before actual requirements engineering process phases (RM planning) and continuing during design, implementation, testing and maintenance phases. 3 Preface This publication has been drawn up during MOOSE (Software engineering methodologies for embedded systems), which is an ITEA project (no 01002). The project's main goal is to seamlessly integrate the different areas of product and software development into a common framework. The purpose of the literature study is to provide a comprehensive review of the current state of requirements engineering. As this publication is an inventory of existing requirements engineering methods, techniques and tools and contains the requirements engineering process definition, it serves as the basis for further research performed within the MOOSE project. More information about MOOSE project together with its goals and publications can be found from the project's web site, http://www.mooseproject.org. 4 Contents Abstract................................................................................................................. 3 Preface .................................................................................................................. 4 List of terminology ............................................................................................... 6 1. Introduction................................................................................................... 11 2. Requirements engineering processes............................................................ 12 2.1 System requirements development...................................................... 16 2.2 Requirements allocation and flow-down............................................. 22 2.3 Software requirements analysis and specification............................... 29 2.4 Continuous activities in RE................................................................. 34 2.4.1 Requirements documentation.................................................. 34 2.4.2 Requirements validation and verification ............................... 36 2.4.3 Requirements change management......................................... 37 2.5 Requirements management viewpoint................................................. 37 3. Requirements engineering methods.............................................................. 47 3.1 General methods.................................................................................. 48 3.2 System Requirements development..................................................... 52 3.3 Requirements allocation and flow-down............................................. 59 3.4 Software requirements analysis and specification............................... 61 3.5 Continuous activities ........................................................................... 72 3.6 Requirements management.................................................................. 78 3.6.1 Requirements identification .................................................... 78 3.6.2 Requirements traceability........................................................ 79 3.6.3 Requirements traceability models, methods and languages.... 80 3.6.4 Requirements change control.................................................. 87 4. Requirements engineering tools.................................................................... 93 4.1 Introduction ......................................................................................... 93 4.2 Basic RM tool features ........................................................................ 94 4.3 Examples of RE tools .......................................................................... 95 5. Summary....................................................................................................... 96 Acknowledgements............................................................................................. 97 References........................................................................................................... 98 5 List of terminology The terminology of this publication is presented in the following. Allocation The process of distributing requirements, resources, or other entities among
Load more

Recommended publications
  • A System Model for Managing Requirement Traceability Matrices Via Statistical Artifact Change Analysis Benjamin J
    A System Model for Managing Requirement Traceability Matrices via Statistical Artifact Change Analysis Benjamin J. Deaver and LiGuo Huang, Southern Methodist University, Dallas Introduction and Motivation Requirement Traceability Matrix – Gantt Open Source Software Project The Value of the Requirements Traceability Matrix The system Requirement Traceability Matrix (RTM) is primarily used for ensuring Our initial dataset for evaluation is taken from the Gantt Open Source PROCEDURE Kannenberg et al identify the underlying necessity of the Requirements Traceability Matrix and the underlying effect on that all requirements are fulfilled by the system artifact deliverables and the Software Project (http://www.ganttproject.biz). The initial trace data 1. Identify the taxonomy of change for a given domain (Systems Engineering, project management, process visibility, verification and validation, as well as project maintainability. Over time, the management of change to deliverables with respect to impact on other systems. In has been provided to us by Dr. Alexander Egyed at the Institute for SoS Engineering, Software Engineering). the systems engineering and system of systems (SoS) engineering landscapes, the Systems Engineering and Automation at Johannes Kepler University. Requirements Traceability Matrix provides significant insight in to the internal workings of the relationships between RTM is a tool that is useful at time of creation, but requires constant maintenance in Additional traces of requirements to code for subsequent Gantt versions 2. Identify and classify changes between static versions of the product. requirements and deliverable artifacts. a frequently changing landscape to maintain the original level of validity. The are being created using similar methods to the original collections 3. Generate Requirements Trace Matrixes for each static version of the product dynamic nature of systems and SoS engineering landscapes requires that a RTM be performed by Dr.
    [Show full text]
  • Innovations in Natural Language Document Processing for Requirements Engineering
    Calhoun: The NPS Institutional Archive Faculty and Researcher Publications Faculty and Researcher Publications 2008 Innovations in Natural Language Document Processing for Requirements Engineering Berzins, Valdis þÿB. Paech and C. Martell (Eds.): Monterey Workshop 2007, LNCS 5320, pp. 125 146, 2008. http://hdl.handle.net/10945/46073 Innovations in Natural Language Document Processing for Requirements Engineering Valdis Berzins, Craig Martell, Luqi, and Paige Adams Naval Postgraduate School, 1411 Cunningham Road, Monterey, California 93943 {berzins,cmartell,luqi,phadams}@nps.edu Abstract. This paper evaluates the potential contributions of natural language processing to requirements engineering. We present a selective history of the relationship between requirements engineering (RE) and natural-language processing (NLP), and briefly summarize relevant re- cent trends in NLP. The paper outlines basic issues in RE and how they relate to interactions between a NLP front end and system-development processes. We suggest some improvements to NLP that may be possible in the context of RE and conclude with an assessment of what should be done to improve likelihood of practical impact in this direction. Keywords: Requirements, Natural Language, Ambiguity, Gaps, Domain- Specific Methods. 1 Introduction A major challenge in requirements engineering is dealing with changes, especially in the context of systems of systems with correspondingly complex stakeholder communities and critical systems with stringent dependability requirements. Documentation driven development (DDD) is a recently developed approach for addressing these issues that seeks to simultaneously improve agility and de- pendability via computer assistance centered on a variety of documents [1,2]. The approach is based on a new view of documents as computationally active knowledge bases that support computer aid for many software engineering tasks from requirements engineering to system evolution, which is quite different from the traditional view of documents as passive pieces of paper.
    [Show full text]
  • Managing Requirements Engineering Risks: an Analysis and Synthesis of the Literature
    Lars Mathiassen – Timo Saarinen – Tuure Tuunanen – Matti Rossi MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE W-379 HELSINKI SCHOOL OF ECONOMICS ISSN 1795-1828 WORKING PAPERS ISBN 951-791-895-X (Electronic working paper) W-379 2004 Lars Mathiassen* – Timo Saarinen** – Tuure Tuunanen** – Matti Rossi** MANAGING REQUIREMENTS ENGINEERING RISKS: AN ANALYSIS AND SYNTHESIS OF THE LITERATURE *Center for Process Innovation, Georgia State University **Helsinki School Economics, Department of Management, Information Systems Science November 2004 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS WORKING PAPERS W-379 HELSINGIN KAUPPAKORKEAKOULU HELSINKI SCHOOL OF ECONOMICS PL 1210 FIN-00101 HELSINKI FINLAND © Lars Mathiassen, Timo Saarinen, Tuure Tuunanen, Matti Rossi and Helsinki School of Economics ISSN 1795-1828 ISBN 951-791-895-X (Electronic working paper) Helsinki School of Economics - HeSE print 2004 Managing Requirements Engineering Risks: An Analysis and Synthesis of the Literature Lars Mathiassen ([email protected]) Center for Process Innovation, Georgia State University P. O. Box 4015, Atlanta, GA 30303-4015, USA Phone: +1-404-651-0933, Fax: +1-404-463-9292 Timo Saarinen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-9-431-38272, Fax: Fax: +358-9-431-38700 Tuure Tuunanen ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P. O. Box 1210, FIN-00101 Helsinki, Finland Phone: +358-40-544-5591, Fax: +358-9-431-38700 http://www.tuunanen.fi Matti Rossi ([email protected]) Helsinki School Economics, Department of Management, Information Systems Science P.
    [Show full text]
  • Requirements Traceability Practices Guide
    CDC UNIFIED PROCESS PRACTICE GUIDE REQUIREMENTS TRACEABILITY Document Purpose The purpose of this document is to provide guidance on the project management practice of Requirements Traceability and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements. In addition, templates relevant to this practice are provided at the end of this guide. Practice Overview Requirements traceability is an activity that is one part of an overarching requirements management practice and extends from requirements definition through to implementation. Requirements tracing is used to ensure that each step of the product’s development process is correct, conforms to the needs of prior and next steps, and conforms to the defined requirements. Requirements tracing is a technique that helps to ensure that the project delivers what stakeholders expect. If applied correctly requirements tracing is a practice that can greatly increase the quality and reliability of a project’s final product while minimizing costly rework resulting from requirements errors. Requirements tracing defines the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through each step of the entire product’s life cycle. This is done by documenting and tracking traceability relationships between requirements. A traceability relationship is a dependency relationship between project and/or product elements. Similar to the way a dynamic project schedule may react to a change in one task, a change to a requirement element may also have a rippling effect on other elements. A well documented traceability relationship clearly defines requirement dependencies and allows for analysis of how changes in requirements affect other requirements and the project as a whole.
    [Show full text]
  • Requirements Management Applied in an Agile Project Management Environment
    Requirements Management applied in an agile Project Management environment Franco (Frank) Curtolo CEng, Principal Consultant, Program Planning Professionals Ltd, [email protected] Categorisation • Accessibility: PRACTITIONER • Application: GOOD PRACTICE • Topics: Agile Systems Engineering; Project Management Abstract This paper looks at how the Requirements Management process of Systems Engineering may benefit from some of the aspects derived from developing systems within an agile Project Management environment, using as example, the Scaled Agile Framework® of © Scaled Agile, Inc. The aim is to see if some of these agile techniques can enhance the Systems Engineering approach. Systems Engineering (SE) is well suited to develop large, complex products in a project environment where the requirements can be defined and fixed upfront. In fact, SE relies on an initial, well-defined End User’s need specified in for example, a User Requirements Specification (URS), to establish an initial requirements baseline which is used to drive the rest of the development process. However not all development projects happen that way. Sometimes the End User’s need is not clear, or cannot be well defined upfront, thus not allowing it to be captured in a fixed requirements baseline. Furthermore, the project environment may need to accommodate rapid change, both in the End Users’ need and in the technologies available to satisfy this need. In such a project environment, an agile development approach, as described in the Scaled Agile Framework® (SAFe®), may be more suitable since it allows for incremental delivery of the product and change to requirements. This can accommodate undefined End User needs, rapid change in requirements and allow for the introduction of innovation during the development and implementation stages.
    [Show full text]
  • Non-Functional Requirements
    ® IBM Software Group Non-Functional Requirements Peter Eeles [email protected] IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Definitions Functional Requirement Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities. [Malan] Non-Functional Requirement Non-functional requirements include constraints and qualities. [Malan] [System] qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. [Malan] A constraint is a restriction on the degree of freedom we have in providing a solution. [Leffingwell] [Leffingwell] Managing Software Requirements – a Unified Approach, Dean Leffingwell and Don Widrig. [Malan] Defining Non-Functional Requirements, Ruth Malan and Dana Bredemeyer. IBM Software Group | Rational software Agenda Definitions Types of requirement Classifying requirements Capturing NFRs Summary IBM Software Group | Rational software Types of Requirement Use Cases Defines the behavior of the system from an external perspective System-Wide Requirements Legal and regulatory requirements, application standards, qualities that the system exhibits (such as usability, reliability, scalability, performance), operating system and environment requirements, compatibility requirements, and other design and implementation constraints Change
    [Show full text]
  • Requirements Engineering Objectives
    Requirements Engineering Chapter 2 Requirements Engineering Processes Learning Objective ...to give a general introduction to the requirements engineering process. Different approaches to modeling requirements engineering processes are suggested and why human, social and organizational factors are important influences on those processes. Other concepts that are evaluated include process maturity, tools and process improvement. Frederick T Sheldon Assistant Professor of Computer Science University of Colorado at Colorado Springs CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Objectives ⊗ To introduce the notion of processes and process models for requirements engineering ⊗ To explain the critical role of people in requirements engineering processes ⊗ To explain why process improvements is important and to suggest a process improvement model for requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 2 Processes ⊗ A process is an organized set of activities which transforms inputs to outputs ⊗ Process descriptions encapsulate knowledge and allow it to be reused ⊗ Examples of process descriptions • Instruction manual for a dishwasher • Cookery book • Procedures manual for a bank • Quality manual for software development CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 3 Design processes ⊗ Processes which involve creativity, interactions between a wide range of different people, engineering judgement and background knowledge and experience ⊗ Examples of design processes • Writing a book • Organizing a conference • Designing a processor chip • Requirements engineering CS 531 Software Requirements Analysis and Specification Chapter 2 From Requirements Engineering Processes and Techniques by G.
    [Show full text]
  • Elicitation of Quality Agile User Stories Using QFD
    Elicitation of Quality Agile User Stories Using QFD NDIA 20th Annual Systems Engineering Conference “Agile in Systems Engineering“ 10:15 – 10:40 AM October 25, 2017 Sabrina J. Ussery, Shahryar Sarkani, Thomas Holzer Dissertation Topic Department of Engineering Management and Systems Engineering School of Engineering and Applied Science The George Washington University 1176 G Street NW Washington, DC 20052 1 Agile Requirements Engineering (RE) The lack of standard Requirements Engineering (RE) practices in Agile negatively impacts system quality, contributing to 24% of the causes for challenged or failed projects. • The 2015 CHAOS Standish Group report indicates Agile projects are 3x more likely to succeed than Waterfall projects due to increased customer collaboration and customer satisfaction. [2] • The Agile community claims that they do not really tackle requirements in a structured way, which may bring problems to the software organization responsible for software built following an Agile method. [1] • Though more successful in some respects, the Image source: [2] lack of stand RE practices in Agile contributes to 24% of the reasons for challenged or failed projects due to poor requirements quality (i.e., unclear or volatile). [2] 2 What is Agile? 3 Agile RE: As Is Requirements Requirements engineering (RE) refers to the process of defining, documenting and maintainingEngineering requirements. [5] Requirements Requirements Development Management Elicitation Priorities Specification Traceability Analysis Specifications Validation Configuration
    [Show full text]
  • Integrated Requirements Engineering: a Tutorial
    focusrequirements engineering1 Integrated Requirements Engineering: A Tutorial Ian Sommerville, Lancaster University efore developing any system, you must understand what the sys- tem is supposed to do and how its use can support the goals of the individuals or business that will pay for that system. This in- B volves understanding the application domain (telecommunica- tions, railways, retail banking, games, and so on); the system’s operational constraints; the specific functionality required by the stakeholders (the peo- ple who directly or indirectly use the system or the information it provides); and essential system characteristics such as The fundamental process performance, security, and dependability. Re- The RE process varies immensely depend- quirements engineering is the name given to a ing on the type of application being devel- structured set of activities that help develop oped, the size and culture of the companies in- this understanding and that document the sys- volved, and the software acquisition processes tem specification for the stakeholders and en- used. For large military and aerospace sys- gineers involved in the system development. tems, there is normally a formal RE stage in This short tutorial introduces the funda- the systems engineering processes and an ex- mental activities of RE and discusses how it tensively documented set of system and soft- has evolved as part of the software engineering ware requirements. For small companies de- process. However, rather than focus on estab- veloping innovative software products, the RE lished RE techniques, I discuss how the chang- process might consist of brainstorming ses- ing nature of software engineering has led to sions, and the product “requirements” might new challenges for RE.
    [Show full text]
  • A Requirements Modeling Language for the Component Behavior of Cyber Physical Robotics Systems
    A Requirements Modeling Language for the Component Behavior of Cyber Physical Robotics Systems Jan Oliver Ringert, Bernhard Rumpe, and Andreas Wortmann RWTH Aachen University, Software Engineering, Aachen, Germany {ringert,rumpe,wortmann}@se-rwth.de Abstract. Software development for robotics applications is a sophisticated en- deavor as robots are inherently complex. Explicit modeling of the architecture and behavior of robotics application yields many advantages to cope with this complexity by identifying and separating logically and physically independent components and by hierarchically structuring the system under development. On top of component and connector models we propose modeling the requirements on the behavior of robotics software components using I/O! automata [29]. This approach facilitates early simulation of requirements model, allows to subject these to formal analysis and to generate the software from them. In this paper, we introduce an extension of the architecture description language MontiArc to model the requirements on components with I/O! automata, which are defined in the spirit of Martin Glinz’ Statecharts for requirements modeling [10]. We fur- thermore present a case study based on a robotics application generated for the Lego NXT robotic platform. “In der Robotik dachte man vor 30 Jahren, dass man heute alles perfekt beherrschen würde”, Martin Glinz [38] 1 Introduction Robotics is a field of Cyber-Physical Systems (CPS) which yields complex challenges due to the variety of robots, their forms of use and the overwhelming complexity of the possible environments they have to operate in. Software development for robotics ap- plications is still at least as complex as it was 30 years ago: even a simple robot requires the integration of multiple distributed software components.
    [Show full text]
  • Collecting and Analyzing Requirements Related Software Project Queries
    Collecting and Analyzing Requirements Related Software Project Queries Sugandha Malviya*, Jane Cleland-Huang**, and Alexander Rasin* *DePaul University, College of Computing and Digital Media, Chicago, IL **University of Notre Dame, South Bend, Indiana [email protected], [email protected], [email protected] Abstract Project data is often underutilized due to lack of accessibility and difficulties users have in constructing the non-trivial SQL queries that are often needed to support realistic Software Engineering questions. In our prior work we therefore presented TiQi – a natural language interface which allows users to issue trace queries in their own words. We initially collected sample queries from a limited number of industrial stakeholders, and utilized these to evaluate our proof of concept solution. As the work has matured, we have collected and analyzed a far more extensive set of trace queries from which we derive additional requirements for TiQi and construct a more challenging evaluation context. This paper not only describes the collected queries and their derived requirements, but discusses the need for iteratively building realistic benchmarks when engaging in research design projects. 1 TiQi: A Quick Overview All software and systems engineering projects accumulate large amounts of artifacts in the form of requirements, design artifacts, code, test cases, project scheduling, fault logs, and other such data. This collection of data represents a valuable resource for managing various aspects of a software project; however, in practice it is often underutilized primarily because of the difficulties in accessing and retrieving it from heterogeneous data stores and then using it to formulate useful queries. To alleviate this problem, we have developed a natural language query interface, named TiQi for use in Software Engineering projects [1, 2].
    [Show full text]
  • Tool Demo) Benoît Ries, Alfredo Capozucca and Nicolas Guelfi University of Luxembourg, Esch-Sur-Alzette, Luxembourg
    Messir: A Text-First DSL-Based Approach for UML Requirements Engineering (Tool Demo) Benoît Ries, Alfredo Capozucca and Nicolas Guelfi University of Luxembourg, Esch-sur-Alzette, Luxembourg Context 2. Messir Textual DSLs Students Feedback Our students surveys on the lectures using Due to the need for (and absence of) Messir/Excalibur resulted, out of 90+ answers, an integrated requirements engineering tool Messir Constraint Messir Validation Rules in a majority of students agreeing both on centered on a textual specification language, Language Documentation "recommending the lectures to others", and providing rich coverage of UML, report • A number of syntactical Language that "the learning resources met their needs". generation, and formal simulation to be used validation rules are generated • declarative specification of Positive comments were "the integrated hands-on by our students at University of Luxembourg, automatically by the XText operations • complementary textual approach" and "the report generation". Negative in our software engineering project-based framework based on the • syntax inspired from OCL language comments were mostly about "the actual presence lectures, we have started to develop the Messir DSL grammar. • semantics defined as a manual • natural language descriptions of bugs in the tool". Excalibur workbench and Messir DSLs. • We have implemented 50 translation to prolog used during report generation additional runtime validation • covered concepts include: • allow documenting Messir Conclusion rules used as educational
    [Show full text]