Ontology Based Requirements Analysis: Lightweight Semantic Processing Approach

Software requirements analysis is crucial for any software project and it is the basis of requirements reuse within Software Product Line engineering. Software requirements specifications are usually expressed in natural language, which are informal, imprecise and ambiguous, thus analyzing them automatically is a challenging task. Although methods towards automatic analysis of software requirements have been studied before, many of them have limitations and effective researches in this area are still lacking. Therefore, in this paper a new approach was proposed to automatically extract structured information of functional requirements from Software Requirements Specifications in natural language. The methods of machine learning, natural language processing and semantic analysis were employed and combined in this approach. With a 10-fold cross validation setting, the method was evaluated on a manually annotated corpus. The experiments show that this approach achieves a good performance. Moreover, it was found that the model trained on the requirements dataset of the E-commerce systems, can be used to extract semantic information from the requirements of auto-maker systems. The cross-domain extraction results show that the method of this paper is domain independent and robust to some extent.

An Ameliorated Methodology for the Abstraction of Object Oriented Features from Software Requirements Specification

A software process improvement programme is under way at a Spanish financial institution. A structured methodology, supported by formal and informal techniques and tools, is being established by a methodological support group, as a starting point for the improvement. This paper centres particularly on the methodological and automated management of software requirements analysis. This process was previously performed in a not formal manner, and the most direct consequence was the high costs in maintenance. The methodology developed includes actions to obtain, refine and validate the software requirements. It also includes an organisational Software Requirements Specification (SRS) standard, implemented on a commercial tool which was selected as a result of a formal evaluation process. Additionally, a procedure was defined for working with the SRS and the tool. The results of this practical experience show an improvement in SRS quality, and work is no longer duplicated, since more correct and complete specifications are obtained.

The paper proposes an approach to extracting ontology concepts from the results of automatic processing the software requirements written in natural Russian-language. Relevance of developing an approach to automating the process of extraction of the ontology concepts from the requirements written in natural language is due to the necessity to maintain the requirements specification in a consistent state under conditions of business environment variability. First we discuss the advantages of the ontology-based approach to the requirements engineering as a stage of the software engineering process. The main attention is focused on the possibilities of presenting knowledge about the software application domain and requirements specification in the form of ontologies. We analyzed possibilities of automatic Russian text processing tools for extracting ontology concepts and consider such tools as ETAP-4, MaltParser and UDPipe. The choice of UDPipe as a tool for automatic processing the requirements texts is explained by the best results that it showed when analyzing texts such as software requirements. Then we describe the main classes, object properties and data properties of the proposed requirements ontology and the application domain ontology. An additional advantage of the proposed approach, increasing its practical utility, is building the system of production rules by which the analysis of the results of the automatic processing of the requirements texts obtained using the UDPipe tool.KeywordsRequirements engineeringOntologyAutomatic text processing

Software development starts by specifying the requirements. A Software Requirements Specification (SRS) describes what the software must do. Naturally, the SRS takes the core role as the descriptive documentation at every phase of the development cycle. To avoid problems in the latter development phases and reduce life-cycle costs, it is crucial to ensure that the specification is correct. This paper describes how to model, test and evaluate (i.e., check, examine, and probe) a natural language (NL) SRS using two formalisms (Z and Statecharts). These formalisms are used to determine strategies for avoiding design defects that stem from the requirements that could ultimately lead to system failures. A case study was performed to validate the integrity of a Guidance Control SRS in terms of completeness, consistency, and fault-tolerance. Based on these experiences, the NL-specification→Z→Statechart transformations can be completed in a systematic and repeatable manner that yield valuable insight into the overall integrity of software specifications.

This paper focuses on requirements to design traceability. There have been many advances in requirements traceability and various tools are available to perform requirements traceability. Software Requirements to Design Traceability Technique named SoRDeTT, is the methodology proposed, which is based on templates. Software Requirements Specification (SRS) and Software Design Document (SDD) form inputs to this methodology. SoRDeTT has defined a common template (for requirement and design) to capture data and information from these documents. The template with data populated from SRS is called SRS Trace Item (SRSTI), and the one filled with data from SDD is called SDD Trace Item (SDDTI). The template defined needs to be filled for every software requirement. Initialization, input, output, data type, range, resolution of data etc. are the fields which are part of the template. The filled templates namely SRSTI and SDDTI corresponding to all software requirements are used to carry out traceability analysis. Since the template is same for requirements and design data, hence it is easy to compare and raise alerts for appropriate action to be taken.

Requirements Engineering is the set of activities involved in creation, managing, documenting, and maintaining a requirements’ set for a product. Engineering involves the use of systematic repeatability techniques to ensure that the Software Requirements are complete, consistent, valid, and verifiable. Software Requirements Specification is an organized process oriented toward defining, documenting and maintaining requirements throughout the development life cycle. Many authors suggest that requirements should always focus their claims on what the software product needs to address, without specifying how to implement them. However, the detail of Software Requirements is influenced by several factors such as: organizational thinking; existing specification standards; and regulatory needs. This work fits exactly with regulatory needs, where the characteristics of Software Requirements Specification in Regulated Environments such as aeronautics, railways and medical are presented and explored. This paper presents and analysis of software requirements specification characteristics in regulated environments. The four characteristics identified are: consistency (internal and external), unambiguity, verifiability, and traceability. The paper also describes the three standards used in these regulated environments (RTCA DO-178C, IEC 62279 and IEC 62304) and examines their similarities and differences from a Requirements Specification standpoint. The similarities and differences will be used to address a future requirements framework universal process that can be configured to address each standard by the usage of Software Process Lines.

Software requirement specification (SRS) documents are written in natural language (NL) and are prone to contain faults due to the inherently ambiguous nature of NL. Inspections are employed to find and fix these faults during the early phases of development, where these are the most cost-effective to fix. Inspections being too manual are very tedious and time consuming to perform. After fixing a fault, the SRS author has to manually re-inspect the document to make sure if there are other similar requirements that need a fix, and also if fixing a fault does not reintroduce another fault in the document (i.e., change impact analysis). The proposed approach in this paper employs NL processing, machine learning, semantic analysis, and graph mining approaches to generate a graph of inter-related requirements (IRR) based on semantic similarity score. The IRR graph is next mined using graph mining approaches to analyze the impact of a change. Our approach when applied using a real SRS generated IRR and yielded promising results. Graph mining approaches resulted in a G-mean of more than 90% to accurately identify the highly similar requirements to support the CIA.

The requirements of a system describe what the user expects from the system – in other words, what the system will do for the user. When defining the requirements of a system, the system should be viewed as a black box, so that only the external characteristics of the system are considered. Both functional and nonfunctional requirements need to be considered. Requirements modeling consists of requirements analysis and requirements specification. Use case modeling is an approach for describing the functional requirements of the system, as described in this chapter. The system's data requirements in terms of the information that needs to be stored by the system are determined using static modeling, as described in Chapter 7. The inputs to the system and the outputs from the system are described initially in the use case models and then specified in more detail during static modeling. This chapter gives an overview of software requirements analysis and specification in Section 6.1. It then goes on to describe the use case approach to defining functional requirements, as well as how to extend use cases to describe nonfunctional requirements. This chapter describes the concepts of actors and use cases , and then goes on to describe use case relationships, in particular, the include and extend relationships. Section 6.2 gives an overview of use case modeling followed by an example of a simple use case. Section 6.3 then describes actors and their role in use case modeling.

Software requirement artifacts such as manuals request for proposals, and software requirements specification (SRS) are commonly focused on functional requirements. In most SRS files, nonfunctional requirements do not formally encoded or encoded as a whole, not for an individual design problem. Moreover, these nonfunctional requirements are intermingled with functional requirements. Therefore, these nonfunctional requirements need special attention to understand for successful project development. These nonfunctional requirements have an impact on each other and optimal tradeoff is required for balanced nonfunctional requirements set. NFRs have a negative and positive tradeoff with each other such as increase confidentiality, decrease the availability, and enhance authenticity. So, an optimum tradeoff among these design problem within a module is required to have better design decisions. Instead of considering all nonfunctional requirements, the NFRs that have mutual tradeoff is considered. In this paper, we devised a novel document annotation scheme for SRS and extracted nonfunctional requirements from these annotated artifacts. In the next step, we classified NFRs into two classes security triad and performance triad, and the cost is assumed constant for each NFR. From the design problem, the tradeoff ratio is calculated among NFRs associated with it. Then, the production possibility graph is plotted to estimate the optimum tradeoff ratio within the module. For estimation economic optimum from a set of NFR, iso-cost graphs by assuming the constant cost. Some hypothetical variations in cost are also examined using 3D iso-cost graph. The reason to measure these tradeoff is to make design decision more empirical and helpful for the selection of design patterns, especially secure design patterns.

The paper argues that quality assurance must begin with quality software requirements specification (SRS) and that by preserving the link between a customer's requirements definition and the SRS, the quality of a software system can be assured beyond first release. Without such a link, it would be difficult to properly analyse the effect of related or inconsistent requirements because the reason for their existence in the final SRS document has been lost, an example of forward and backward tracing requirements through the business and system models developed during analysis and design is given. Areas of further research are then identified.

The aim of this study is the development of the method of generating and filling the template of ontology for the quality of the concrete software and method of forming the logical conclusion about the sufficiency of information of software requirements specification (SRS) for software quality assessment (by ISO 25010:2011). The first time proposed method of generating and filling the template of ontology for the quality of the concrete software leaves in the relevant ontology only measures, which are available in the SRS for the concrete software. It provides forming the ontology for the quality of the concrete software. The first time developed method of forming the logical conclusion about the sufficiency of the SRS information for software quality assessment provides the conclusion about the sufficiency or insufficiency of the SRS information for software quality assessment by ISO 25010:2011. If the SRS information is insufficient, this method: provides the conclusion for which characteristics and sub-characteristics the information is insufficient; creates the sorted list of missing measures as the recommended priority of their addition in the SRS; evaluates the veracity of software quality assessment based on the available in the SRS measures.

Software Requirements Specifications is a document that describes the requirements that occur in the development of a software system. The category of requirements is defined in two types: Functional Requirements (FR) and Non-Functional Requirements (NFR). Software Requirements Engineering is critical in successfully designing a piece of software. Many studies have examined the classification of software requirements using machine learning, but none have compared bagging algorithms with Support Vector Machine (SVM). This study compares text feature extraction techniques with machine learning algorithms Bagging and Support Vector Machine to solve the Software Requirement Classification problem. Using vectorization techniques from word2vec: Continuous Bag of Words and Skip-gram can help produce the best model performance for Bagging and SVM models. In this study, the data used is expansion data from the PROMISE repository, namely PROMISE_exp, the repository is a collection of software requirements data that has been labeled. To measure performance, this study uses an evaluation matrix, namely precision, recall and f1-score. As a result, the two models that have been trained using the Continuous Bag of Words and skip-gram vectorization techniques will be compared to determine the more optimal model for classifying software requirements from the promise_exp repository.

The scale of software is growing rapidly for organizations begin to deploy their business on internet. It is a need of avoid ambiguity between engineers and users and to avoid mistakes in software requirements. And provide automatic requirement analysis techniques for modeling and analyzing requirements formally and save manpower. In this paper proposed cloud service method for automated detection of quality requirement in software requirement specification. This paper also present novel approach for process of automatic classification of software quality requirements based on supervised machine learning technique applied for the classification of training document and predict target document software quality requirements.

: This document describes the software requirements of a Joint Tactical Radio System (JTRS) Software Communications Architecture (SCA) implementation called the Core Framework (CF). This Software Requirements Specification (SRS) defines the requirements for the Open Radio Communications Architecture Core Framework (OrcaCF) v1.1.0 in accordance with the JTRS SCA version 2.2. The CF software package contains: an Operating System per SCA v2.2, Section 3.1.1, Middleware and Services per SCA v2.2, Section 3.1.2, a Core Framework per SCA v2.2, Section 3.1.3, and a simple application per SCA v2.2, Section 3.2. The OrcaCF was developed on a standard Intel x86-based PC running the Linux Operating System (OS) from RED HAT.