Automated cloud service based quality requirement classification for software requirement specification

A quantitative approach for assessing the priorities of software quality requirements

Software quality assurance (SQA) must be able to support the practical application. This chapter presents the models as well as the software engineering standards available for correctly defining performance or non‐functional requirements of software. It describes the research carried out over the years that culminated in a definition of a software quality model. Quality assurance, in certain industries and business models overseen by the software developer, requires a more formal management of software quality throughout the software life cycle. Quality is often measured by considering a specific perception of quality. The chapter provides the SQA practitioner with the knowledge to use the ISO 25010 software quality model concepts. It presents the history of the different models and standards designed to characterize software quality. The chapter introduces the concept of quality requirements and presents a process for defining quality requirements.

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

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.

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.

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.

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.

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.

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.

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 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.

We propose a software requirements analysis method based on domain ontology technique, where we can establish a mapping between a software requirements specification and the domain ontology that represents semantic components. Our ontology system consists of a thesaurus and inference rules and the thesaurus part comprises domain specific concepts and relationships suitable for semantic processing. It allows requirements engineers to analyze a requirements specification with respect to the semantics of the application domain. More concretely, we demonstrate following three kinds of semantic processing through a case study, (1) detecting incompleteness and inconsistency included in a requirements specification, (2) measuring the quality of a specification with respect to its meaning and (3) predicting requirements changes based on semantic analysis on a change history.

The elicitation, analysis, and specification of quality requirements involve careful balancing of a broad spectrum of competing priorities. Developers must therefore focus on identifying qualities and designing solutions that optimize the product's value to its stakeholders.

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.