Creation of an automated management software requirements environment: A practical experience

We have been involved in a number of large-scale software development projects, which might lead to loss of millions of dollars if failed. The quality of SRS (Software Requirements Specification) is the key to success of the software development. Review and inspection are common practices for the verification and validation of SRS. However, verification techniques used in projects might be characterized as ad hoc. In this article, we propose requirements clinic, a third party inspection methodology for improving the quality of the SRS. In order to systematically inspect a SRS, we developed a perspective-based inspection methodology based on PQM (Pragmatic Quality Model) of SRS. PQM is derived from IEEE Std. 830 from the perspective of pragmatic quality. To inspect a SRS according to PQM, we identified 198 inspection points, which lead to a quality score between 0 and 100. The requirements clinic advises to the requirements engineering team by a comprehensive quality inspection report including quality score, benchmark and SRS patterns for improvement. Since 2010, we have been practicing the methodology to a variety of development projects, and revealed an average of 10.6 ROI in 12 projects. We also discuss the feasibility of the methodology and lessons learned from the practices.

The development success of software is essentially based on the quality of its Software Requirements Specifications (SRS). A requirement represents the main objective that needs to be accomplished, while a specification is a full description of this objective. The inspection of the Software Requirements Specification (iSRS) system is developed to ensure that the SRSs are of high quality. This paper presents the contribution of integrating a fuzzy logic technique in the Case Base Reasoning (CBR) as a reasoning framework in the iSRS system. The fuzzy logic technique provides a disambiguation mechanism within the Retrieve, Reuse, Revise, and Retain steps of the CBR cycle. Specifically, it is used as a similarity measurement technique in the matching process between the inspected SRS cases and the existing SRS cases in the CBR case base. It then classifies and labels the cases in the case base to no-match, partial-match and, complete-match cases. This classification improves the overall reasoning and inspection of the SRS quality by comparing the inspected case with the most similar cases of the case base.

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.

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

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.

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.

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

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

Software requirements specifications (SRS) are often validated manually. One such process is inspection, in which several reviewers independently analyze all or part of the specification and search for faults. These faults are then collected at a meeting of the reviewers and author(s). Usually, reviewers use Ad Hoc or Checklist methods to uncover faults. These methods force all reviewers to rely on nonsystematic techniques to search for a wide variety of faults. We hypothesize that a Scenario-based method, in which each reviewer uses different, systematic techniques to search for different, specific classes of faults, will have a significantly higher success rate. We evaluated this hypothesis using a 3/spl times/2/sup 4/ partial factorial, randomized experimental design. Forty eight graduate students in computer science participated in the experiment. They were assembled into sixteen, three-person teams. Each team inspected two SRS using some combination of Ad Hoc, Checklist or Scenario methods. For each inspection we performed four measurements: (1) individual fault detection rate, (2) team fault detection rate, (3) percentage of faults first identified at the collection meeting (meeting gain rate), and (4) percentage of faults first identified by an individual, but never reported at the collection meeting (meeting loss rate). The experimental results are that (1) the Scenario method had a higher fault detection rate than either Ad Hoc or Checklist methods, (2) Scenario reviewers were more effective at detecting the faults their scenarios are designed to uncover, and were no less effective at detecting other faults than both Ad Hoc or Checklist reviewers, (3) Checklist reviewers were no more effective than Ad Hoc reviewers, and (4) Collection meetings produced no net improvement in the fault detection rate-meeting gains were offset by meeting losses. >

This work proposes an object oriented design method for Ada software. The mehod is mainly intended for software engineers who are not experts in object oriented design, in the context of a course as well as in the context of a firm wanting to acquire experience in object oriented design. To meet this objective, the method is simple and easy to learn. It also minimizes the risks of errors and it is possible to use it without resorting to complex tools in order to easily develop a small application. We will start by giving the basic concepts used in the method. Then we will describe the phases of the method. Finally, we will apply the method on a small example: a search tool for documents. The first phase is the software requirements phase in which the functions offered by the software are analysed and described in a software requirements specification. The second phase is the architectural design in which the components of the architecture are identified. The components identified are the objects and classes of the application, their structures, the associations between them, their attributes and the services they export. These components are described in an architectural design document. The third phase is the detailed design phase in which the components identified during the architectural design phase are described in detail. Among other things, the Ada mechanisms used to code the components are given. The results of this phase are a detailed design document and the Ada specifications of the objects and classes. Finally, the last phase is the implementation phase whose results are the listings of the code implementing objects and classes identified during the second phase.

Software systems are becoming an integral part of all walks of life. This aggravates the need for an artificial intelligent perspective for requirements engineering, which allows for modeling and analyzing requirements formally, rapidly and automatically, avoiding mistakes made by misunderstanding between engineers and users, and saving lots of time and manpower. To address this problem, we propose a process of acquiring requirements automatically, which adopts automated planning techniques and machine learning methods to convert software requirement into an incomplete planning domain, and propose an algorithm AMLCP to learn action models with uncertain effects. Furthermore, we obtain a complete planning domain by applying this algorithm and convert it into software requirement specification.

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.

Completeness in software requirements specification is one of the key factors for successful software development. For specifying software requirements, scenario-based approach is broadly used, comprising a basic flow regarding the successful use of the system, and alternative flows describing abnormal or less frequent interactions of the system. However, alternative flows tend to be frequently missed in many cases, because of the relative lower significance rather than the basic flow, which eventually have an influence on achieving the completeness of software requirements. In order to address the issue, we propose an approach for automatically recommending alternative flows from a basic flow by extracting the essential use case patterns based on the occurrence patterns of the agents and measuring the verb similarity between the main verbs of each scenario. In order to validate our approach, we apply it to three industrial case studies, and show comprehensiveness of the suggested alternative flows and synergic effectiveness for inexperienced developers.