Non-Functional Requirements Elicitation Guideline for Agile Methods

One of the essential activities in software development is elicitation of requirement. Majority of the studies has pointed out that less attention is given to the NonFunctional Requirement (NFR). The negligence of NFR elicitation is due to lack of knowledge of the user and developer about NFR. Our study presents elicitation guidelines for NFRs in agile methods. This guideline will helps developers as well as users in agile methods. A case study is conducted on the group of master students for eliciting NFR with the help of elicitation guidelines. In addition, the initial results were obtained by extracting NFRs from eProcurement document that carries requirements of major European Union projects. The result of the case study is positive and encouraging for the new developers and users having less awareness about NFRs. Furthermore, the study describes the role of cloud computing in agile methods, especially in elicitation activity

Capturing, Eliciting, and Prioritizing (CEP) Non-Functional Requirements Metadata during the Early Stages of Agile Software Development

Agile software engineering has been a popular methodology to develop software rapidly and efficiently. However, the Agile methodology often favors Functional Requirements (FRs) due to the nature of agile software development, and strongly neglects Non-Functional Requirements (NFRs). Neglecting NFRs has negative impacts on software products that have resulted in poor quality and higher cost to fix problems in later stages of software development. This research developed the CEP “Capture Elicit Prioritize” methodology to effectively gather NFRs metadata from software requirement artifacts such as documents and images. Artifact included the Optical Character Recognition (OCR) artifact which gathered metadata from images. The other artifacts included: Database Artifact, NFR Locator Plus, NFR Priority Artifact, and Visualization Artifact. The NFRs metadata gathered reduced false positives to include NFRs in the early stages of software requirements gathering along with FRs. Furthermore, NFRs were prioritized using existing FRs methodologies which are important to stakeholders as well as software engineers in delivering quality software. This research built on prior studies by specifically focusing on NFRs during the early stages of agile software development. Validation of the CEP methodology was accomplished by using the 26 requirements of the European Union (EU) eProcurement System. The NORMAP methodology was used as a baseline. In addition, the NERV methodology baseline results were used for comparison. The research results show that the CEP methodology successfully identified NFRs in 56 out of 57 requirement sentences that contained NFRs compared to 50 of the baseline and 55 of the NERV methodology. The results showed that the CEP methodology was successful in eliciting 98.24% of the baseline compared to the NORMAP methodology of 87.71%. This represents an improvement of 10.53% compared to the baseline results. of The NERV methodology result was 96.49% which represents an improvement of 1.75% for CEP. The CEP methodology successfully elicited 86 out of 88 NFR compared to the baseline NORMAP methodology of 75 and NERV methodology of 82. The NFR count elicitation success for the CEP methodology was 97.73 % compared to NORMAP methodology of 85.24 %which is an improvement of 12.49%. Comparison to the NERV methodology of 93.18%, CEP has an improvement of 4.55%. CEP methodology utilized the associated NFR Metadata (NFRM)/Figures/images and linked them to the related requirements to improve over the NORMAP and NERV methodologies. There were 29 baseline NFRs that were found in the associated Figures/images (NFRM) and 129 NFRs were both in the requirement sentence and the associated Figure/images (NFRM). Another goal of this study was to improve the prioritization of NFRs compared to prior studies. This research provided effective techniques to prioritize NFRs during the early stages of agile software development and the impacts that NFRs have on the software development process. The CEP methodology effectively prioritized NFRs by utilizing the αβγ-framework in a similarly way to FRs. The sub-process of the αβγ-framework was modified in a way that provided a very attractive feature to agile team members. Modification allowed the replacement of parts of the αβγ-framework to suit the team’s specific needs in prioritizing NFRs. The top five requirements based on NFR prioritization were the following: 12.3, 24.5, 15.3, 7.5, and 7.1. The prioritization of NFRs fit the agile software development cycle and allows agile developers and members to plan accordingly to accommodate time and budget constraints

Categorizing Non-Functional Requirements Using a Hierarchy in UML.

Non-functional requirements (NFRs) are a subset of requirements, the means by which software system developers and clients communicate about the functionality of the system to be built. This paper has three main parts: first, an overview of how non-functional requirements relate to software engineering is given, along with a survey of NFRs in the software engineering literature. Second, a collection of 161 NFRs is diagrammed using the Unified Modelling Language, forming a tool with which developers may more easily identify and write additional NFRs. Third, a lesson plan is presented, a learning module intended for an undergraduate software engineering curriculum. The results of presenting this learning module to a class in Spring, 2003 is presented

Exploring issues in agile requirements engineering in the South African industry

The agile manifesto has certainly changed the way software is produced in the Information Communications Technology (ICT) industry. However, many persistent challenges cripple agile software development. One challenge is that the constant change in technology makes the requirements hard to implement. Another is that issues of the agile requirements engineering (ARE) process are abundant and pervasive throughout software projects. The aim of this study is to determine common issues in agile requirements engineering in the South African software industry and identify tools and frameworks to mitigate risks emanating from such problems. This includes finding out how much value software practitioners put in the agile principles. This study was essentially quantitative, based on a cross-sectional survey. Self-administered questionnaires were used to collect required data which was then subjected to exploratory data analysis using SPSS (Statistical Package for the Social Sciences), a tool for statistical analysis. The results show that software practitioners have a strong penchant for principles of the Agile Manifesto. Major issues in agile requirements engineering include lack of proper validation tools and techniques, scope problems, lack of proper documentation, issues of prioritisation, as well as unavailability of customer representative. A detailed baseline of issues in agile requirements engineering was created along with a set of recommended tools and techniques used in the software industry. As for the recommendation, it is suggested that companies invest more on validation tools and techniques and consider non-functional requirements integration during software development.School of ComputingM. Sc. (Computing

Framework for examination of software quality characteristics in conflict: A security and usability exemplar

© 2020, © 2020 The Author(s). This open access article is distributed under a Creative Commons Attribution (CC-BY) 4.0 license. Standards and best practices for software quality guide on handling each quality characteristic individually, but not when two or more characteristics come into conflict such as security and usability. The objectives of this paper are twofold: (a) to argue on the importance of handling the conflicts between quality characteristics in general; (b) to formulate a framework for conflict examination of the software quality characteristics, we do so while considering the specific case of security and usability. In line with the objectives, a framework called Pattern-oriented Design Framework (PoDF) was formulated. The PoDF provides a mechanism for identification of the conflicts, modeling the conflicts to illuminate the reason for their occurrence, and eliciting the suitable trade-offs between the conflicting characteristics. The suitable trade-offs are thus documented as design patterns. The patterns can assist developers and designers in handling the conflicts in other but similar context of use. To validate and instantiate the PoDF, two studies were conducted. Usable security patterns discovered as a result of the studies are also presented in the paper

Requirements reuse and requirement patterns: a state of the practice survey

Context. Requirements engineering is a discipline with numerous challenges to overcome. One of these challenges is the implementation of requirements reuse approaches. Although several theoretical proposals exist, little is known about the practices that are currently adopted in industry. Objective. Our goal is to contribute to the investigation of the state of the practice in the reuse of requirements, eliciting current practices from practitioners, and their opinions whenever appropriate. Besides reuse in general, we focus on requirement patterns as a particular strategy to reuse. Method. We conducted an exploratory survey based on an online questionnaire. We received 71 responses from requirements engineers with industrial experience in the field, which were analyzed in order to derive observations. Results. Although we found that a high majority of respondents declared some level of reuse in their projects (in particular, non-functional requirements were identified as the most similar and recurrent among projects), it is true that only a minority of them declared such reuse as a regular practice. Larger IT organizations and IT organizations with well-established software processes and methods present higher levels of reuse. Ignorance of reuse techniques and processes is the main reason preventing wider adoption. From the different existing reuse techniques, the simplest ones based on textual copy and subsequent tailoring of former requirements are the most adopted techniques. However, participants who apply reuse more often tend to use more elaborate techniques. Opinions of respondents about the use of requirement patterns show that they can be expected to mitigate problems related to the quality of the resulting requirements, such as lack of uniformity, inconsistency, or ambiguity. The main reasons behind the lack of adoption of requirement patterns by practitioners (in spite of the increasing research approaches proposed in the community) are related to the lack of a well-defined reuse method and involvement of requirement engineers.Peer ReviewedPostprint (author's final draft

GOREWEB framework for goal oriented requirements engineering of web applications

In this paper, we propose a framework for modeling goal driven requirements of web applications. Web engineers mostly focus on design aspects only overlooking the real goals and expectations of the user. Goal oriented Requirement Engineering is a popular approach for Information system development but has not been explored much for Web applications. However, in today's times Web is dominating in every business making it imperative that its requirements are analyzed carefully and in profundity. Goal driven requirements analysis helps in capturing stakeholders' goals very finely, by choosing between alternatives and resolving conflicts. Detailed classification of both functional and non-functional requirements specific to web applications is discussed in the presented work. A framework, GOREWEB (Goal oriented Requirements Engineering for Web Applications) is proposed for analyzing goals and translating them into functional and non-functional web requirements