Towards Multi-Dimensional Separating of NFRs in Software Architecture

Requirements engineering is the first phase in software development life cycle and it also plays one of the most important and critical roles. Requirement document mainly contains both functional requirements and non-functional requirements. Non-functional requirements are significant to describe the properties and constraints of the system. Early identification of Non-functional requirement has direct impact on the system architecture and initial design decision. Practically, non-functional requirements are extracted manually from the document. This makes it tedious, time-consuming task and prone to various errors. In this paper, we propose an automatic approach to identify and classify non-functional requirements using semantic and syntactic analysis with machine learning approaches from unconstrained documents. We used A dataset of public requirements documents (PURE) that consists of 79 unconstrained requirements documents in different forms. In our approach, features were extracted from the requirement sentences using four different natural language processing methods including statistical and state-ofthe-art semantic analysis presented by Google word2vec and bidirectional encoder representations from transformers models. The adopted approach can efficiently classify non-functional requirements with an accuracy between 84% and 87% using statistical vectorization method and 88% to 92% using word embedding semantic methods. Furthermore, by fusing different models trained on different features, the accuracy improves by 2.4% compared with the best individual classifier. INDEX TERMS Software requirement, Machine learning, Natural language processing.

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.

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.

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.

This position paper examines current practices and challenges for tracing non-functional requirements (NFRs). Anecdotal evidence suggests that many organizations do not effectively trace NFRs and that functional changes are often implemented with very little understanding as to how system qualities such as safety, security, and performance will be impacted. The tendency for NFRs to have broad ranging impact upon a software system, and the strong interdependencies and tradeoffs that exist between NFRs and the software architecture leave typical existing traceability methods insufficient for tracing NFRs. This paper focuses on post-requirements traceability of NFRs. It first identifies three critical areas in which NFRs require traceability support, it then evaluates existing traceability methods, and finally proposes a more holistic traceability environment named Goal Centric Traceability that supports impact analysis of NFRs within the context of the software architecture in which they are deployed.

The application of AI technology in architectural software has brought various innovations and changes to the industry. By introducing convolutional neural networks and deep neural networks, architectural design software is expected to automatically identify and generate complex architectural images, optimize the design process, and provide intelligent design assistance. Through literature research, this paper aims to discuss the specific application of CNN and DNN in parametric design and the innovation brought by them, and analyzes the application of these technologies in architectural image recognition, generation, design optimization and other aspects. This paper aims to provide a comprehensive reference for researchers in related fields and promote the innovative application of AI technology in architectural design. The application of AI technology in architectural software has brought numerous innovations and changes to the industry. By introducing convolutional neural networks and deep neural networks, architectural design software is expected to automatically identify and generate complex architectural images, optimize the design process, and provide intelligent design assistance. Through literature research, this paper aims to discuss the specific application of CNN and DNN in parametric design and the innovation brought by them; it also analyzes the application of these technologies in architectural image recognition, generation, design optimization, and other aspects. This paper aims to provide a comprehensive reference for researchers in related fields and promote the innovative application of AI technology in architectural design.

With the growing use of UML diagrams for software architecture description and the importance of non-functional requirements evaluation at software architecture level, filling the scientific gap between architect and requirement analyst is considered to be significant. Software architects are not usually familiar with non-functional requirement analysis and are not able to analyze such requirements easily. On the other hand, non-functional requirements cannot be evaluated directly by UML diagrams. Therefore, the architect should annotate additional information of the nonfunctional requirements to software architecture description and then an executable model can be produced. These executable models can be petri nets, queuing networks, stochastic process algebra and etc. One kind of the UML diagrams that can be used to describe software architecture is component diagram. In this paper, we propose a new algorithm that enables an architect to transform a component diagram into an executable model based on different extensions of petri nets. Moreover, we show how to use this petri net model for performance evaluation and simulation and the implications of this transformation are described completely. Finally, to represent the usage of our proposed algorithm, we consider a case study as an example.

Non-functional requirements NFR, such as availability, usability, performance, and security are often crucial in producing a satisfactory software product. Therefore, these non-functional requirements should be addressed as early as possible in the software development life cycle. Contrary to other non-functional requirements, such as usability and performance, security concerns are often postponed to the very end of the design process. As a result, security requirements have to be tailored into an existing design, leading to serious design challenges that usually translate into software vulnerabilities. In this paper, we present a novel approach to describe high-level security requirements using the Use Case Maps UCM language of the ITU-T User Requirements Notation URN standard. The proposed approach is based on a mapping to UCM models of a set of security architectural tactics that describe security design measures in a very general, abstract, and implementation-independent way. The resulting security extensions are described using a metamodel and implemented within the jUCMNav tool. We illustrate our approach using a UCM scenario describing the modification of consultants' pay rates.

A software architecture is composed of a collection of design decisions. Each design decision helps or hinders certain Non-Functional Requirements (NFR). Current software architecture views focus on expressing components and connectors in the system. Design decisions and their relationships with non-functional requirements are often captured in separate design documentation, not explicitly expressed in any views. This disassociation makes architecture comprehension and architecture evolution harder. In this paper, we propose a UML profile for modeling design decisions and an associated UML profile for modeling non-functional requirements in a generic way. The two UML profiles treat design decisions and nonfunctional requirements as first-class elements. Modeled design decisions always refer to existing architectural elements and thus maintain traceability between the two. We provide a mechanism for checking consistency over this traceability. An exemplar is given as a way to demonstrate the feasibility of our approach.

Earlier software architecture design is essential particularly when it comes to security concerns, since security risks, requirements and architectures are all closely interrelated and interacting. We have proposed the security driven twin peaks method with a mutual refinement of the requirements, and architectures. However, there are multiple alternatives to an architecture design for initial requirements, and their choices depend on non-functional requirements (NFRs), such as security, performance, and costs which have a big impact on the quality of the software. We propose a new method called TPM-SA2 to avoid any back-track in refinement. Each architectural alternative in TPM-SA2 is refined so that it aligns with the requirements. For each refinement, the requirements can be updated vice versa. TPM-SA2 enables us to predict the impacts on the NFRs by each candidate for the architecture, and choose the most appropriate one with respect to the impact. As a result, we can define the requirements and architectures, and estimated the development costs earlier than ever.

This book will help readers gain a solid understanding of non-functional requirements inherent in systems design endeavors. It contains essential information for those who design, use, and maintain complex engineered systems, including experienced designers, teachers of design, system stakeholders, and practicing engineers. Coverage approaches non-functional requirements in a novel way by presenting a framework of four systems concerns into which the 27 major non-functional requirements fall: sustainment, design, adaptation, and viability. Within this model, the text proceeds to define each non-functional requirement, to specify how each is treated as an element of the system design process, and to develop an associated metric for their evaluation. Systems are designed to meet specific functional needs. Because non-functional requirements are not directly related to tasks that satisfy these proposed needs, designers and stakeholders often fail to recognize the importance of such attributes as availability, survivability, and robustness. This book gives readers the tools and knowledge they need to both recognize the importance of these non-functional requirements and incorporate them in the design process

Requirements Engineering plays a crucial role in the software development process. Many works have pointed out that Non-Functional Requirements (NFRs) are critical to the quality of software systems. NFRs, also known as quality requirements, can be difficult to elicit due to their subjective diversity nature. In this paper, we introduce the QR Framework which uses an ontology-based approach to support the collection of knowledge on possible solutions to implement NFRs, semi-automatically connecting related NFRs. Preliminary search mechanisms are provided in a tool to facilitate the identification of possible solutions to an NFR and their related consequences to other solutions and/or other NFRs. To evaluate whether our approach aids eliciting NFRs, we conducted a controlled experiment performing a software development scenario. Our results suggest that reusing NFR knowledge can drive software engineers to obtain a closer to complete set of possible solutions to address quality concerns.

Managing non-functional requirements (NFRs) has been a challenge in software development for many years. These requirements are typically used to make important architectural decisions early in the project, which can be problematic if they are uncertain or unstable. When this uncertainty is not considered when designing the software architecture, changes are often costly and sometimes even unfeasible. Some empirical studies on the subject have already been carried out, but few have focused on the perspective of professionals with extensive experience on the changes and uncertainties of NFRs. This work aims to expand the understanding about the management, clarity and validation of NFRs to fill this gap in the literature. To achieve this goal, a survey was carried out with professionals to find out how NFRs were managed and validated. For the research design, instead of generic questions, the questionnaire focused on some specific types of NFRs to induce participants to recall and report concrete situations. As a result, 40 valid responses were obtained, most from professionals with more than 10 years of experience. The results reveal that a significant number of NFRs were defined after the delivery of software increments (more than 30%) and that revision and change occurred in about a third of the NFRs. Hence, this study presents evidence that NFRs, as the functional ones, can also be uncertain and change frequently, requiring agile approaches and techniques to evolve the software architecture to consider this uncertainty.

Design of a quality software system is a complex and challenging task. This complexity arises due to negligence of non-functional requirements (NFRs) during development process. Model-Driven Development helps in reducing design complexity in the form of a continuous transformation of models of the desired system by providing abstraction at earlier phases of development and code generation. However, non-functional requirements which are important for building correctness in the design of the system are not adequately considered in current model driven development methods. This paper discusses the challenges in dealing non-functional requirements in model-driven development of systems and provides an approach based on architecture design decisions and technical decisions for the integration of nonfunctional properties in model-driven architecture.

The aim of this article is to describe a method that helps analysts to translate qualitative data gathered in the field, collected for the purpose of requirements specification, to a model usable for software engineers. Requirements specification constitutes three different parts: functional requirements, quality requirements, and nonfunctional requirements. The first one specifies how the software system should function, who are the actors, and what are the input and output of the functions. The second one specifies what quality requirements the software should meet while operating in context of its environment such as reliability, usability, efficiency, portability, and maintainability. Finally, the third part specifies other requirements including context of use and development constraints. Examples of context of use are where and when the system is used, and examples of development constraints are human resources, cost and time constraints, technological platforms, and development methods. The role of the requirements specification is to give software engineers a basis for software design, and, later in the software development life cycle, to validate the software system. Requirements specification can also serve the purpose of validating users’ or customers’ view of the requirements of the system. On one hand, there has been a growing trend towards analyzing needs of the user and abilities through participatory design (Kuhn & Muller, 1993), activity theory (Bertelsen & Bødker, 2003), contextual design (Beyer & Holtzblatt, 1998), user-centered design (Gulliksen, Göransson, & Lif, 2001), and co-design and observation as in ethnography (Hughes, O’Brien, Rodden, Rouncefield, & Sommerville, 1995). Common to these methods is that qualitative data (Taylor & Bogdan, 1998) is collected, to understand the future environment of the new system, by analyzing the work or the tasks, their frequency and criticality, the cognitive abilities of the user and the users’ collaborators. The scope of the information collected varies depending on the problem, and sometimes it is necessary to gather data about the regulatory, social, and organizational contexts of the problem (Jackson, 1995) to be solved. The temporal and spatial contexts describe when the work should be carried out and where. On the other hand, software engineers have specified requirements in several different modelling languages that range from semiformal to formal. Examples of semiformal languages are UML (Larman, 2002), SADT, and IDEF (Ross, 1985). Examples of the latter are Z (Potter, Sinclair, & Till, 1996), VDM or ASM. Those are modelling languages for software development, but some languages or methods focus on task or work modelling such as Concurrent Task Trees (Paterno, 2003) and Cognitive Work Analysis (Vicente, 1999). Others emphasize more the specification method than a modelling language. Examples of the former are Scenario-Based Design (SBD) (Rosson & Carroll, 2002) and Contextual Design (Beyer & Holtzblatt, 1998). In practice, many software developers use informal methods to express requirements in text, e.g., as narrations or stories. Agile Development Methods (Abrahamsson, Warsta, Siponen, & Ronkainen, 2003) emphasize this approach and thereby are consistent with their aim of de-emphasizing methods, processes, and languages in favor of getting things to work. A popular approach to requirements elicitation is developing prototypes. There has been less emphasis on bridging the gap between the above two efforts, for example, to deliver a method that gives practical guidelines on how to produce specifications from qualitative data (Hertzum, 2003). One reason for this gap can be that people from different disciplines work on the two aspects, for example, domain analysts or experts in HCI, and software engineers who read and use requirements specification as a basis for design. Another reason for this gap may be in the difference in the methods that the two sides have employed, that is, soft methods (i.e., informal) for elicitation and analysis and hard methods (i.e., formal) for specification. In this article, we suggest a method to translate qualitative data to requirements specification that we have applied in the development of a Smart Space for Learning. The process borrows ideas from or uses scenarios, interviews, feature-based development, soft systems methodology, claims analysis, phenomenology, and UML.