Special issue on High Assurance Systems Engineering

This editorial introduces the special issue on High Assurance Systems Engineering concepts for safe, secure, and reliable software systems in the Journal of Software: Evolution and Process. The nine papers published in this special issue were selected from extended versions of papers presented at the 2016 IEEE International Symposium on High Assurance Systems Engineering (HASE 2016) held in Orlando, Florida, through a highly competitive review process. The papers propose and discuss emerging solutions that address at least one of the three characteristics identified as foundational requirements to design, verify, and operate contemporary high assurance software systems: safety, security, and reliability, though, several papers consider a combination of these requirements, by modeling software system dependability and/or system resilience in the face of operational changes. The modeling aspects of the papers include fault‐tolerant design and analysis, online logic adaptation, decision and risk analysis, malware detection, and disaster management solutions, as well as several formalized testing and verification techniques.

CAFI: A Configurable location-Aware Fault Injection technique for software reliability assessment against soft errors

As in traditional software development, non-functional requirements play also a crucial role in service-oriented development. Non-functional requirements are spread across the entire service-oriented system or within individual services and cannot be allocated to one specific system / service artefact (such as a package, component). This makes them often more difficult to handle than functional requirements. The specifics of service-oriented architectures (in particular highly distributed services) bring up additional difficulties. In this paper, we present a taxonomy for non-functional requirements in a service-oriented context. The taxonomy implements three main categories of non-functional requirements: process requirements, non-functional external requirements, and non-functional service requirements. The taxonomy can be applied with individual services as well as with a service-based system as a whole. This taxonomy is considered as a starting point and check list when handling non-functional issues in service-oriented and particularly highly distributed environments.

One of the primary responsibilities of requirement engineer is the elicitation of non-functional and functional requirements. Functional requirements sketch out the functionality, the system has to be performed while non-functional requirements compel the restrictions on this functionality. Software industry is raising its demand for not only the required functionality but the necessity of non-functional requirements too such as performance, security, usability, security, privacy etc. The current practice in the industry is to deal with functional requirements as first class requirements while non-functional requirements are only catered at design and implementation level. This approach leaves a serious flaw in the system design towards user satisfaction and often results in the failure of projects such as the classic example of London Ambulance System[1]. The chances of software success can be maximized when dealing with NFR at the requirements level. This literature survey is a first effort of its kind to seek key NFR challenges and issues while elicitation level of requirement engineering. It also find-outs the approaches and methods that are suggested in literature to deal with these issues.

As Machine Learning (ML) becomes ever more ubiquitous, it is critical to increase the rigor of design and testing. In traditional software, this is done using the Requirements Engineering (RE) process, but RE looks different for ML because it is data-centric. There are different Non-Functional Requirements (NFRs) and standard testing techniques do not apply. While there are standards for verifying NFRs in traditional software, there is no standard measurement for ML NFRs, e.g. how is a model verified to meet an explainability NFR? In traditional software, NFRs are decomposed into Functional Requirements (FRs), but without clear measurements for ML NFRs, their decomposition into FRs is nearly impossible. However, recently, research has shown that provenance can help improve model transparency and reproducibility. This work builds on such literature and suggests provenance as a lower-level NFR to connect high-level NFRs, e.g. explainability and transparency, and FRs, thereby enabling concrete model verification based on requirement specifications. This work examines types of ML provenance and their use in decomposing model NFRs into verifiable FRs, thereby better aligning ML development with RE and increasing the rigor of ML testing. This paper aggregates current literature on provenance for ML and provides a method of measurement for otherwise unquantifiable NFRs. This work also analyzes trends in how provenance can decompose various ML NFRs and future directions for the field.

Non-Functional requirements (NFRs) are overlooked whereas Functional Requirements (FRs) take the center stage in developing agile software. Research has shown that ignoring NFRs can have negative impacts on the software and could potentially cost more to fix at later stages. This research extends the Capture Elicit Prioritize (CEP) methodology to predict NFRs in the early stages agile software development. Research in other fields such as the medical field have shown that historical data can be beneficial in the long run. In the medical field it was found that historical data can be beneficial in determining patient treatments. The Capture Elicit Prioritize (CEP) methodology extended the NERV and NORMAP methodologies in previous research. The CEP methodology identified 56 out of 57 requirement sentences and was successful in eliciting 98.24% of the baseline an improvement of 10.53% of the NORMAP methodology and 1.75% improvement over the NERV methodology. The NFRs count for the CEP methodology was 86 out of 88 NFRs which was an improvement of 12.49% over the NORMAP methodology and 4.55% over the NERV methodology. The CEP was used and utilized the EU eProcument requirements document. The CEP methodology utilized the capture methodology by gathering potential NFRs using OCR from requirements images. The elicit part took the NFR Locator plus and takes sentences from documents and places them in distinct categories. The NFR categories are defined from the Chung's NFR framework utilizing a set of keywords utilized for training to locate NFRs. The e αβγ-framework was utilized to prioritize the NFRs. Utilizing the data from previous research of the CEP methodology and extending the CEP methodology to include a decision tree to predict future NFRs. A simple decision tree was utilized to make a prediction utilizing the past NFRs data. If a certain NFR appears three times or higher in the requirements document. It is most likely that NFRs will appear in the next iteration of the software requirements specification. If the NFRs is equivalent to three times it is likely it will appear in the next iteration. If the NFRs is between one and two it is not likely to appear in future iteration. The path can be traced from the root of the tree to a decision tree's leaf (yes or no) that determines whether the NFRs will appear in future iterations. This research showed that using the data available can be beneficial for the next iteration of software development. This research showed that historical metadata can help in predicting NFRs utilizing a decision tree to make a prediction where NFRs appear multiple times in a set of the EU procurement documents can predict the next iteration of software development. The NFRs Availability, Compliance, Confidentiality, Documentation, Performance, Security, and Usability were found and these NFRs are most likely to appear in the next iteration of the EU procurement software.

Requirements Engineering (RE) is the area of softwa re engineering that deals with the discovery and specification of the objectives for the system unde r development and the environment in which it is us ed including the human activities it supports. Require ment Elicitation is process of gathering requiremen ts from stakeholders. Incorporating RE to identify non Functional Requirements (NFR) in early stages of design and implementation avoids ambiguities, confl icting requirement and other defects. The efficacy of the requirement engineering methodology is its abil ity to capture NFR in an efficient manner. In this study, we propose a novel method of elicitation using mobi le multimedia and to automatically trace the NFR. T he requirements description is captured in video using smart phones. Requirement document are prepared using voice to text converter. NFR is detected auto matically from the requirement document and hand gestures emphasise the importance of the requirement. It is observed that the precision and recall of the class ifiers is better using multimedia data. Features were extract ed from video frame and audio using image processing technique and speech processing. We investigated data mining approach to identify Non Functional Requirements (NFR) from Functional Requirement (FR) Documents. Results obtained were satisfactory.

Self-adaptation of service compositions through product line reconfiguration

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.

Providentia: Using search-based heuristics to optimize satisficement and competing concerns between functional and non-functional objectives in self-adaptive systems

In web system development, the Non-Functional Requirements (NFRs) are typically considered only briefly during the requirements elicitation stage and not rigorously articulated by either web developers or the client. This paper reports on an investigation into this issue involving interviews with web developers who were engaged in commercial web development projects. The results from this qualitative research highlight that web developers commonly do not pay sufficient attention to NFRs. This arises due to uncertainty, lack of time, lack of knowledge in the importance of NFRs and partly because NFRs are not readily available and documented from previous similar projects. Web developers also do not elicit NFR at the same time and at the same level of details as Functional Requirements (FRs). This study highlights that exploring the domain at an early stage of development will help developers to better understand NFR. A lack of rigour in articulating NFRs may significantly impact on the development effectiveness and the quality of the resulting web system. An evaluation of NFRs may also lead to discovering new FRs.

Currently, the customer's demands have expressively amplified their expectations of getting software at a high-quality level. However, the non-functional requirements of the software products attention have been expanded in both the academic and the industrial fields; so, there is no framework for specifying and measuring such kinds of quality constraints for the security requirements of software product quality. This paper presents an integrated framework of the early specification and measurement of the functional and non-functional software security requirements. Such a measurement framework would help software and systems engineers to improve product qualities whether the software has already been delivered or has yet to be built. The main steps that have been followed include: identify, specify and measure the software security requirements based on ISO/IEC SQuaRE series of international standards for software product quality. A standard measurement framework used to measure the functional size of the software product quality to develop a functional size measurement of the functional and non-functional security requirements is described. As a result, a functional size measurement framework of the functional and non-functional security requirements (SPQNFSR) using international standards is proposed. An automatic teller machine case study for the measurement of security requirements based on perspectives of a software functional user requirements is presented. Finally, it is concluded that it is essential to develop such a functional size measurement framework for functional and non-functional security requirements to support developers to face the challenges derived from early dealing with such requirements.

Breast cancer is the most common cancer in Jordan. Mutations in BReast CAncer susceptibility gene 1 and BReast CAncer susceptibility gene 2 (BRCA1/2 genes) greatly increase the lifetime risk of developing breast and/or ovarian cancer in women. The aim of this paper is to identify functional and non-functional requirements for BRCA 1/2 testing, as a corner stone for establishing BRCA 1/2 testing services in the country and as a case example for other susceptibility genetic testing for cancer. During two sessions, the authors outlined the functional and non-functional requirements for BRCA1/2 testing, as types of categories of requirements, using the Sommerville approach. Six functional requirements were identified. Non-functional requirements were divided to: 1. Product related 2. Process related and 3. Externally related (Interoperability and Legal, Social, Ethical and Professional (LSEP) Implications). The authors will continue to build on their work in order to produce a full model for BRCA1/2 testing to provide the most comprehensive and advanced cancer care for patients and facilitate future development of innovate measures in the battle against cancer.

Functional and non-functional requirements are equally important in software engineering. Both of them are mixed together within the same software requirement document. Usually, they are expressed in natural languages. So, a lot of human effort is required to classify them. Software requirements classification is a challenging task. Requirements classification can help developers to deliver quality software that meets users' expectations completely. In this paper, we present a Semi-Automated classification approach of Arabic functional and non-functional requirements using a natural language processing (NLP) tool. We propose a set of heuristics based on basic constructs of Arabic sentences in order to extract information from Arabic software requirements to classify the requirements into functional and non-functional requirements. This research aims to help software engineers by reducing the cost and time required in performing manual classification of software requirements.

Software requirements classification is a human-intensive task performed during the requirements analysis phase in software development. This literature review analyzes the state-of-the-art of the classification of software requirements using Artificial Neural Networks. Fourteen articles were selected to conduct the review. Sixteen different techniques to classify requirements were identified where, besides artificial neural networks, the most popular are Naive Bayes and the Support Vector Machine. Among the reported Artificial Neural Networks, we identify Convolutional Neural Networks and a Shallow Neural Network. We also found seven approaches that classify functional and non-functional requirements, six that classify only non-functional requirements, and one of them that classifies only functional requirements. The most used metrics to express classification results were accuracy, recall, and F-score. Finally, the results of the classifiers are gathered and reported.