No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Are "Non-functional" Requirements really Non-functional? An Investigation of Non-functional Requirements in Practice
Abstract
Non-functional requirements (NFRs) are commonly distinguished from functional requirements by di↵erentiating how the system shall do something in contrast to what the system shall do. This distinction is not only prevalent in research, but also influences how requirements are handled in practice. NFRs are usually documented separately from functional requirements, without quantitative measures, and with relatively vague descriptions. As a result, they remain dicult to analyze and test. Several authors argue, however, that many so-called NFRs actually describe behavioral properties and may be treated the same way as functional requirements. In this paper, we empirically investigate this point of view and aim to increase our understanding on the nature of NFRs addressing system properties. We report on the classification of 530 NFRs extracted from 11 industrial requirements specifications and analyze to which extent these NFRs describe system behavior. Our results suggest that most " non-functional " requirements are not non-functional as they describe behavior of a system. Consequently, we argue that many so-called NFRs can be handled similarly to functional requirements.
... Although this limitation is inherent in supervised learning, the ability to deal with previously unseen classes can bring huge benefits to many real-world applications where classes are artificially defined, with no common consensus, or where classes may evolve over time, with new classes emerging and old ones becoming obsolete. One such example is requirements classification where several classification schemes exist for non-functional requirements (NFRs) [17,18]. ...
... Most studies in ML-based requirements classification focus on the categorisation between functional (FR) and non-functional (NFR, or "quality" [28]) requirements, and on the further categorisation of different NFR classes, such as security, performance, usability, etc. However, the distinction between FR and NFR has been a matter of debate in the RE community [29,16], and the empirical study by Eckhardt et al. [18] shows that NFRs can include functional aspects. Furthermore, there is a more fine-grained representation of FRs and NFRs given by the ISO/IEC/IEEE 29148:2018(E) Standard [20], which distinguishes between functional/performance, quality, usability, interface, and other classes, thus refining the conceptualisation already elaborated by the NFR classification from Glinz [17]. ...
... Furthermore, there is a more fine-grained representation of FRs and NFRs given by the ISO/IEC/IEEE 29148:2018(E) Standard [20], which distinguishes between functional/performance, quality, usability, interface, and other classes, thus refining the conceptualisation already elaborated by the NFR classification from Glinz [17]. Yet, despite the lack of consensus what NFRs are, and how we should classify and represent them, the differentiation between FRs and NFRs is a common categorisation in RE, and in the following we will use this distinction, keeping in mind that it is an artificial construct [18]. ...
Context: Requirements engineering (RE) researchers have been experimenting with machine learning (ML) and deep learning (DL) approaches for
a range of RE tasks, such as requirements classification, requirements tracing, ambiguity detection, and modelling. However, most of today’s ML/DL
approaches are based on supervised learning techniques, meaning that they
need to be trained using a large amount of task-specific labelled training
data. This constraint poses an enormous challenge to RE researchers, as the
lack of labelled data makes it difficult for them to fully exploit the benefit
of advanced ML/DL technologies. Objective: This paper addresses this
problem by showing how a zero-shot learning (ZSL) approach can be used
for requirements classification without using any labelled training data. We
focus on the classification task because many RE tasks can be framed as
classification problems. Method: The ZSL approach used in our study
employs contextual word-embeddings and transformer-based language models
(LMs). We demonstrate this approach through a series of experiments to
perform three classification tasks: (1) FR/NFR — classification functional
requirements vs non-functional requirements; (2) NFR — identification of
NFR classes; (3) Security — classification of security vs non-security requirements. Results: The study shows that the ZSL approach achieves an F1
score of 0.66 for the FR/NFR task. For the NFR task, the approach yields F1∼ 0.72 − 0.80, considering the most frequent classes. For the Security
task, F1 ∼ 0.66. All of the aforementioned F1 scores are achieved with
zero-training efforts. Conclusion: This study demonstrates the potential of
ZSL for requirements classification. An important implication is that it is
possible to have very little or no training data to perform classification tasks.
The proposed approach thus contributes to the solution of the long-standing
problem of data shortage in RE.
... Although this limitation is inherent in supervised learning, the ability to deal with previously unseen classes can bring huge benefit to many real-world applications where classes are artificially defined, with no common consensus, or where classes may evolve over time, with new classes emerging and old ones becoming obsolete. One such example is requirements classification where several classification schemes exist for non-functional requirements (NFRs) [22,23]. As software applications, their requirements, and the theory of NFRs itself evolve over time, so do the classification schemes. ...
... Most studies in ML-based requirements classification focus on categorisation between functional (FR) and non-functional (NFR, or "quality" [33]) requirements, and on further categorisation of different NFR classes, such as security, performance, usability, etc. However, the distinction between FR and NFR has been a matter of debate in the RE community [34,9], and the empirical study by Eckhardt et al. [23] shows that NFRs can include functional aspects. Furthermore, there is a more fine-grained representation of FRs and NFRs given by the ISO/IEC/IEEE 29148:2018(E) Standard [25], which distinguishes between functional/performance, quality, usability, interface, and other classes, thus refining the conceptualisation already elaborated by the NFR classification from Glinz [22]. ...
... Furthermore, there is a more fine-grained representation of FRs and NFRs given by the ISO/IEC/IEEE 29148:2018(E) Standard [25], which distinguishes between functional/performance, quality, usability, interface, and other classes, thus refining the conceptualisation already elaborated by the NFR classification from Glinz [22]. Yet, despite the lack of consensus what NFRs are, and how we should classify and represent them, the differentiation between FRs and NFRs is a common categorisation in RE, and in the following we will use this distinction, keeping in mind that it is an artificial construct [23]. ...
Context and motivation: Requirements Engineering (RE) researchers have been experimenting Machine Learning (ML) and Deep Learning (DL) approaches for a range of RE tasks, such as requirements classification, requirements tracing, ambiguity detection, and modelling. Question-problem: Most of today's ML-DL approaches are based on supervised learning techniques, meaning that they need to be trained using annotated datasets to learn how to assign a class label to sample items from an application domain. This constraint poses an enormous challenge to RE researchers, as the lack of annotated datasets makes it difficult for them to fully exploit the benefit of advanced ML-DL technologies. Principal ideas-results: To address this challenge, this paper proposes an approach that employs the embedding-based unsupervised Zero-Shot Learning (ZSL) technique to perform requirements classification. We focus on the classification task because many RE tasks can be framed as classification problems. In this study, we demonstrate our approach for three tasks. (1) FR-NFR: classification functional requirements vs non-functional requirements; (2) NFR: identification of NFR classes; (3) Security: classification of security vs non-security requirements. The study shows that the ZSL approach achieves an F1 score of 0.66 for the FR-NFR task. For the NFR task, the approach yields F1 ~ 0.72-0.80, considering the most frequent classes. For the Security task, F1 ~ 0.66. All of the aforementioned F1 scores are achieved with zero-training efforts. Contribution: This study demonstrates the potential of ZSL for requirements classification. An important implication is that it is possible to have very little or no training data to perform multiple tasks. The proposed approach thus contributes to the solution of the longstanding problem of data shortage in RE.
... There is an academic debate on what quality requirements are and what they should be called [48]. We found a study indicating that quality requirements-sometimes called non-functional requirements-are functional or behavioral [41]. This is in line with other studies that report that a mix of requirements type is common [14]. ...
... Two studies find that architects address quality requirements the same way as other requirements [33,84], also confirmed in other surveys [83]. However, there are also research studies indicating a varying prevalence and explicitness than other requirements [14,41,49,80,90]. We interpret the current state of evidence to be unclear on the handling of quality requirements. ...
... We found three case study papers reporting on artifact analysis of realistic requirements documents [14,41,90]. ...
Quality requirements deal with how well a product should perform the intended functionality, such as start-up time and learnability. Researchers argue they are important and at the same time studies indicate there are deficiencies in practice. Our goal is to review the state of evidence for quality requirements. We want to understand the empirical research on quality requirements topics as well as evaluations of quality requirements solutions. We used a hybrid method for our systematic literature review. We defined a start set based on two literature reviews combined with a keyword-based search from selected publication venues. We snowballed based on the start set. We screened 530 papers and included 84 papers in our review. Case study method is the most common (43), followed by surveys (15) and tests (13). We found no replication studies. The two most commonly studied themes are (1) differentiating characteristics of quality requirements compared to other types of requirements, (2) the importance and prevalence of quality requirements. Quality models, QUPER, and the NFR method are evaluated in several studies, with positive indications. Goal modeling is the only modeling approach evaluated. However, all studies are small scale and long-term costs and impact are not studied. We conclude that more research is needed as empirical research on quality requirements is not increasing at the same rate as software engineering research in general. We see a gap between research and practice. The solutions proposed are usually evaluated in an academic context and surveys on quality requirements in industry indicate unsystematic handling of quality requirements.
... In one of the first publications in this domain [14], economic aspects of software are mentioned in the same turn as purely engineering-related aspects such as reliability, usability or safety. Other authors [15,16,17] reflect only on the structural and behavioral aspects of NFRs and hence also approach them solely from a technical perspective. In contrast, recent works in this context [18,19] have a broader notion of NFRs. ...
... Specially, these studies examined the use of certain measurement or evaluation techniques of NFRs in practice or tested novel approaches in practical settings and industrial contexts followed by e.g., expert interviews from different domains. Also interesting is the comparatively high number of philosophical papers, which e.g., sketch possible ways of intertwining functional and non-functional requirements [47] or challenge the scope and notion of NFRs and their demarcation from functional requirements [16,17]. ...
... Due to the apparent similarities of the themes to the ISO 25010 standard, we primarily outline important differences or additions of the respective NFRs in DevOps. [140,141,142,143,16,144,17,66,145,146,147,148,149,150,151,104,152,153,112] Table 9: Themes and objectives of technical quality-focused NFRs. ...
Context: Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. Objective: In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. Method: We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Results: Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. Conclusion: The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software. Remark This paper is an addition to our peer-reviewed publication in [1] and contains a more elaborate presentation of our findings. When citing our work, please always cite the peer-reviewed publication; citing this technical report should always be optional for cases where you explicitly reference aspects that were not published in the peer-reviewed publication.
... In one of the first publications in this domain [14], economic aspects of software are mentioned in the same turn as purely engineering-related aspects such as reliability, usability or safety. Other authors [15,16,17] reflect only on the structural and behavioral aspects of NFRs and hence also approach them solely from a technical perspective. In contrast, recent works in this context [18,19] have a broader notion of NFRs. ...
... Specially, these studies examined the use of certain measurement or evaluation techniques of NFRs in practice or tested novel approaches in practical settings and industrial contexts followed by e.g., expert interviews from different domains. Also interesting is the comparatively high number of philosophical papers, which e.g., sketch possible ways of intertwining functional and non-functional requirements [47] or challenge the scope and notion of NFRs and their demarcation from functional requirements [16,17]. ...
... Due to the apparent similarities of the themes to the ISO 25010 standard, we primarily outline important differences or additions of the respective NFRs in DevOps. [140,141,142,143,16,144,17,66,145,146,147,148,149,150,151,104,152,153,112] Table 9: Themes and objectives of technical quality-focused NFRs. ...
Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software.
... Examples of requirements are: "The system must provide an online help function" and "It must be possible to completely restore a running configuration when the system crashes". An average software project normally has a few hundreds of requirements (Eckhardt et al., 2016). The complete set of requirements for a specific system is called a "requirements document" or a "requirements specification". ...
... However, regardless of what ML approach is used, a common problem with requirements classification is class imbalance in the training data (He and Garcia, 2009), as requirements categories are naturally uneven, usually with a small percentage of categories containing a large percentage of the requirements (Kurtanović and Maalej, 2017;Eckhardt et al., 2016). Class imbalance in requirements classification is known as relative class imbalance, as the minority classes are not necessarily rare in their own right but rather relative to the majority classes (He and Garcia, 2009). ...
Context: Classification of software requirements into different categories is a critically important task in requirements engineering (RE). Developing machine learning (ML) approaches for requirements classification has attracted great interest in the RE community since the 2000s. Objective: This paper aims to address two related problems that have been challenging real-world applications of ML approaches: the problems of class imbalance and high dimensionality with low sample size data (HDLSS). These problems can greatly degrade the classification performance of ML methods. Method: The paper proposes HC4RC, a novel ML approach for multiclass classification of requirements. HC4RC solves the aforementioned problems through semantic-role-based feature selection, dataset decomposition and hierarchical classification. We experimentally compare the effectiveness of HC4RC with three closely related approaches - two of which are based on a traditional statistical classification model whereas one uses an advanced deep learning model. Results: Our experiment shows: 1) The class imbalance and HDLSS problems present a challenge to both traditional and advanced ML approaches. 2) The HC4RC approach is simple to use and can effectively address the class imbalance and HDLSS problems compared to similar approaches. Conclusion: This paper makes an important practical contribution to addressing the class imbalance and HDLSS problems in multiclass classification of software requirements.
... Some of these services are related to booking accommodation close to the users' destination, information on touristic attractions, festivals, and other events , as well as the ability to participate in the platform not only as a user but as a service provider too (Ashkrof et al., 2020). Finally, the quality attributes are critical when designing any digital artifact, as they describe 'how well the system shall perform or offer its functionalities' (Eckhardt et al., 2016). We defined ten feature domains that grouped the identified features. ...
... Quality attributes are essential to ensure the usability and effectiveness of the entire system and increase user satisfaction. This indicates that travelers value non-functional requirements equally or even more than functional requirements (Eckhardt et al., 2016). Planning booking and payments were ordered higher than the rest regarding the Feature Domains. ...
Mobility as a Service (MaaS) aims to offer travelers easy and convenient access to transportation modes via a joint digital channel, often in a mobile application. MaaS has the potential to fundamentally change the way we commute as it encourages a more sustainable travel behavior. MaaS, as a business model, is an innovative concept that integrates a variety of these solutions and can significantly change the mobility environment by encouraging sustainable travel behavior. Despite the existing initiatives and efforts toward MaaS solutions, there is still no consensus on the essential features of MaaS platforms for actors from the supply and demand sides. This study explores the critical features of MaaS platforms from the perspective of mobility service providers - MSP (i.e., supply-side) and travelers (i.e., demand-side). We collected data via interviews with mobility experts for the supply side and a survey for the users' side. Based on a Gaussian Graphical Model, our results show that optimizing the number and use of the vehicles and appropriate data handling are the essential features of a MaaS platform for the MSPs. For the travelers, although retrieval of personal information and enhancing services, such as suggestions on local events and concert tickets, are expected, they are considered less significant. Our study provides insights into the features of MaaS platforms through synthesized and prioritized features -including their relationships-which would be helpful both for research and practice.
... Despite the great benefits organizations reap through CSE [8], NFRs have rarely been explored in the context of CSE [9]. Studies of practice demonstrate NFRs are inherently difficult to explicitly express [10] and even more difficult to verify or validate [11], whether they are part of a formal requirements specification or an agile user story. In agile settings NFRs present more engineering difficulties than functional requirements [12]. ...
... Despite this importance, NFRs for organizations in agile settings are often "informally stated, contradictory, difficult to enforce during development, and very hard to validate" [26]. For example, 75% of NFRs in a recent study from Eckhardt, Vogelsang, and Mendez [10] were actually describing system behaviour . Finally, the wide-ranging and extensive NaPiRE study [27] found that "unclear / unmeasurable non-functional requirements" were one of the top problems respondents had with requirements in their small organizations [28, p.11]. ...
Non-functional requirements (NFR), which include performance, availability, and maintainability, are vitally important to overall software quality. However, research has shown NFRs are, in practice, poorly defined and difficult to verify. Continuous software engineering practices, which extend agile practices, emphasize fast paced, automated, and rapid release of software that poses additional challenges to handling NFRs. In this multi-case study we empirically investigated how three organizations, for which NFRs are paramount to their business survival, manage NFRs in their continuous practices. We describe four practices these companies use to manage NFRs, such as offloading NFRs to cloud providers or the use of metrics and continuous monitoring, both of which enable almost real-time feedback on managing the NFRs. However, managing NFRs comes at a cost as we also identified a number of challenges these organizations face while managing NFRs in their continuous software engineering practices. For example, the organizations in our study were able to realize an NFR by strategically and heavily investing in configuration management and infrastructure as code, in order to offload the responsibility of NFRs; however, this offloading implied potential loss of control. Our discussion and key research implications show the opportunities, trade-offs, and importance of the unique give-and-take relationship between continuous software engineering and NFRs. Research artifacts may be found at https://doi.org/10.5281/zenodo.3376342.
... Our previous work brings supporting evidence that addressing deficiencies in quality requirements take a long time (Olsson et al. 2019). The main reasons are a lack of explicit handling of quality requirements on a strategic level (also highlighted by Ameller et al. (2013), Eckhardt et al. 2016) and a lack of a feedback-loop in the scope decision process, which is one possibility to understand better the user experience and perception of the quality requirements. Companies working agile also struggle with managing quality requirements when looking at the big picture (team coordination challenge) and making unstated assumptions (conceptual challenge) (Alsaqaf et al. 2019). ...
... The terms quality requirements and non-functional requirements are the two prevailing terms. One can claim that many "non-functional" requirements are in fact functional (Eckhardt et al. 2016;Berntsson Svensson et al. 2013). As pointed out by Martin Glinz in 2007, there was no generally agreed definition of quality requirements (Glinz 2007). ...
Quality requirements are vital to developing successful software products. However, there exist evidence that quality requirements are managed mostly in an “ad hoc” manner and down-prioritized. This may result in insecure, unstable, slow products, and unhappy customers. We have developed a conceptual model for the scoping process of quality requirements – QREME – and an assessment model – Q-REPM – for companies to benchmark when evaluating and improving their quality requirements practices. Our model balances an upfront forward-loop with a data-driven feedback-loop. Furthermore, it addresses both strategic and operational decisions. We have evaluated the model in a multi-case study at two companies in Sweden and three companies in The Netherlands. We assessed the scoping process practices for quality requirements and provided improvement recommendations for which practices to improve. The study confirms the existence of the constructs underlying QREME. The companies perform, in the median, 24% of the suggested actions in Q-REPM. None of the companies work data-driven with their quality requirements, even though four out of five companies could technically do so. Furthermore, on the strategic level, quality requirements practices are not systematically performed by any of the companies. The conceptual model and assessment model capture a relevant view of the quality requirements practices and offer relevant improvement proposals. However, we believe there is a need for coupling quality requirements practices to internal and external success factors to motive companies to change their ways of working. We also see improvement potential in the area of business intelligence for QREME in selecting data sources and relevant stakeholders.
... One of the reasons for such results could be the small number of research articles devoted to RE for ML at the time of searching. Another reason could be the use of inconsistent terminology for certain RE activities or software requirements, like (1) the use of synonyms for the term "requirement," (2) the disagreement over the naming of certain RE activities, e.g., "requirements validation" over "requirements verification", further discussed in [45], or (3) the disagreement over the nature, terminology, and definition of the non-functional requirements, further discussed in [46]. A third reason could be the significant difference between the conventional and the ML software development process, leading to a potential terminological inconsistency of the second one with the first. ...
Over the last decade, machine learning methods have revolutionized a large number of domains and provided solutions to many problems that people could hardly solve in the past. The availability of large amounts of data, powerful processing architectures, and easy-to-use software frameworks have made machine learning a popular, readily available, and affordable option in many different domains and contexts. However, the development and maintenance of production-level machine learning systems have proven to be quite challenging, as these activities require an engineering approach and solid best practices. Software engineering offers a mature development process and best practices for conventional software systems, but some of them are not directly applicable to the new programming paradigm imposed by machine learning. The same applies to the requirements engineering best practices. Therefore, this article provides an overview of the requirements engineering challenges in the development of machine learning systems that have been reported in the research literature, along with their proposed solutions. Furthermore, it presents our approach to overcoming those challenges in the form of a case study. Through this mixed-method study, the article tries to identify the necessary adjustments to (1) the best practices for conventional requirements engineering and (2) the conventional understanding of certain types of requirements to better fit the specifics of machine learning. Moreover, the article tries to emphasize the relevance of properly conducted requirements engineering activities in addressing the complexity of machine learning systems, as well as to motivate further discussion on the requirements engineering best practices in developing such systems.
... Although the relevance of NFRs is widely accepted, the discourse and approaches on how to deal with them are still dominated by how to differentiate them from functional requirements [11,16]. Although more effort has been invested in satisfying NFRs [5], it seems that there is still an uneven emphasis on the importance given to the system's features and its quality requirements [15]. Understanding when NFRs are defined and how they change during the project can provide valuable evidence to guide software development, in particular, how the solution design and architecture accommodate these changes. ...
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.
... The Functional requirements are the list of attributes that define the service provided by the system, and NFRs are the constraints on these services such as performance, maintainability, security etc. Nowadays, these requirements are still written in natural language and functional requirements are clearly written, whereas NFRs are usually written in paragraphs or sentences [2]. Therefore, manual extraction of NFRs is becoming an ambiguous task, because different analyst and developers come from different background and expertise, and may interpret same NFRs keywords into different ones [3]. To address this issue, word representation techniques (such as part-of-speech (POS) tags, term frequency/ Inverse document frequency (IDF)) are explored to extract common features [4]. ...
... Often FRs are related to the core functionality, and NFRs describe the properties and constraints of the system. The distinction between FRs and NFRs impacts the handling of requirements elicitation, documentation, and validation process [12]. Therefore, the task of automatic extraction and classification of requirements has been the focus of RE researchers. ...
[Context and Motivation] Requirements in tender documents are often mixed with other supporting information. Identifying requirements in large tender documents could aid the bidding process and help estimate the risk associated with the project. [Question/problem] Manual identification of requirements in large documents is a resource-intensive activity that is prone to human error and limits scalability. This study compares various state-of-the-art approaches for requirements identification in an industrial context. For generalizability, we also present an evaluation on a real-world public dataset. [Principal ideas/results] We formulate the requirement identification problem as a binary text classification problem. Various state-of-the-art classifiers based on traditional machine learning, deep learning, and few-shot learning are evaluated for requirements identification based on accuracy, precision, recall, and F1 score. Results from the evaluation show that the transformer-based BERT classifier performs the best, with an average F1 score of 0.82 and 0.87 on industrial and public datasets, respectively. Our results also confirm that few-shot classifiers can achieve comparable results with an average F1 score of 0.76 on significantly lower samples, i.e., only 20% of the data. [Contribution] There is little empirical evidence on the use of large language models and few-shots classifiers for requirements identification. This paper fills this gap by presenting an industrial empirical evaluation of the state-of-the-art approaches for requirements identification in large tender documents. We also provide a running tool and a replication package for further experimentation to support future research in this area.KeywordsRequirements identificationRequirements classificationtender documentsNLP
... Although much work has been devoted to NFRs [30], ensuring the attainment of NFRs remains a difficult challenge in modern system development [36]. Despite challenges, progress on NFRs has been made, including, for example, definitions (e.g., [30]), taxonomies (e.g., [29]), classification methods (e.g., [22]), modeling approaches (e.g., [21]), management methods (e.g., [38]), and industrial studies (e.g., [26]) for traditional systems. ...
Systems that rely on Machine Learning (ML systems) have differing demands on quality—known as non-functional requirements (NFRs)—from traditional systems. NFRs for ML systems may differ in their definition, measurement, scope, and comparative importance. Despite the importance of NFRs in ensuring the quality ML systems, our understanding of all of these aspects is lacking compared to our understanding of NFRs in traditional domains. We have conducted interviews and a survey to understand how NFRs for ML systems are perceived among practitioners from both industry and academia. We have identified the degree of importance that practitioners place on different NFRs, including cases where practitioners are in agreement or have differences of opinion. We explore how NFRs are defined and measured over different aspects of a ML system (i.e., model, data, or whole system). We also identify challenges associated with NFR definition and measurement. Finally, we explore differences in perspective between practitioners in industry, academia, or a blended context. This knowledge illustrates how NFRs for ML systems are treated in current practice, and helps to guide future RE for ML efforts.
... This analysis is needed to identify the requirements needed to develop the application. Functional requirements are what an application is capable of doing while non-functional requirements can be defined as how the system shall do something [11]. Table 2 shows the Functional Requirement Analysis of the developed application that explains the functionality of each module and interface while Table 3 shows the Non-functional Requirement Analysis that describes the important characteristics implemented on the application to deliver an application that is functioning well and meets the user's needs. ...
lagging in education as compared to their hearing peers. This can affect their communication skills and affect their academic achievement. However, the existing applications developed for sign language education have a few drawbacks, such as only consisting of a Learning Module, and the media used was only learning videos. Hence, the Mobile Learning for Manually Coded Malay Sign Language using Augmented Reality (KTBM AR) is developed to provide users with Learning and Activity Modules where users can interact with and test their knowledge. Not only that, but KTBM AR also included Augmented Reality (AR) as an interactive learning medium to engage users more in learning. The methodology used in developing this application is the ADDIE model, which comprises five main phases: analysis, design, development, implementation, and evaluation. The result from testing shows that the application was successfully developed with a range of 94% acceptable according to the System Usability Scale (SUS). Thus, it can be concluded that KTBM AR is suitable to be implemented in sign language learning.
... Software quality attributes are specific to the development project because each software system has different priorities, concerns, and constraints. However, it has been observed that software developments taking place in the same application domain present a similar prioritization in terms of the definition of software quality attributes (Eckhardt, Vogelsang & Fernández, 2016). In this sense, quality attributes can be prioritized by application domain. ...
Computational models of emotion (CMEs) are software systems designed to emulate the diverse aspects of the human emotion process. This type of model is commonly incorporated into cognitive agent architectures to provide mechanisms underlying affective behavior. The construction of CMEs involve theories that explain human emotion as well as computational artifacts related to the design and implementation of software systems. Although most CMEs reported in the literature provide details on their theoretical foundations, it is uncommon to find details about the computational practices and artifacts utilized during their design and implementation phases. This paper presents and discusses some challenges associated with the computational nature of this type of model: (i) Software quality attributes in CMEs, (ii) Interoperability between CMEs and cognitive components, (iii) Formal procedures for the design of CMEs, and (iv) Reference schemes to validate CMEs. Software engineering is used as a reference to propose and discuss these challenges. In addition, a reference architecture designed by following software engineering practices and artifacts is proposed to discuss the implications of addressing these challenges. The present research is at the intersection of human emotion modeling and software engineering to contribute to the software development process of affective systems.
... Examples of typical functional legal, privacy ethical and social requirements include: authentication, administrative functions, authorization levels, legal or regulatory requirements, audit tracking, external interfaces and reporting requirements. Non-functional requirements describe how a system shall do something or how it should behave and what limits there are on its functionality [26]. The second categorization applied specifically to the legal, privacy, ethical and legal requirements for the project. ...
The use of Artificial Intelligence (AI) systems in the health domain requires developers of these systems to consider a wider view of requirements beyond traditional data security requirements. Data controllers of these systems should also include requirements that consider legal, privacy, fundamental rights, social, and ethical values. However, harmonized guidelines around AI principles and requirements are not agreed and divergent. This requires a creative approach with the development of these requirements for AI projects. Furthermore, many of the guidelines fail to establish a link between principles and actionable requirements. In this paper we present the methodology used to develop the legal, privacy, social and ethical requirements for an AI based medical imaging project entitled Medical Imaging Ireland (Med-I). Furthermore, we provide an overview of an assessment of these requirements implementation within the Med-I project.KeywordsPrivacySocial and ethical requirementsArtificial Intelligence (AI)Impact assessment
... The prevalence of these two software qualities may vary with other types of software systems. However, previous studies show that usability is a prominent quality aspect that can be often found in user reviews [50] as well as in documented requirements [53], and that it is considered of high importance [54]. On the other hand, it is plausible that the prevalence of compatibility in our cases has to do with the type of systems. ...
Crowd-based Requirements Engineering (CrowdRE) promotes the active involvement of a large number of stakeholders in RE activities. A prominent strand of CrowdRE research concerns the creation and use of online platforms for a crowd of stakeholders to formulate ideas, which serve as an additional input for requirements elicitation. Most of the reported case studies are of small size, and they analyze the size of the crowd, rather than the quality of the collected ideas. By means of an iterative design that includes three case studies conducted at two organizations, we present the CREUS method for crowd-based elicitation via user stories. Besides reporting the details of these case studies and quantitative results on the number of participants, ideas, votes, etc., a key contribution of this paper is a qualitative analysis of the elicited ideas. To analyze the quality of the user stories, we apply criteria from the Quality User Story framework, we calculate automated text readability metrics, and we check for the presence of vague words. We also study whether the user stories can be linked to software qualities, and the specificity of the ideas. Based on the results, we distill six key findings regarding CREUS and, more generally, for CrowdRE via pull feedback.
... Li et al. [3] considered non-functional requirements as to quality constraints and used a quality-oriented approach to model non-functional requirements. Some researchers argue that the distinction between functional and non-functional requirements is artificially defined [30] and that many non-functional requirements also include functional requirements [31]. Automatic extraction and classification of requirements from textual natural language documents have been a popular research topic in requirements engineering. ...
Requirements classification is a significant task for requirements engineering, which is time-consuming and challenging. The traditional requirements classification models usually rely on manual pre-processing and have poor generalization capability. Moreover, these traditional models ignore the sentence structure and syntactic information in requirements. To address these problems, we propose an automatic requirements classification based BERT and graph attention network (GAT), called DBGAT. We construct dependency parse trees and then utilize the GAT for mining the implicit structure feature and syntactic feature of requirements. In addition, we introduce BERT to improve the generalization ability of the model. Experimental results of the PROMISE datasets demonstrate that our proposed DBGAT significantly outperforms existing state-of-the-art methods. Moreover, we investigate the impact of graph construction methods on non-functional requirements classification. DBGAT achieved the best classification results on both seen (F1-scores of up to 91%) and unseen projects (F1-scores of up to 88%), further demonstrating the strong generalization ability.
... Although significant research has been devoted to NFRs, significant challenges remain for modern system development. Even for traditional systems, NFRs are difficult and challenging to express explicitly [6], and even more difficult to verify or validate [17]. Such challenges compound for ML systems, and the identification, definition, and measurement of NFRs for ML systems has emerged as a critical problem to solve [8,9]. ...
Systems that rely on Machine Learning (ML systems) have differing demands on system quality compared to traditional systems. Such quality demands, known as non-functional requirements (NFRs), may differ in their definition, scope, and importance from NFRs for traditional systems. Despite the importance of NFRs for ML systems, our understanding of their definitions and scope -- and of the extent of existing research in each NFR -- is lacking compared to our understanding in traditional domains. Building on an investigation into importance and treatment of ML system NFRs in industry, we make three contributions towards narrowing this gap: (1) we present clusters of ML system NFRs based on shared characteristics, (2) we use Scopus search results -- as well as inter-coder reliability on a sample of NFRs -- to estimate the number of relevant studies on a subset of the NFRs, and (3), we use our initial reading of titles and abstracts in each sample to define the scope of NFRs over parts of the system (e.g., training data, ML model, or other system elements). These initial findings form the groundwork for future research in this emerging domain.
... The ISO25010 defines quality in use as to whether the solution fulfills the goals with effectiveness, efficiency, freedom from risk, and satisfaction [2]. Eckhardt et al. analyzed 530 quality requirements and found that they described a behavior -essentially a function [10]. Hence, the term non-functional might be counter-intuitive. ...
Quality requirements deal with how well a product should perform the intended functionality, such as start-up time and learnability. Researchers argue they are important and at the same time studies indicate there are deficiencies in practice. Our goal is to review the state of evidence for quality requirements. We want to understand the empirical research on quality requirements topics as well as evaluations of quality requirements solutions. We used a hybrid method for our systematic literature review. We defined a start set based on two literature reviews combined with a keyword-based search from selected publication venues. We snowballed based on the start set. We screened 530 papers and included 84 papers in our review. Case study method is the most common (43), followed by surveys (15) and tests (13). We found no replication studies. The two most commonly studied themes are 1) Differentiating characteristics of quality requirements compared to other types of requirements, 2) the importance and prevalence of quality requirements. Quality models, QUPER, and the NFR method are evaluated in several studies, with positive indications. Goal modeling is the only modeling approach evaluated. However, all studies are small scale and long-term costs and impact are not studied. We conclude that more research is needed as empirical research on quality requirements is not increasing at the same rate as software engineering research in general. We see a gap between research and practice. The solutions proposed are usually evaluated in an academic context and surveys on quality requirements in industry indicate unsystematic handling of quality requirements.
... Recent evidence suggests that FRs and NFRs differ little in terms of their behavioural characteristics, therefore they may be integrated into a common SRS (Eckhardt, Vogelsang and Méndez Fernández, 2016). One challenge of SRS is that requirements may change over the course of the project. ...
Adaptive building envelopes can dynamically adapt to environmental changes, often supported by a control system. Although adaptive building envelopes can play a significant role in improving thermal building performance, uncertainties and risks have led to a slow uptake in the built environment. A reason for this is the reluctance of practitioners to consider integrating adaptive building envelopes in building design. This may be due to Building Performance Simulation (BPS) tools that can be employed for performance prediction of design proposals with adaptive building envelopes. However, a shortcoming of existing tools is their limited adaptation that hinders proper modelling of the influence of control decisions on the dynamic behaviour of these building envelopes. This thesis investigates an approach for the integrated modelling of control and adaptive building envelope. To this aim, an interview-based industry study with experts in adaptive building envelope simulation was conducted. The interview study aimed to advance the understanding of the limitations of adaptive building envelope simulation in current design practice and to identify implications for future tool developments. The feedback from the interviewees was then used to inform the development of an integrated modelling approach using co-simulation, the accuracy and functionality of which were subsequently tested through a validation study and a multiple case study. The findings of the interview study outline the need for more flexible modelling approaches that enable designers to fully exploit adaptive building envelopes in building design. The proposed modelling approach for predicting the thermal performance of adaptive building envelopes has shown that its co-simulation setup seems to offer more flexibility in integrating the dynamic behaviour of adaptive building envelopes. What is now needed is to observe the execution of the modelling approach in design practice to obtain realistic feedback from its users and to verify that it works as intended.
... NFRs written in natural language can be vague, ambiguous, and/or imprecise leading to software engineers misunderstanding what is required of the software to be developed [1]. Software architects, analysts, and developers always find it challenging and timeconsuming to analyze, understand, and classify NFRs from requirements documents, because all of these tasks require expertise, training, experience, and domain knowledge [2]. People with different education backgrounds, culture, or expertise may understand the same NFRs differently [3]. ...
... where to classify test data (the requirements to be classified) based on the "supervision" of the training data. In requirements engineering, classifying software requirements by their kind into functional requirements and non-functional requirements [39,108] is a widely accepted standard practice today. ...
In recent years, system design constraints evolve more and more requiring to embed more stakeholders in the projects. Consequently, modern software projects are becoming many times larger and more complex than in the past. Model-Based Systems Engineering (MBSE) methods are on their side recognized to foster holistic view of design and empower high quality and maintainable software architecture. However, architecture design models are always extracted manually by engineers, which became a tedious, time-consuming and error prone task. Especially, the exponential growth of the number of system requirements raises difficulties in managing the requirements manually and having a clear crystal view of the expectation and scope of the system to be designed. The lack of human expertise as well as powerful automation tools are often cited as the main key barriers that still slow down the spread of the MBSE approach and present significant hurdles to demonstrate its Return On Investments (ROI).Recently, Artificial Intelligence (AI) has been receiving intensive attention and its applications have made their way into products in our daily life. In fact, AI techniques together with suitable technology have enabled systems to perceive, predict, and act in assisting humans in a wide range of applications. Hence, it stands to reason that advances in AI can bring great practical value to mitigate some of the challenges raised by the adoption of MBSE. In this thesis, we contributed a first step towards applying AI for MBSE to optimize the adoption of MBSE and resolve some of its challenges. Specifically, we proposed a new flow of Machine Learning (ML) and Natural Language Processing (NLP) components, empowering the automation to go from natural language requirements towards a preliminary UML architecture design model including a package breakdown model denoting the system’s decomposition. First, we proposed a clustering solution that helps to decompose the complex system into smallest sub-systems based on the semantic similarity of early requirements. The core of the proposed clustering solution is a semantic similarity computation module that analyzes the semantic information of both the words and requirement statements of each pair of requirements using the neural word embedding model word2vec. Accordingly, a set of clusters of similar requirements are generated denoting the identified sub-systems and hence, helping to reduce the complexity of the target system. Then, we proposed a model extractor that extracts from each identified cluster (i.e., sub-system), the relevant elements that are needed to build the UML use-case package break-down model using a set of NLP heuristics. Finally, we proposed a mapping operation that programmatically maps the extracted model elements into their corresponding ones in the target UML use-case package model. Our proposal was prototyped on Papyrus and evaluated on several case studies encompassing different types of natural language software requirements.
... In this work, we focus on NFRs as quality requirements. Despite the NFR-related challenges, progress in the area of NFR exploration has been made, including, for example, definitions (e.g., [7]), taxonomies (e.g., [9]), classification methods (e.g., [10]), modeling approaches (e.g., [5]), management methods (e.g., [11]), and industrial studies (e.g., [12]). ...
Machine Learning (ML) is an application of Artificial Intelligence (AI) that uses big data to produce complex predictions and decision-making systems, which would be challenging to obtain otherwise. To ensure the success of ML-enabled systems, it is essential to be aware of certain qualities of ML solutions (performance, transparency, fairness), known from a Requirement Engineering (RE) perspective as non-functional requirements (NFRs). However, when systems involve ML, NFRs for traditional software may not apply in the same ways; some NFRs may become more prominent or less important; NFRs may be defined over the ML model, data, or the entire system; and NFRs for ML may be measured differently. In this work, we aim to understand the state-of-the-art and challenges of dealing with NFRs for ML in industry. We interviewed ten engineering practitioners working with NFRs and ML. We find examples of (1) the identification and measurement of NFRs for ML, (2) identification of more and less important NFRs for ML, and (3) the challenges associated with NFRs and ML in the industry. This knowledge paints a picture of how ML-related NFRs are treated in practice and helps to guide future RE for ML efforts.
... A set of formal design requirements was collated from all three sources: (1) iterative review and feedback from experts, (2) patient usability evaluations and interviews, and (3) researcher observations of the system implementation. They are classified as functional and non-functional, the former describing what a system will do and the latter how it does this [38]. These can also be understood as what makes the system useful and what makes it usable. ...
Patients on haemodialysis face complex care pathways, a high treatment burden and lower quality-of-life. Working with multidisciplinary domain experts, we have conducted several iterative development cycles to design, develop and evaluate a portal for patients on haemodialysis that can help them better understand and navigate their care pathways. A key functionality of the portal is to improve data and information sharing with clinicians, including on key aspects of quality-of-life through Patients Reported Outcome Measures. A case study was conducted with multidisciplinary experts and patients in the NHS Greater Glasgow and Clyde health board (Scotland), using interviews combined with the System Usability Scale (n = 26). Patients’ feedback and system use observations were used to further refine the system design requirements and functionalities. Key lessons include: a wide preference for tablet-based input vs paper, identification of case-specific accessibility issues and situational impairment, benefits of self-completed digital data collection in overcoming such issues and promoting patient independence and privacy, with considerations for maintaining perceived value and engagement with such systems and when to offer alternatives.
... The requirements can be divided into two categories, functional requirements and non-functional requirements. The functional requirements determine what type of tasks a system is expected to carry out, but the non-functional requirements create constraints on how those tasks can be fulfilled [12]. Based on the general requirements, safety and security requirements will be investigated. ...
... This generally occurs as the main focus is on getting the system's functional features explicitly and formally defined [33,46,83]. This phenomenon can be partially attributed to the vague understanding of what quality concerns actually comprise [33,67,68,82]. Take for instance the description of requirement: "R1: the system shall collect real-time traffic information". ...
To build successful and cost-effective software systems, in conjunction with functional requirements, software development practices advocate for more rigorous understanding of non-functional requirements often referred to as "quality concerns." Typically, during the requirement elicitation phase, software architects primarily focus on satisfying and prioritizing functional requirements while neglecting quality concerns. When this requirement elicitation gap occurs, developers typically retrofit solutions by implementing quality concerns at the code-level. This poses a risk on the stability of the entire software architecture---as developers may inadvertently make system-wide design decisions compromising architectural well-formalized design decisions. Aside from that, developers have to reason about which functional pieces of the code interact with which non-functional ones. The caveat is that when such interactions are poorly or vaguely understood, future modifications may lead to defects resulting in excessive maintenance costs. When defects are reported, they are generally addressed with adhoc bug-fixing code, often, resulting in code fragmentation. Seemingly, the architectural knowledge associated with quality concerns becomes fragmented across implemented code leading to architectural drift phenomena. Typically, architectural drift occurs due to the effect of both "scattered" and "tangled" code---code that leads to poor readability, maintainability, low reuse and, high impact and cost of changes.
Understanding quality concerns under these effects is a resource-intensive process even for experienced developers; Especially when developers perform system-wide tasks such as iteratively tracing monitoring quality concerns, refactoring, or fixing bugs at the code-level. To promote a better understanding of quality concerns, an automated process to acquire even partial knowledge of these concerns would be highly desirable. This would steer developers towards building a proactive awareness about quality concerns across evolving software artifacts.
This thesis adopts a comprehensive approach for detecting system-wide emerging quality-related concerns across various software artifacts. First, I introduce a novel three-pronged approach to detect a diverse set of quality-related concerns in bug report summaries---concerns which are then traced in buggy code. Second, I integrate textual and structural information to improve structural-based refactoring tools by promoting high-level human explanations via analysis of commit messages. Finally, I implement a ranked-based bug-fixing search tool that recommends bug-fixing comments from lengthy discussion threads of past solved bugs to fix a new bug. These bug-fixing comments are ranked and recommended in the context of user query relevance, use of positive language, and semantic relevance.
In summary, this thesis explores a series of solutions by leveraging natural language information with different semantic-based strategies and machine learning-based techniques. Ultimately, these solutions serve as transformative advances for reducing the comprehension gap between how developers reason about quality-related concerns and how such concerns are intertwined and scattered across artifacts.
In the broader context, this thesis makes an effort to further enhance comprehension of quality concerns during software maintenance and evolution, software reuse, code reuse, and supports consistency between design and the code.
... We also identified the terms developers used to discuss QAs and ATs. We found that most of discussed QAs (i.e., about 45% QA-AT posts) describe QA behavioral properties of a system [41]. For example, a developer mentioned that "Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, it may be possible to launch a denial of service attack by depleting the resource pool 9 ", and in around 85% the mined QA-AT posts, developers discuss AT and QA issues using a variety of terms (see Tables 1 and 2), for example, developers used the words "workload", "memory consumption", "application crash", and "low speed" to describe Performance issues in the QA-AT posts. ...
Context: Architecture Tactics (ATs) are architectural building blocks that provide general architectural solutions for addressing Quality Attributes (QAs) issues. Mining and analyzing QA-AT knowledge can help the software architecture community better understand architecture design. However, manually capturing and mining this knowledge is labor-intensive and difficult. Objective: Using Stack Overflow (SO) as our source, our main goals are to effectively mine such knowledge; and to have some sense of how developers use ATs with respect to QA concerns from related discussions. Methods: We applied a semi-automatic dictionary-based mining approach to extract the QA-AT posts in SO. With the mined QA-AT posts, we identified the relationships between ATs and QAs. Results: Our approach allow us to mine QA-AT knowledge effectively with an F-measure of 0.865 and Performance of 82.2%. Using this mining approach, we are able to discover architectural synonyms of QAs and ATs used by designers, from which we discover how developers apply ATs to address quality requirements. Conclusions: We make two contributions in this work: First, we demonstrated a semi-automatic approach to mine ATs and QAs from SO posts; Second, we identified little-known design relationships between QAs and ATs and grouped architectural design considerations to aid architects make architecture tactics design decisions.
... We also identified the terms developers used to discuss QAs and ATs. We found that most of discussed QAs (i.e., about 45% QA-AT posts) describe QA behavioral properties of a system [41]. For example, a developer mentioned that "Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, it may be possible to launch a denial of service attack by depleting the resource pool 9 ", and in around 85% the mined QA-AT posts, developers discuss AT and QA issues using a variety of terms (see Tables 1 and 2), for example, developers used the words "workload", "memory consumption", "application crash", and "low speed" to describe Performance issues in the QA-AT posts. ...
Context: Architecture Tactics (ATs) are architectural building blocks that provide general architectural solutions for addressing Quality Attributes (QAs) issues. Mining and analyzing QA-AT knowledge can help the software architecture community better understand architecture design. However, manually capturing and mining this knowledge is labor-intensive and difficult.
Objective: Using Stack Overflow (SO) as our source, our main goals are to effectively mine such knowledge; and to have some sense of how developers use ATs with respect to QA concerns from related discussions.
Methods: We applied a semi-automatic dictionary-based mining approach to extract the QA-AT posts in SO. With the mined QA-AT posts, we identified the relationships between ATs and QAs.
Results: Our approach allow us to mine QA-AT knowledge effectively with an F-measure of 0.865 and Performance of 82.2%. Using this mining approach, we are able to discover architectural synonyms of QAs and ATs used by designers, from which we discover how developers apply ATs to address quality requirements.
Conclusions: We make two contributions in this work: First, we demonstrated a semi-automatic approach to mine ATs and QAs from SO posts; Second, we identified little-known design relationships between QAs and ATs and grouped architectural design considerations to aid architects make architecture tactics design decisions.
... These attributes describe mainly quality aspects of published services such as availability, cost, response time, reliability, performance, etc. An interesting work classified and analyzed each of 530 studied attributes extracted from 11 industrial requirements specification [2]. The aim of this work is to determine if the NFRs can be really considered as nonfunctional requirements, or simply be approached as behavioral aspects that can be treated in the same way as the functional requirements. ...
The web service technology has still proved its effectiveness in the digital revolution we are facing. This success unfortunately raises more and more complex obstacles, particularly related to the service composition. The integration of Non-Functional Requirements (NFRs) in each step of service composition process, starting with abstract service composition specification to the generation of the verified and concrete composed services, represents one of them. Furthermore, this complexity remains more difficult when NFRs are addressed in both quantifiable (i.e. Quality of Service) and behavioral aspects. Despite the relevant contributions present in the literature, this challenge still remains an open issue when considering NFRs modeling, publishing, integrating with each other, and handling conflicts and dependencies in the whole composition's lifecycle. As a consequence, we suggest this contribution that aims to propose an approach showing how to weave efficiently required NFRs with functional requirements in a complete lifecycle composition supporting specification, formalization, model checking verification and integration steps of desired concrete composite service. Patient Health Records in Regional and University Health Centers in Morocco is used as a case study to experiment our approach.
Context:: Classification of software requirements into different categories is a critically important task in requirements engineering (RE). Developing machine learning (ML) approaches for requirements classification has attracted great interest in the RE community since the 2000s. Objective:: This paper aims to address two related problems that have been challenging real-world applications of ML approaches: the problems of class imbalance and high dimensionality with low sample size data (HDLSS). These problems can greatly degrade the classification performance of ML methods. Methods:: The paper proposes HC4RC, a novel ML approach for multiclass classification of requirements. HC4RC solves the aforementioned problems through semantic-role based feature selection, dataset decomposition and hierarchical classification. We experimentally compare the effectiveness of HC4RC with three closely related approaches — two of which are based on a traditional statistical classification model whereas one using an advanced deep learning model. Results:: Our experiment shows: (1) The class imbalance and HDLSS problems present a challenge to both traditional and advanced ML approaches. (2) The HC4RC approach is simple to use and can effectively address the class imbalance and HDLSS problems compared to similar approaches. Conclusion:: This paper makes an important practical contribution to addressing the class imbalance and HDLSS problems in multiclass classification of software requirements.
The processes through which new leaders in systems engineering are nurtured and developed – what are frequently referred to, collectively, as the systems engineering “leadership pipeline” – are integral to supplying the systems engineering community with its members and ensuring the continuing success (and, arguably, existence) of the systems engineering discipline. Given its significance, it is vital that the systems engineering leadership pipeline (much like any system) adheres to its requirements and demonstrates a high level of performance quality in its intended role. However, what has been observed in terms of the pipeline’s operational behaviour is far from ideal. Fewer than 10% of systems engineers and engineering project managers are women, a far cry from the value of around 50% that would be expected with all things being equal. This disparity highlights a fundamental imbalance in how the systems engineering pipeline processes the “inputs” it receives (in terms of students) and suggests that there may be further underlying problems in the systems engineering pipeline that may be affecting its performance and quality.This chapter strives to analyse the issue of the systems engineering gender gap through a quantitative lens, using quality management techniques to characterize current performance, isolate areas of the pipeline that merit further improvement, and describe concrete means by which engineering leadership and other engineering professionals can enact and measure positive change in systems engineering and broader fields under the umbrella of science, technology, engineering, and mathematics.KeywordsSystems engineeringLeadership pipelineWomen in STEMDiversityEquityGender equalityGender gapSTEM educationDMAICProfessional developmentSix Sigma
Non-functional requirements are property that software products must have in order to meet the user’s business requirements, and are additional constraints on the quality and characteristics of software systems. They are generally written by software designers and documented in various parts of requirements documentation. When developing systems, developers need to classify non-functional requirements from requirements documents, and classifying these non-functional requirements requires professional skills, experience, and domain knowledge, which is challenging and time-consuming for developers. It would be beneficial to implement automatic classification of non-functional requirements from requirements documents, which could reduce the manual, time, and mental fatigue involved in identifying specific non-functional requirements from a large number of requirements. In this paper, a deep neural network model called NFRNet is designed to automatically classify non-functional requirements from software requirement documents. The network consists of two parts. One is an improved BERT word embedding model based on N-gram masking for learning context representation of the requirement descriptions, and the other is a Bi-LSTM classification network for capture context information of the requirement descriptions. We use a Softmax classifier in the end to classify the requirement descriptions. At the same time, in order to accelerate the training and improve the generalization ability of the model, the network uses multi-sample dropout regularization technology. This new regularization technology can reduce the number of iterations needed for training, accelerate the training of deep neural networks, and the networks trained achieved lower error rates. In addition, we expanded the original non-functional requirements dataset (PROMISE dataset) and designed a new dataset called SOFTWARE NFR. The new dataset far exceeds the original dataset in terms of the number of requirement description sentences and the number of non-functional requirements categories. It can be taken as a new testbed for non-functional requirements classification. Through cross-validation on the new dataset, the experimental results show that the network designed in this paper is significantly better than the other 17 classification methods in terms of Precision, Recall, and F1-score. At the same time, for the training set and the validation set, using the multi-sample dropout regularization technology can accelerate the training speed, reduce the number of iterations, and achieve lower error rates and loss.
Natural language is widely used to write software requirements. Generally, software designers start with textual requirements and realize them into a first architectural design. A common problem in this transition is the conceptual gap between the requirements space and the software architecture space. To assist designers in the task, we propose an AI-based approach for deriving high-level architecture descriptions expressed as Use Case Maps (UCMs) from textual requirements. Our approach consists of three steps: (i) identification of responsibilities from functional requirements, (ii) extraction of causal relationships between the responsibilities, and (iii) allocation of the responsibilities to architectural components. Thus, designers can obtain a first view of a software solution that covers both structural and behavioral aspects. This view is useful for assessing architecture alternatives or for further design refinements. The approach relies on NLP and Data Mining techniques. An experimental evaluation with four case studies revealed that our approach detected on average 75% of the responsibilities in term of F-measure.
This paper proposes a pilot approach based on the comparative analysis of supervised Machine Learning models coupled with basic Natural Language Processing concepts for classifying Functional and Non-Functional Requirements from huge collections of data relevant to the Requirements Engineering (RE) phase within software development. The publicly available PROMISE Software Engineering Repository dataset is used in the execution of this approach. Non-Functional Requirements are further classified into subclasses based on attributes they address since they are not directly related to the core functions of the concerned software. This overall research initiative helps to make the RE phase more efficient and reduces human effort in software development. It leverages Big Data in Software Engineering
Requirement Engineering has radicalized data analytics by playing a pivotal role in planning requirements strategies and activities. It has emerged as a leading domain of software engineering that branches into 2 categories namely functional requirements (FRs) and non-functional requirements (NFRs). Functional Requirements have gained eminence and prominence while NFRs have always faced a step-sisterly treatment. It is a lit large in the literature review that NFRs are very crucial and never considered appropriately and consequently, the systems have failed. The present study presents an automated system for efficient NFRs prediction. The proposed system consists of 4 layers for the prediction of NFRs significance including Data acquisition layer (DA), feature selection and extraction layer (FSE), data extraction and mining layer (DEM), and data analysis and visualization layer (DAV). Moreover, the current research considers the probability measure of the level of NFR significance in terms of LoNFRS, which is cumulatively quantified as NFRs significance measure (NFRINDEX). NFRINDEX has been quantified for prediction purposes using an convolution neural network (CNN). Additionally, the existence of NFRs is visualized based on a self organized mapping (SOM) procedure. To validate the proposed system, a primary dataset is collected from several IT professionals and academicians. The NFRs dataset of 312 IT professionals and academicians has been gathered for 17 attributes resulting in 5304 instances. Numerous experimental simulations were performed to assess performance in terms of classification, reliability, stability, feature selection, and prediction efficiency.
Zentral in der Anforderungsanalyse ist die Frage: Welchen Wert schafft die zu entwickelnde Software für den Auftraggeber? Das zielt primär auf die zu schaffende Funktionalität. Liegt der Funktionsumfang fest, muss die geforderte Funktionalität im Detail beschrieben werden. Dabei stößt man in der Regel immer wieder auf Einzelfragen, wie ein System in einer bestimmten Situation zu (re)agieren hat, wie eine Funktion im Einzelnen zu spezifizieren ist und auf welche konkrete Weise die Interaktion zwischen einem Nutzer und dem System zu erfolgen hat. Dies alles bestimmt die Bereitschaft zur Nutzung einer Software und ihre Attraktivität für den Nutzer und damit letztlich ihren Wert. Bei der Analyse und Dokumentation der Anforderungen können wir zwei große Teilgebiete unterscheiden. Zum einen sind das die Produktanforderungen, die sich auf Fragen der funktionalen Nutzung eines Systems beziehen. Dabei wird festgelegt, welche Funktionalität das System oder das Produkt in welcher Form anbietet. Zum anderen sind das Qualitätsanforderungen, die eine Reihe von unterschiedlichen Qualitätseigenschaften eines Systems betreffen, sich also mit der Fragestellung befassen, in welcher Qualität das System umgesetzt wird und seine Funktionalität erbringt. Die beiden Felder sind sehr unterschiedlicher Natur und erfordern deshalb unterschiedliche Vorgehensweisen, Methoden und Modelle, welche in diesem Kapitel vorgestellt werden.
Blockchain has been one of Gartner’s Top 10 Strategic Technology Trends for several consecutive years. The technology has evolved from a platform allowing transactions of cryptocurrency between peers (e.g. Bitcoin) to a platform allowing the design of Decentralized Applications (DApps). Despite their growing popularity, little attention has been paid to the Software Engineering aspect of DApps. In this work, we aim to start bridging this gap by addressing the Requirements Engineering of DApps. We collect, analyze and integrate DApp user reviews in order to propose a first list of user requirements for DApps. The results can have practical implications for both practitioners and researchers. The former can use the results to guide them in the design of DApps, while the latter can see this paper as a first result to build upon to advance the software engineering field of blockchain-based applications.
Non-functional requirements (NFR), which include performance, availability, and maintainability, are vitally important to overall software quality. However, research has shown NFRs are, in practice, poorly defined and difficult to verify. Continuous software engineering practices, which extend agile practices, emphasize fast paced, automated, and rapid release of software that poses additional challenges to handling NFRs. In this multi-case study we empirically investigated how three organizations, for which NFRs are paramount to their business survival, manage NFRs in their continuous practices. We describe four practices these companies use to manage NFRs, such as offloading NFRs to cloud providers or the use of metrics and continuous monitoring, both of which enable almost real-time feedback on managing the NFRs. However, managing NFRs comes at a cost—as we also identified a number of challenges these organizations face while managing NFRs in their continuous software engineering practices. For example, the organizations in our study were able to realize an NFR by strategically and heavily investing in configuration management and infrastructure as code, in order to offload the responsibility of NFRs; however, this offloading implied potential loss of control. Our discussion and key research implications show the opportunities, trade-offs, and importance of the unique give-and-take relationship between continuous software engineering and NFRs. Research artifacts may be found at
https://doi.org/10.5281/zenodo.3376342
.
Context: Seamless model-based development provides integrated chains of models, covering all software engineering phases. Non-functional requirements (NFRs), like reusability, further play a vital role in software and systems engineering, but are often neglected in research and practice. It is still unclear how to integrate NFRs in a seamless model-based development. Goal: Our long-term goal is to develop a theory on the specification of NFRs such that they can be integrated in seamless model-based development. Method: Our overall study design includes a multi-staged procedure to infer an empirically founded theory on specifying NFRs to support seamless modeling. In this short paper, we present the study design and provide a discussion of (i) preliminary results obtained from a sample, and (ii) current issues related to the design. Results: Our study already shows significant fields of improvement, e.g., the low agreement during the classification. However, the results indicate to interesting points; for example, many of commonly used NFR classes concern system modeling concepts in a way that shows how blurry the borders between functional and NFRs are. Conclusions: We conclude so far that our overall study design seems suitable to obtain the envisioned theory in the long run, but we could also show current issues that are worth discussing within the empirical software engineering community. The main goal of this contribution is not to present and discuss current results only, but to foster discussions on the issues related to the integration of NFRs in seamless modeling in general and, in particular, discussions on open methodological issues.
Many requirements engineering approaches structure and specify requirements based on the notion of modes or system states. The set of all modes is usually considered as the mode model of a system or problem domain. However, it is neither clear how such a mode model can be elicited systematically, nor whether it is realistic to elicit a mode model for a productive system with regard to size and comprehensibility. In this paper, we introduce three elicitation approaches for mode models. We applied the three approaches in an industrial automotive context and assessed the resulting mode models with respect to size, complexity, and differences to each other. Our results show that all elicitation approaches were capable of eliciting modes, which were structured in mode models with 20 to 42 modes. From these results, we conclude that it is possible to elicit manageable mode models for an entire system in a productive context. In our case, the practitioners decided to integrate our model in their feature specification and analysis process.
Context: Seamless model-based development provides integrated chains of models, covering all software engineering phases. Non-functional requirements (NFRs), like reusability, further play a vital role in software and systems engineering, but are often neglected in research and practice. It is still unclear how to integrate NFRs in a seamless model-based development. Goal: Our long-term goal is to develop a theory on the specification of NFRs such that they can be integrated in seamless model-based development. Method: Our overall study design includes a multi-staged procedure to infer an empirically founded theory on specifying NFRs to support seamless modeling. In this short paper, we present the study design and provide a discussion of (i) preliminary results obtained from a sample, and (ii) current issues related to the design. Results: Our study already shows significant fields of improvement, e.g., the low agreement during the classification. However, the results indicate to interesting points; for example, many of commonly used NFR classes concern system modeling concepts in a way that shows how blurry the borders between functional and NFRs are. Conclusions: We conclude so far that our overall study design seems suitable to obtain the envisioned theory in the long run, but we could also show current issues that are worth discussing within the empirical software engineering community. The main goal of this contribution is not to present and discuss current results only, but to foster discussions on the issues related to the integration of NFRs in seamless modeling in general and, in particular, discussions on open methodological issues.
Service oriented architecture (SOA) is an emerging style of software architectures to reuse and integrate existing systems for designing new applications. Each application is designed in an implementation independent manner using two major abstract concepts: services and connections between services. In SOA, non-functional aspects (e.g., security and fault tolerance) of services and connections should be described separately from their functional aspects (i.e., business logic) because different applications use services and connections in different non-functional contexts. This paper proposes a model-driven development (MDD) framework for non-functional aspects in SOA. The proposed MDD framework consists of (1) a Unified Modeling Language (UML) profile to model non-functional aspects in SOA, and (2) an MDD tool that transforms a UML model defined with the proposed profile to application code. Empirical evaluation results show that the proposed MDD framework improves the reusability and maintainability of service-oriented applications by hiding low-level implementation technologies in SOA.
This article presents a framework for characterizing architecturally significant requirements (ASRs) on the basis of an empirical study using grounded theory. The study involved interviews with 90 practitioners with an accumulated 1,448 years of software development experiences in more than 500 organizations of various sizes and domains. These findings could provide researchers with a framework for discussing and conducting further research on ASRs and can inform researchers' development of technologies for dealing with ASRs. The findings also enrich understanding of requirements and architecture interactions, allowing the twin peaks to move from aspiration to reality.
Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.
This paper aims at boosting the level of re-use in design for automotive applica-tions. We see as a key vehicle to achieve this goal the development of rich component models, which are expressive enough to cover the complete development cycle from high-level specifications to design models. We address in particular the need to maintain both functional and non-functional views on components, and the propa-gation of component viewpoints both horizontally as well as vertically.
Even though non-functional requirements (NFRs) are critical in order to provide software of good quality, the literature of NFRs is relatively sparse. We describe how NFRs are treated in two development organizations, an Ericsson application center and the IT department of the Swedish Meteorological and Hydrological Institute. We have interviewed professionals about problems they face and their ideas on how to improve the situation. Both organizations are aware of NFRs and related problems but their main focus is on functional require-ments, primarily because existing methods focus on these. The most tangible problems experienced are that many NFRs remain undiscovered and that NFRs are stated in non-measurable terms. It became clear that the size and structure of the organization require proper distribution of employees' interest, authority and competence of NFRs. We argue that a feasible solution might be to strengthen the position of architectural requirements, which are more likely to emphasize NFRs.
[Context and motivation] In market-driven software development it is crucial, but challenging, to find the right balance among competing quality requirements
(QR). [Problem] In order to identify the unique challenges associated with the selection, trade-off, and management of quality requirements
an interview study is performed. [Results] This paper describes how QR are handled in practice. Data is collected through interviews with five product managers and
five project leaders from five software companies. [Contribution] The contribution of this study is threefold: Firstly, it includes an examination of the interdependencies among quality requirements
perceived as most important by the practitioners. Secondly, it compares the perceptions and priorities of quality requirements
by product management and project management respectively. Thirdly, it characterizes the selection and management of quality
requirements in down-stream development activities.
Model-driven development has become common practice in design of safety-critical real-time systems. High-level modeling constructs help to reduce the overall system complexity apparent to developers. This abstraction caters for fewer implementation errors in the resulting systems. In order to retain correctness of the model down to the software executed on a concrete platform, human faults during implementation must be avoided. This calls for an automatic, unattended deployment process including allocation, scheduling, and platform configuration.
In this paper we introduce the concept of a systems compiler using non-functional requirements (NFR) as a guidance for deployment of real-time systems. The postulated requirements are then used to optimize the allocation decision, i.e., the process of mapping model entities to available computing nodes, as well as the subsequent generation of schedules.
As more and more business-critical systems are based upon services deployed over flexible and dynamic platforms like Service-Oriented
Architecture (SOA), there is an increasing need for such services to meet their non-functional requirements like reliability,
availability, security, etc. To achieve such objectives, these services need to be designed carefully making critical design
decisions early in the development process on an architectural level.
In the current paper, we aim at carrying out a performability analysis of service configurations to estimate the cost of using reliable messaging techniques for services with respect to performance.
Such an analysis is enabled by automated model transformations carried out within the VIATRA2 framework.
The impact of non-functional requirements (NFRs) over software systems has been widely documented. Consequently, cost-effective software production method shall provide means to integrate this type of requirements into the development process. In this vision paper we analyze this assumption over a particular type of software production paradigm: model-driven development (MDD). We report first the current state of MDD approaches with respect to NFRs and remark that, in general, NFRs are not addressed in MDD methods and processes, and we discuss the effects of this situation. Next, we outline a general framework that integrates NFRs into the core of the MDD process and provide a detailed comparison among all the MDD approaches considered. Last, we identify some research issues related to this framework. Preprint
Although Non-Functional Requirements (NFRs) are recognized as very important contributors to the success of software projects, studies to date indicate that there is still no general consensus in the software engineering community regarding the notion of NFRs. This paper presents the result of an extensive and systematic analysis of the extant literature over three NFRs dimensions: (1) definition and terminology; (2) types; and (3) relevant NFRs in various types of systems and application domains. Two different perspectives to consider NFRs are described. A comprehensive catalogue of NFRs types as well as the top five NFRs that are frequently considered are presented. This paper also offers a novel classification of NFRs based on types of systems and application domains. This classification could assist software developers in identifying which NFRs are important in a particular application domain and for specific systems.
Service Oriented Architecture (SOA) is an emerging style of software architectures to reuse and integrate existing systems for designing new applications. Each application is designed in an implementation independent manner using two major abstract concepts: services and connections between services. In SOA, non-functional aspects (e.g., security and fault tolerance) of services and connections should be described separately from their functional aspects (i.e., business logic) because different applications use services and connections in different non-functional contexts. This paper proposes a model-driven development (MDD) framework for non-functional aspects in SOA. The proposed MDD framework consists of (1) a Unified Modeling Language (UML) profile to graphically model non-functional aspects in SOA, and (2) an MDD tool that accepts a UML model defined with the proposed profile and transforms it to application code. This paper also demonstrates how the proposed framework is used in model-driven development of service- oriented applications. Empirical evaluation results show that the proposed MDD framework improves the reusability and maintainability of service-oriented applications by hiding low-level implementation technologies in UML models.
Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.
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.
A comprehensive framework for representing and using nonfunctional requirements during the development process is proposed. The framework consists of five basic components which provide the representation of nonfunctional requirements in terms of interrelated goals. Such goals can be refined through refinement methods and can be evaluated in order to determine the degree to which a set of nonfunctional requirements is supported by a particular design. Evidence for the power of the framework is provided through the study of accuracy and performance requirements for information systems
Service oriented architecture (SOA) is an emerging style of software architectures to reuse and integrate existing systems for designing new applications. Each application is designed in an implementation independent manner using two major abstract concepts: services and connections between services. In SOA, non-functional aspects (e.g., security and fault tolerance) of services and connections should be described separately from their functional aspects (i.e., business logic) because different applications use services and connections in different non-functional contexts. This paper proposes a model-driven development (MDD) framework for non-functional aspects in SOA. The proposed MDD framework consists of (1) a Unified Modeling Language (UML) profile to model non-functional aspects in SOA, and (2) an MDD tool that transforms a UML model defined with the proposed profile to application code. Empirical evaluation results show that the proposed MDD framework improves the reusability and maintainability of service-oriented applications by hiding low-level implementation technologies in SOA.
Requirements engineering (RE) constitutes an important success factor for software and systems development. Requirements documents, as they are worked out before and during the development of (software) systems, tend to get large and complex. Adequate structuring of requirements documents on the basis of a carefully chosen and adequate categorization is crucial to support their systematic elicitation, analysis, (seamless) specification, documentation, and implementation. So far, however, a well‐defined categorization of requirements still constitutes one of the not sufficiently solved challenges in requirements engineering. Structuring large sets of requirements has to be done in combination with adequate choices of levels of abstraction to keep them structured and manageable. Different ways of categorizing and structuring requirements have been suggested in literature. Often, used categories are “functional” versus “nonfunctional” requirements as well as “quality requirements” versus “process constraints” and “product constraints.” Other categorizations are derived from the different categories of stakeholders. However, the characterizations of these categories remain often vague, imprecise, and lack semantic coherence and consistency. In the following, we present a novel approach to categorizing requirements. We base the categorization on a functional and architectural modeling of systems, including both logical (set theoretical) and probabilistic models of behavior. In contrast to traditional categories, in which we distinguish between “functional” and “nonfunctional” requirements, we suggest to use the dichotomies of behavioral versus nonbehavioral properties to further structure behavior into logical versus probabilistic and furthermore into behavioral black box (interface) views versus behavioral glass box views. This provides a precise and more coherent classification of requirements.
Service oriented architecture (SOA) is an emerging style of software architectures to reuse and integrate existing systems for designing new applications. Each application is designed in an implementation independent manner using two major abstract concepts: services and connections between services. In SOA, non-functional aspects (e.g., security and fault tolerance) of services and connections should be described separately from their functional aspects (i.e., business logic) because different applications use services and connections in different non-functional contexts. This paper proposes a model-driven development (MDD) framework for non-functional aspects in SOA. The proposed MDD framework consists of (1) a Unified Modeling Language (UML) profile to model non-functional aspects in SOA, and (2) an MDD tool that transforms a UML model defined with the proposed profile to application code. Empirical evaluation results show that the proposed MDD framework improves the reusability and maintainability of service-oriented applications by hiding low-level implementation technologies in SOA.
Categorizing software requirements based on functional and architectural views in terms of logical and probabilistic behavior models could help mitigate weaknesses in the elicitation and structuring of requirements.
Published software quality models either provide abstract quality attributes or concrete quality assessments. There are no models that seamlessly integrate both aspects. In the project Quamoco, we built a comprehensive approach with the aim to close this gap. For this, we developed in several iterations a meta quality model specifying general concepts, a quality base model covering the most important quality factors and a quality assessment approach. The meta model introduces the new concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects. Product factors have measures and instruments to operationalise quality by measurements from manual inspection and tool analysis. The base model uses the ISO 25010 quality attributes, which we refine by 200 factors and 600 measures for Java and C# systems. We found in several empirical validations that the assessment results fit to the expectations of experts for the corresponding systems. The empirical analyses also showed that several of the correlations are statistically significant and that the maintainability part of the base model has the highest correlation, which fits to the fact that this part is the most comprehensive. Although we still see room for extending and improving the base model, it shows a high correspondence with expert opinions and hence is able to form the basis for repeatable and understandable quality assessments in practice.
Modeling and analyzing the dependability of software systems is a key activity in the development of embedded systems. An important factor of dependability is availability. Current modeling methods that support availability modeling are not based on a rigorous modeling theory. Therefore, when the behavior of the system influences the availability, as it is the case for fault-tolerant systems, the resulting analysis is imprecise or relies on external information. Based on a probabilistic extension of the Focus theory, we present a modeling technique that allows specifiying availability with a clear semantics. This semantics is a transformation of the original behavior to one that includes failures. Our approach enables modeling and verifying availability properties in the same way as system behavior.
Model Driven Development (MDD) refers to the systematic use of models as primary engineering artifacts throughout a software development life cycle. In recently years, MDD has been increasingly employed to guide development with a focus on system modeling, code generation from models and white-box analysis of models. However, compositional system analysis regarding early Non-Functional Aspects/Properties (NFP) remains difficult. In this paper, we critically review the state-of-the-art of MDD in the context of non-functional aspects and shed some lights on the following two questions: 1) How to model Non-Functional Aspect/Property (NFP). The focus is to understand the different subtypes of a non-functional aspects and its compositional and emergent nature. 2) How models can be used for analyzing Non-functional Aspect/Property (NFP). This focuses on the analysis models in the form of reasoning frameworks (both qualitative and quantitative) behind each non-functional aspect.
Due to the rapid increase in the number of available web services, more and more emphasis is put on their reliability, availability, security, etc. These non-functional requirements are frequently captured in service-level agreements between service requesters and providers. In order to meet such non-functional requirements, a service needs to be designed for reliability by making design decisions on a high, architec-tural level. In the paper, we present a model-driven approach for the precise analysis of service configurations with reliable messaging. Start-ing from high-level UML models of service configurations captured by a UML profile dedicated to service design, performability models are de-rived by automated model transformations for the PEPA toolkit in order to assess the cost of fault tolerance techniques in terms of performance.
In recent years, Web Engineering development projects have grown increasingly complex for and critical to the smooth running of organizations. However, recent studies reveal that a high percentage of these projects fail to attain the quality parameters required by stakeholders. The inadequate consideration of requirements management activities together with the absence of attention to the elicitation and evaluation of requirements and metrics related to certain quality attributes which are of special importance in this kind of systems, such as usability, have proved to be some of the main causes of this failure. This paper attempts to reduce some of the quality failures detected in Web Engineering development projects by proposing the consideration and evaluation of quality attributes from early stages of the development process. The presented approach therefore commences with a reinforcement of the requirements related activities in this discipline, which is carried out by using a requirements metamodel. Once these requirements have been identified, the approach focuses on the extension of the conceptual models used by Web Engineering methodologies with the aim of allowing the explicit consideration of usability requirements along with the evaluation of quality metrics during the design of the system. An example of an application illustrating how the approach can be used, along with the automatic support which was developed for it, are also shown.
Non-functional requirements (NFRs), apparently, have different characteristics from their functional counterparts. The ways to develop conceptual models of NFRs, therefore, do not akin to the one for functional requirements (FRs). This paper proposes a method to analyze, specify and modeling non-functional requirements especially the ones that can be manifested as operational/functional features, in the context of translative model-driven development. Our method employs two analysis approaches: NFR framework and uses-cases approach accompanied with our proposed specification technique: scenario-based specification. Results from the scenario-based specification will be used as an insight for developing NFRs conceptual models. In here, we present the way to model a security concern of Voter Tracking System (VTS), a system to mark voters using handheld electronic device.
This paper deals with the structured specification of interface behavior of multifunctional systems, which are systems that offer a variety of functions for different purposes and use cases. It introduces a theory and first concepts of a methodology for the identification, structured modeling, and formalization of functional requirements of multifunctional systems. Service hierarchies specify multifunctional systems in terms of their provided sub-functions called services together with their mutual relationships and dependencies. A service hierarchy describes the functionality of multifunctional systems in a structured way. Each service is specified independently and the specification is added to the service hierarchy. Modes help to specify the feature interactions and by that functional dependencies between the services. The approach is based on the Focus theory for modeling interface behavior and services.
Although the term 'non-functional requirement' has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project. This paper surveys the existing definitions of the term, highlights and discusses the problems with the current definitions, and contributes concepts for overcoming these problems.
Quality characteristics are vital for the success of software systems. To remedy the problems inherent in ad hoc development, a framework has been developed to deal with non-functional requirements (quality requirements or NFRs). Taking the premise that the quality of a product depends on the quality of the process that leads from highlevel NFRs to the product, the framework's objectives are to represent NFR-specific requirements, consider design tradeoffs, relate design decisions to NFRs, justify the decisions, and assist defect detection. The purpose of this paper is to give an initial evaluation of the extent to which the framework's objectives are met. Three small portions of information systems were studied by the authors using the framework. The framework and empirical studies are evaluated herein, both from the viewpoint of domain experts who have reviewed the framework and studies, and ourselves as framework developers and users. The systems studied have a variety of characteri...
Code complete. Pearson Education
- S Mcconnell
S. McConnell. Code complete. Pearson Education, 2004.
Quality requirements in practice: An interview study in requirements engineering for embedded systems. InRequirements Engineering: Foundation for Software Quality, volume 5512 ofLecture Notes in Computer Science
- R B Svensson
- T Gorschek
On non-functional requirements in software engineering
- L Chung
- J C S Do Prado Leite
L. Chung and J. C. S. do Prado Leite. On
non-functional requirements in software engineering. In
Conceptual modeling: Foundations and applications,
volume 5600 of Lecture Notes in Computer Science.
Springer, 2009.
Boosting re-use of embedded automotive applications through rich components
- W Damm
- A Votintseva
- A Metzner
- B Josko
- T Peikenkamp
- E Böde
W. Damm, A. Votintseva, A. Metzner, B. Josko,
T. Peikenkamp, and E. Böde. Boosting re-use of
embedded automotive applications through rich
components. In Proc. of the Workshop on Foundations
of Interface Technologies (FIT), 2005.
A rigorous approach to availability modeling
- M Junker
- P Neubeck
M. Junker and P. Neubeck. A rigorous approach to
availability modeling. In Proc. of the 4th International
Workshop on Modeling in Software Engineering (MiSE),
2012.
Quality requirements in practice: An interview study in requirements engineering for embedded systems
- R B Svensson
- T Gorschek
- B Regnell
R. B. Svensson, T. Gorschek, and B. Regnell. Quality
requirements in practice: An interview study in
requirements engineering for embedded systems. In
Requirements Engineering: Foundation for Software
Quality, volume 5512 of Lecture Notes in Computer
Science. Springer, 2009.
The quamoco product quality modelling and assessment approach
- S Wagner
- K Lochmann
- L Heinemann
- M Kläs
- A Trendowicz
- R Plösch
- A Seidl
- A Goeb
- J Streit
S. Wagner, K. Lochmann, L. Heinemann, M. Kläs,
A. Trendowicz, R. Plösch, A. Seidl, A. Goeb, and
J. Streit. The quamoco product quality modelling and
assessment approach. In Proc. of the 34th International
Conference on Software Engineering (ICSE), 2012.