Reducing structural ambiguity in natural language software requirements specifications

Abstract. The ambiguity of natural language (NL) causes miscommunication and misunderstandings. Precision of language is particularly important in software development when handling requirements agreed between the customer and the provider. Software Requirements Specification (SRS) is a commonly used document type for specifying the requirements. A strict standard for how every SRS should be constructed does not exist, and thus it is often written in NL. However, some restricted languages can be used for specifying requirements. An example of such is Easy Approach to Requirements Syntax (EARS). In this thesis is presented an automated tool for reducing the structural ambiguity of requirements by converting NL into EARS form. Four different text datasets were used for testing the converter and they were compared before and after conversion and against each other. Both performance and ambiguity reduction of the tool were assessed using various measures. Since a standard ambiguity measurement was not available, a combination of sentence structure assessment, word occurrences against Zipf’s law, readability score and information complexity was used. The results suggest that the tool reduces structural ambiguity of sentences. The tool is successful in converting NL into the different EARS patterns and the converted sentences are less complicated and more readable, according to the results. This hints at the possibility of creating more automated tools that could be used to reduce ambiguity in NL SRS. It might not be possible to make people start using a restricted language, like EARS, for writing the documents, but with the help of automated converters, sentences could be mapped to more restricted forms to help with making better sense of them.Luonnollisen kielen rakenteellisen moniselitteisyyden vähentäminen ohjelmistojen vaatimusten määrittelyissä. Tiivistelmä. Luonnollisen kielen epämääräisyys aiheuttaa vaikeuksia kommunikoinnissa ja ymmärtämisessä. Kielen tarkkuus on erityisen tärkeää ohjelmistokehityksessä silloin kun käsitellään asiakkaan ja tarjoajan keskenään sopimia vaatimuksia ohjelmistolle. Ei ole olemassa tiukkaa standardia sille miten vaatimusten määrittelydokumentti pitäisi rakentaa, joten se usein kirjoitetaan luonnollisella kielellä. Siitä huolimatta joitain rajoitettuja kieliä voidaan käyttää yksittäisten vaatimusten määrittelyyn. Eräs esimerkki rajoitetusta kielestä on Easy Approach to Requirements Syntax (EARS). Tässä diplomityössä esitellään automatisoitu työkalu vähentämään rakenteista epämääräisyttä muuttamalla luonnollista kieltä EARS-muotoon. Neljää erilaista tekstiä käytettiin työkalun testaamiseen ja niitä verrattiin toisiinsa sekä ennen että jälkeen muuntamisen. Työkalun toimintaa ja epämääräisyyden vähentämistä mitattiin useilla metriikoilla. Epämääräisyyden mittaamiseen valittiin joukko kvantitatiivisia metriikoita: lauserakenteita analysoitiin, sanojen ilmiintyvyystiheyttä ja lausiden luettavuutta mitattiin ja informaation kompleksisuuttakin verrattiin muunnettujen ja muuntamattomien tekstien välillä. Tulosten perusteella esitelty työkalu vähentää lauseiden rakenteellista epämääräisyyttä. Se muuntaa onnistuneesti luonnollista kieltä EARS-muotoon ja tulosten mukaan muunnetut lauseet ovat vähemmän monimutkaisia ja luettavampia. Tämä viittaa siihen, että automatisoiduilla työkaluilla voisi olla mahdollista vähentää epämääräisyyttä luonnollisella kielellä kirjoitetuissa vaatimusten määrittelydokumenteissa. Vaikkei ihmisiä saataisikaan kirjoittamaan vaatimusten määrittelyjä rajoitetuilla kielillä, automatisoiduilla kielen muuntajilla lauseita voidaan uudelleenmuotoilla rajoitetumpiin muotoihin, jotta niistä saataisiin paremmin selvää

Formal Requirements Elicitation with FRET

FRET is a tool for writing, understanding, formalizing and analyzing requirements. Users write requirements in an intuitive, restricted natural language, called FRETISH, with precise, unambiguous meaning. For a FRETISH requirement, FRET: 1) produces natural language and diagrammatic explanations of its exact meaning, 2) formalizes the requirement in logics, and 3) supports interactive simulation of produced logic formulas to ensure that they capture user intentions. FRET connects to analysis tools by facilitating the mapping between requirements and models/code, and by generating verification code. FRET is available open source at https://github.com/NASA-SW-VnV/fret; a video can be accessed at : https://tinyurl.com/fretForREFSQ

A human factors approach to defining requirements for low-speed autonomous vehicles to enable intelligent platooning

This paper presents results from a series of focus groups, aimed at enhancing technical engineering system requirements, for a public transport system, encompassing a fleet of platooning low-speed autonomous vehicles (LSAV; aka pods) in urban areas. A critical review of the pods was conducted, as part of a series of technical workshops, to examine the key areas of the system that could affect users and other stakeholders, such as businesses and the public. These initial findings were used to inform a series of focus groups, aimed at identifying the public's views of multiple autonomous vehicles being deployed in a pedestrianised area that can join and form platoons. Analysis of findings from the focus groups suggests that while people view platooning public transport vehicles favourably as a passenger, they have some concerns from a pedestrian perspective. Thematic analysis was applied to these findings and a systematic approach was used to identify where subjective outputs could be formalised to inform requirements. Finally, a step-by-step requirements elicitation process is presented that illustrates the method used to convert qualitative user data to objective engineering requirements

法令から機能要求を半自動的に抽出する手法の提案

行政機関における各種業務システムは，法令に基づいた業務を処理することから，法令の内容をシステムに反映させる必要がある．一方，新規に成立が予定されている法案や大幅な法改正が行われる場合，行政機関は法令の施行に間に合うように短期間で業務システムの開発・改修に関する仕様書を作成し，ベンダーに発注する必要がある．また，その際には後工程での手戻りを防止するため，機能要求を正しく網羅的に抽出する必要がある．一方で，法令の規定は自然言語で記述され，関連する規定が膨大なことから，システムに求められる機能を正確にかつ網羅的に短期間で抽出することは困難である．法令からの要求獲得においてはオントロジー[1]や述語論理[2]を用いた手法が提案されているが，オントロジー構築や述語論理式への変換等，法改正が頻繁に生じる法令においては維持コストが必要である上に，仕様書の作成を行う行政機関の担当者がそれらの手法に習熟しているケースは少ないなど，実用面での課題がある．そのため，本研究では，法令に基づく業務システムに必要な機能要求を正確にかつ網羅的に短期間で抽出することを目的として，その機能要求を半自動的に抽出する手法を提案する．具体的には，機能要求を表現する記述を予め定義したテンプレートを用いた機能要求の抽出手法を構築し，その抽出を支援するため，主に次の2つの機能を持つ支援ツールを実装した：(1) 複雑で長文となりがちな条文をシンプルに記述するため，形態素解析した条文からアクターとユースケースに着目し条文を自動的に要約する機能，(2) 手作業で構築した辞書に基づき機能要求を含む条文を示唆する機能．また，要求抽出実験を通じて提案手法の有用性に関する評価を行い，その結果，本手法を用いることで要求工学や法令に関する専門知識が無い者でも高い精度で法令の規定から機能要求を抽出できることが確認できた．電気通信大学201

Requirements Engineering

Requirements Engineering (RE) aims to ensure that systems meet the needs of their stakeholders including users, sponsors, and customers. Often consid- ered as one of the earliest activities in software engineering, it has developed into a set of activities that touch almost every step of the software development process. In this chapter, we reflect on how the need for RE was first recognised and how its foundational concepts were developed. We present the seminal papers on four main activities of the RE process, namely (i) elicitation, (ii) modelling & analysis, (iii) as- surance, and (iv) management & evolution. We also discuss some current research challenges in the area, including security requirements engineering as well as RE for mobile and ubiquitous computing. Finally, we identify some open challenges and research gaps that require further exploration

Requirements-based Simulation Execution for Virtual Validation of Autonomous Systems

The complexity of software is rapidly increasing in many domains. Therefore, simulations have become established as a testing tool in recent years. Especially the virtual validation of autonomous systems leads to increasingly complex simulation environments. Nevertheless, the scenarios and the simulation results are not linked to the requirements. To close this gap, we develop a lightweight approach that allows the user to extract functional information. Simulation results can then be presented in different levels of detail in the original requirements. This replaces difficult translations of requirements and allows permanent comparison at all test levels

Requirements for Point of Care Devices using Use Case Maps

Point of Care (PoC) testing (diagnosis) is a method for bringing medical laboratories to a patient’s home to conduct diagnostic tests so that the patient does not need to go to the doctor or laboratory in person. PoC testing reduces the burden on expensive laboratory setups and provides management of patient care in cost effective manner. The design and development of the PoC device and the associated infrastructure must be done with extreme rigor, as the PoC system meets the definition of a mission critical or safety critical system. Requirements creation and management are the key processes for ensuring that a highly reliable and low defect PoC system is developed since accurate PoC testing-based diagnosis is an essential process improvement for remote patient care management. It is important that the requirements be specified accurately, completely and without any ambiguity so that the PoC device can be designed and developed with minimal errors. This provides physicians a vehicle to diagnose patients with drastically increased reliability. This paper explains how Use Case Maps (UCM), a modeling technique, can help to sufficiently model requirement specifications for a PoC system development. It illustrates PoC functional requirements and security requirements in terms of the UCM representation. DOI: 10.17762/ijritcc2321-8169.150616

Non-functional requirement template for usability aspect based on NIMSAD evaluation engineering

In requirement engineering, non-functional requirement is a requirement that specifies characteristics of system behavior and sys-tem quality attributes. Furthermore, a non-functional requirement template facilitates system stakeholders in better system documentation, system elicitation and system traceability. However, some non-functional requirements may come from many type of requirements document and no stringent standard has been applied that lead to various pattern of non-functional requirements tem-plate. Specifically, in usability requirement, the quality attribute is being ignored and less expressive in majority requirements document. Therefore, this study was motivated to propose the most feasible non-functional requirement template for usability aspect. NIMSAD evaluation is used to obtain the most feasible non-functional requirement template by comparing existing non-functional requirement templates based on the following criteria which are i) general concepts, ii) modeling concepts and iii) analysis concepts. From the NIMSAD evaluation results, it is found that Boilerplates template is the most feasible non-functional requirement tem-plate for usability aspect