Quality Of Software Requirements Research Articles

Structured SRS for e-Government Services With Boilerplate Design and Interface

There are many projects being carried out to develop e-Government applications. In order to develop an efficient application, a proper requirements specification is strictly required. However, in the case of improper requirements specifications, errors are unavoidable for the developed applications. Therefore, it is necessary to use a model to determine the quality of software requirements. In the literature, several studies have been presented to propose a quality model for software requirements. Yet, there is no study on the development of a quality model for software requirements in Turkish language. Thus, the purpose of this study is to propose a quality assessment model of Software Requirements Specification (SRS) in Turkish language for e-Government applications. The proposed model aims at defining common texts and confirming that the sentences used in writing SRS are developed within an assured structure in order to minimize and standardize the errors originating from natural language. For this purpose, a model based on the Rupp’s boilerplate is created that allows the analyst or requirements engineer to accurately enter the requirements statements. In this study, an interface (webpage) is also created so that the model may match requirements with common text templates, compute similarity values, and also may insert the requirements, regulatory documents, and user requirements into the template in a more convenient format. In order to evaluate the proposed model, the sentences in the 32 documents, including 843 requirements, were adapted to the model. Then, the usability of the model was validated by the requirement engineers serving in a Government service. According to the results, it is concluded that the proposed model is applicable, and is able to improve the quality of SRS in Turkish language for e-Government applications.

Improvement Quality of Software Requirements Using Requirement Negotiation System for Supporting Decision

The Requirement Engineering phase, where all requests and software requirements of the user and the client are delivered, understood and agreed upon. However, often the developers are just too focused on implementing the software, even though the Requirements Engineering phase is a phase that can have a big impact. The impact is not only on the final product but also on the development process itself. In this study, the authors conducted software development negotiation of software requirements as a medium for stakeholders to negotiate the requirements of software products. In the negotiation system, the author will provide a means of decision support or group decision support system that a method of resolving conflicts. The main objectives of this work are twofold: 1) to assist the negotiation process between stakeholders and 2) to improvement quality software after negotiation. The workings of the E-Voting method are by giving choices to each sub-specification that has been chosen by stakeholders. We will select the choice that has the highest number of votes as a specification. We used prototyping as a method of developing a system life cycle because prototyping is very open to improvements that might occur after it releases the prototype version system. The results of evaluations show that the system has a high success rate based on 3 dimensions of testing, Performance (80.5%), Usability (78.5%), and User Satisfaction (78%).

Requirements Engineering for Software Systems: A Systematic Literature Review

This article contains a systematic literature review of requirements engineering for software systems. The literature published within last 5 years was included into the review. A research question was defined as requirements development process of large scale software system (with thousands of requirements) and an interaction problem during this process (communication, coordination and control). The problem is caused by the fact that large-scale software system requirements process is a cross-disciplinary task and it involves multiple parties — stakeholders, domain experts, and suppliers with own goals and constrains, and thus, the interaction between them seriously slows down the overall requirements development process than writing the requirements specification itself. The research papers were classified by several research directions: Natural Language Processing for Requirements Engineering (NLP4RE), Requirement Prioritization, Requirements Traceability, Quality of Software Requirements, Non-functional Requirements and Requirements Elicitation. Motivation and intensity of each direction was described. Each direction was structured and represented with the key references. A contribution of each research direction into the research question was analyzed and summarized including potential further steps. It was identified that some researchers had met a part of the described problem in different forms during their researches. At the end, other researches were described additionally in a short overview. To approach the research question further potential direction was described.

Challenges of Software Requirements Quality Assurance and Validation: A Systematic Literature Review

Validation of software requirements is a primary phase in requirements engineering that ensures requirements match the target system with the intended needs of the acquirer. It aims to detect and correct errors that prevail in the specified requirements. Although there are tremendous requirements validation approaches, some software may fail because of limited or ineffective requirements validation techniques and unreliable requirements’ quality characteristics. In this study, a systematic literature review of requirements validation is performed. The study analyzes the most adopted validation techniques, reports requirements quality characteristics, and discovers significant challenges of validation techniques. The review identified 66 relevant primary studies analyzed to derive deep insights into the following aspects of requirements validation: trends of requirements validation methods, including their subtechnique strengths and weaknesses, requirements quality characteristics categories, and adopted tools and datasets in these techniques. We grouped validation techniques into categories: prototyping, inspection, knowledge-oriented, test-oriented, modeling and assessment, and formal models. The analysis reported 19 validation techniques, 27 tools, new requirements validation characteristics, and several challenges that prevailed through validation techniques. The trend of validation techniques is to those methods that apply machine learning techniques with knowledge from dictionaries and ontologies. Most challenges are about how to express the requirements and how to revert clients’ feedback. There is a strong relationship between validation techniques, software application domain, and requirements validation quality attributes. Thus, there is an immense need to unify the quality characteristics and domain-specific validation methods.

Software Requirements Quality: Using Analytics to Challenge Assumptions at Intel

Creating high-quality software requirements is critically important in the complex, dynamic, and pressurized context of contemporary software development. Our findings challenge assumptions by management and project teams regarding the relationship among requirements quality, and requirements priority, compliance, and defect rates.

Identifikasi Karakteristik Teknik Elisitasi pada Rekayasa Kebutuhan Perangkat Lunak: Sebuah Review Sistematis

Accuracy of elicitation techniques selection will affect the quality of software requirements. However, mostly the selection was based on familiarity only. Therefore, it is necessary to identify the characteristics of each technique and its development. The identification was initialized through paper review on requirements elicitation topics published between 2001-2016. The results show that interviews are most frequently studied techniques. In addition, interviews, brainstorming, and document analysis considered as developed techniques. The developments are related to the use of processing tools from interviews such as tool ladder, electronic communication software and analytical techniques, namely social network analysis and collaborative filtering. The use of web application tools and social network sites marked the development of brainstorming technique. While in document analysis, the involvement of business process models and organizational models characterized the development. Interviews, brainstorming, and document analysis are most frequently used combinations techniques. Document analysis is used to find basic information, while interview is used to engaged with core users, and brainstorming is used to determine the list of requirements.

Lack of Attention to Singular (or Atomic) Requirements Despite Benefits for Quality, Metrics and Management

There are seemingly many advantages to being able to identify, document, test, and trace single or "atomic" requirements. Why then has there been little attention to the topic and no widely used definition or process on how to define atomic requirements? Definitions of requirements and standards focus on user needs, system capabilities or functions; some definitions include making individual requirements singular or without the use of conjunctions. In a few cases there has been a description of atomic system events or requirements. This work is surveyed here although there is no well accepted and used best practice for generating atomic requirements. Due to their importance in software engineering, quality and metrics for requirements have received considerable attention. In the seminal paper on software requirements quality, Davis et al. proposed specific metrics including the "unambiguous quality factor" and the "verifiable quality factor"; these and other metrics work best with a clearly enumerable list of single requirements. Atomic requirements are defined here as a natural language statement that completely describes a single system function, feature, need, or capability, including all information, details, limits, and characteristics. A typical user login screen is used as an example of an atomic requirement which can include both functional and nonfunctional requirements. Individual atomic requirements are supported by a system glossary, references to applicable industry standards, mock ups of the user interface, etc. One way to identify such atomic requirements is from use case or system event analysis. This definition of atomic requirements is still a work in progress and offered to prompt discussion. Atomic requirements allow clear naming or numbering of requirements for traceability, change management, and importance ranking. Further, atomic requirements defined in this manner are suitable for rapid implementation approaches (implementing one requirement at a time), enable good test planning (testing can clearly indicate pass or fail of the whole requirement), and offer other management advantages in project control.

A benchmarking process to assess software requirements documentation for space applications

Poorly written requirements are a common source of software defects and, in application areas like space systems, the cost of malfunctioning software can be very high. This work proposes a benchmarking procedure for assessing the quality of software requirements that adopt the Packet Utilization Standard (PUS) defined by the European Cooperation for Space Standardization (ECSS) standards. The benchmark uses three checklists that aim at guaranteeing that the specifications comply with the PUS standard, consider faulty behaviour, and do not include errors typically found in this type of documents. The benchmark is defined for two services of the PUS standard: the telecommand verification and on board operating scheduling. A benchmark validation approach is also proposed in the paper. It uses the concept of fault injection to insert known errors in software requirements specification documents. The benchmark validation is performed through its application to three projects from different countries. Results show that our proposal provides a simple and effective way for identifying weaknesses and compare the degree of maturity of requirements documents.

Web-Based System for Software Requirements Quality Analysis Using Case-Based Reasoning and Neural Network

The overall success of a software project depends on the quality of its software requirements specifications (SRS). Hence, it is very important to get the requirements correct from the onset of the project. This research paper proposes a web-based system to perform SRS quality analysis using Case-Based Reasoning (CBR) and Artificial Neural Network (ANN). CBR is an AI technique that learns and deduces solutions based on past cases or experiences that are stored in a case base. However, when the case base becomes very large, the “Retrieve” phase of CBR becomes very tedious. So, in this research, we use ANN to improve the retrieval phase within the CBR. ANN measures the similarity of the new case against all existing cases in the case base. This results in a more efficient method of performing quality analysis for a given SRS document.