Proposed Framework to Manage Non-Functional Requirements in Agile

Agile Software Development (ASD) is a type of iterated software development that strives to maximize productivity, effectiveness, and quick delivery through the minimization of documents and needless procedures within constrained timeframes. Agile software development has a number of advantages. There are still some difficulties. For instance, during the development lifecycle, non-functional requirements (NFRs) are disregarded and not given first-class artifacts. This results in several issues, including customer dissatisfaction and a great deal of rework, which impacts time and cost. In this paper, a proposed framework for handling non-functional requirements in Agile is explained. The framework supports the several primary activities of requirements engineering including requirements elicitation, analysis, documentation, and validation. In addition, the framework handles non-functional recommendations. Results of the suggested solution validation showed that it could address the problems with non-functional requirements in Agile.


I. INTRODUCTION
The term ''Agile'' denotes flexibility, adaptation, and agility [1]. Agile software development entails the division of a single large software project into numerous independently executable sub-projects. The development team begins by focusing on the most important features that users have chosen, other features chosen in successive iterations, and so on. Due to its advantages, such as increased team productivity, motivation, and software quality, Agile software development has grown in popularity over the past ten years [1]. However, there are still some challenges and issues in Agile Software Development [2]. One of the main challenges is not focusing on non-functional requirements [2], [3], [4], [5], [6], [7], [8], [9]. Our research problem in this challenge is focused on recommendation, elicitation, analysis, documentation, and validation of nonfunctional requirements in Agile. Therefore, this paper proposes a framework to address this challenge. This paper is organized as follows: Section one provides an introduction, Section two presents the research methodology, Section three presents the Agile Software Development Background, The associate editor coordinating the review of this manuscript and approving it for publication was Aasia Khanum . Section four presents a proposed framework, Section five presents validation and results, and finally, Section six outlines the conclusion of this paper.

II. RESEARCH METHODOLOGY
To analyze key works now available in the non-functional requirements in Agile, this research report carried out a critical literature review of this area. This research was conducted in four phases. The existing related articles were first screened using popular search engines such as IEEE Xplore Digital Library, Google Scholar, ACM, Springer, Science Direct, and Wiley Online Library. A keyword-based search on the terms was used throughout the screening process using different combinations of the following terms: ''non-functional requirement'', ''scrum'', Agile'', ''quality requirement'', ''requirements engineering in Agile'', ''conflict'', ''requirements elicitation'', and ''recommendation''. The second phase concentrated on selecting the important key works that would be examined and analyzed by filtering the collected papers. All pertinent papers were divided into categories based on their origin, whether they were theoretical or practical, and where they were published, whether in journals or conference proceedings. The third phase involved developing an analysis of the filtered works to identify their advantages and disadvantages as regards Agile solutions for focusing on non-functional requirements. Finally, the result from the analytical study had been reached by the fourth phase.

III. AGILE SOFTWARE DEVELOPMENT BACKGROUND
Agile Software Development let the development team first concentrates on the most important features that people have asked for. The team uses an incremental iterative development approach for all of the chosen capabilities, with each iteration producing a working system. The focus of the development team is on adapting quickly to changing requirements. The development team promptly modifies the plan in response to requests for changes to the requirements. Seventeen software developers got together in 2001 to talk about a quick and efficient development process [10]. They published a document called ''Manifesto for Agile Software Development''. The Agile manifesto contains twelve principles and four values which drew on their collective experience in software development and recognized the need to move away from rigid process models like Waterfall. The four values are [10]: 1) Individuals and interactions over processes and tools. 2) Working software over comprehensive documentation.
3) Customer collaboration over contract negotiation. 4) Responding to a change over following a plan. The twelve principles are [10]: 1) The highest priority is to satisfy the customer through the early and continuous delivery of valuable software. 2) Welcome changing requirements, even late the development. Agile processes harness change for the customer's competitive advantage. 3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale. 4) Business people and developers must work together daily throughout the project. 5) Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 6) The most efficient and effective method by which to convey information to and within a development team is face-to-face conversation. 7) Working software is the primary measure of progress. 8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9) Paying continuous attention to technical excellence and good design enhances agility. 10) Simplicity -the art of maximizing the amount of work not done-is essential. 11) The best architectures, requirements, and designs emerge from selforganizing teams. 12) At regular intervals, the team should reflect on how to become more effective, then tune and adjust its behavior accordingly.
The above principles and values aim to accomplish two main objectives. The first objective is increasing public knowledge of Agile methodologies is the primary goal. The second objective is to help project teams decide if they are going to use an Agile process or not. This manifesto defines the philosophy behind Agile techniques, together with all of its guiding principles and values, and should ideally be included in all of the Agile methods' practices [11]. These principles fall short of taking into account the significance of the nonfunctional requirements (NFRs) [12]. As shown in Table 1, there are 16 different challenges in Agile requirements engineering discussed by 15 different research papers [2]. The challenge labeled with 'Y' means this challenge is mentioned in this given paper. The challenge that is labeled with '−' means that this challenge is not mentioned in the given paper. Neglecting non-functional requirements in Agile along with minimal documentation are the top two challenges in Agile requirements engineering [2], as these two challenges are stated in 14 out of the 15 research papers. Our focus is on the non-functional requirements in Agile.
There are related solutions that did focus on non-functional requirements in Agile software development. As shown in Table 2, it consists of 4 methodologies and 3 methods that focus on non-functional requirements in the Agile software development [2]. Table 3 consists of 3 tools, 2 frameworks, 1 metric, 1 study, 1 process, 1 guideline, and 1 new artifact that focuses on non-functional requirements in the Agile software development [2]. Each one of those solutions tackled the challenge of non-functional requirements in Agile from different perspectives. As shown in Tables 2 and 3, the keywords ''yes'' and ''no'' indicate whether or not the item applies to the given solution or research article, respectively. As a summary of both tables, there is no single solution that focuses on recommendation, elicitation, analysis, documentation, and validation of non-functional requirements in Agile.

IV. MANoR: A PROPOSED FRAMEWORK
In any given software, there are two types of requirements: functional and non-functional requirements. This also applies to any software developed using an Agile software development approach. One of the foci in ASD is to deliver working functional software to the client as soon as possible. Therefore, the focus is on the functional requirements and Agile software development treats them as a first-class object. So, there is less focus on nonfunctional requirements. One of the problems of neglecting requirements, in general, is rework, where extra work is needed to fix problems in software due to poorly understood requirements [43]. The rework can cost from 40% to 50% of the total efforts of the software project [43]. It is found that a failure range of 60% or higher of software products when not considering non-functional requirements while development [9], [44], [45], [30], [46], [29], [36]. There are many different points to be considered while working on non-functional requirements, such as how are non-functional requirements going to be elicited, documented, and validated.  Another point is whether there is a possibility to recommend certain non-functional requirements to the client. What if there is a conflict between non-functional requirements? This is where the proposed framework comes in. The proposed framework is called MANoR which stands for ''Managing Agile Non-functional Requirements.'' The framework assists in resolving the above issues, regarding the non-functional requirements. The framework consists of different stages, and components; it is supported by a tool with the same name as the framework, as shown in Figure 1. The tool is a web application developed using ASP.NET MVC framework and the tool is available on 1 and credentials are available on. 2 The tool includes 14 different main features that 1 http://manor-app.org/ 2 username: Manor_guest, password: Mg!AuNeOs2Rt consist of 48 different functions. The tool handles both functional requirements and non-functional requirements in Agile, more specifically, Scrum. Regarding the framework, there are two main stages and five main components. The stages are pre-analysis and post-analysis. The components are non-functional requirements recommendation, elicitation, analysis, documentation, and validation. The following are the main steps of the framework: 1) MANoR recommends specific non-functional requirements for the software being developed based on specific inputs. The recommendation will be based on two main items. The first item is historical data (previous projects). The second item is predefined data gathered from research and entered into the MANoR tool. Predefined data includes characteristics of the software such as: is the software being developed is a web application, a desktop application, or a mobile application. In addition, data includes the business domain for which the software is being developed. 2) Non-functional requirements elicitation session occurs between the product owner/business analyst and key stakeholders from the client side in order to determine non-functional requirements. The objective of this session is to explain the meaning of the concept of nonfunctional requirements to the stakeholders. In addition, a list of recommended non-functional requirements can be provided by MANoR based on the characteristics of the software that will be developed.
3) The next step is to find conflicts in non-functional requirements. MANoR will assist in finding those conflicts. 4) Functional and non-functional requirements are documented in the product backlog by the product owner in MANoR. The documentation is written as user stories and MANoR provides different types of user stories (non-functional and functional). 5) Non-functional requirements will be validated by the client before starting the development. 6) Once step 5 is done, the normal process of Scrum will continue. There are five main components of the framework: nonfunctional requirements recommendation, elicitation, analysis, documentation, and validation. Each of those components is explained further in the below sections.

A. MANoR: STAGE I
In this section, we discuss the first two components of the framework. The first component is the requirements recommendation which is discussed in section I. The second component is requirements elicitation which is discussed in section II.

1) REQUIREMENTS RECOMMENDATION
Research has shown historical data to be useful in determining a future event based on past data [30]. Therefore, the proposed solution is to recommend non-functional requirements based on historical data in ''MANoR''. In addition, a recommendation can be made based on data found in table 4 [47] and table 5 [47], [48].
Eight distinct application domains were taken into consideration, as indicated in Table 4, including transportation, banking and finance, telecommunication services, education, medical/health care, energy resources, insurance, government, and military [47]. In addition, the table shows that usability and performance are considered in seven domains, security is considered in six domains, and reliability is considered in four domains.
As shown in table 5 [47], [48], there are five different types of systems: real-time systems, process-controlled systems, safety-critical systems, information systems, and web systems [47], [48]. In addition, it shows that security, performance, and usability are considered in all five types of systems, and reliability is considered in four types of systems.
Based on the above information, our proposed solution recommends non-functional based on the following: 1) An application domain (predefined data from table 4)  Based on table 4, the data is entered in the ''MANoR'' which helps users with relevant non-functional requirements based on various application domains. This becomes extremely helpful when there is no historical data available. 2) Type of systems (predefined data from table 5) The relevant data from table 5 is entered into ''MANoR'' which assists the users with relevant types of nonfunctional requirements based on different types of systems. This data includes relevant non-functional requirements based on the type of system. For example, communicativeness, dependability, reliability, performance, security, usability, integrity, and safety are relevant non-functional requirements for safety-critical systems.

3) Historical data
This option allows the tool to use the previous projects that were entered in ''MANoR''. As more projects are entered into the tool, it can provide better recommendations for upcoming projects. However, for the first few projects being entered into the tool, recommendations can be made through the application domain or the type of systems. Using the historical data inside the MANoR tool, it recommends non-functional requirement(s) based on a specific domain and a specific type of software being developed. The recommendation is based on how many non-functional requirements the end user wants to see. For example, if the client wants to know the top two non-functional that were used in previous projects with the same type of software and the same type of business domain, then the tool provides the results by showing two non-functional requirements based on the historical data. The end user can request to view the top one or two or three or four or five or even ten non-functional requirements that were used previously in the same type of software and the same type of business domain. Another example: let's assume that we have five different projects inside the tool that are involved in the academic domain and all of them are web applications, and currently we will work on the sixth project of the same type of software and the same type of domain. In addition, all five projects had one nonfunctional in common which is performance and four out of the five projects had security as a non-functional requirement. Then the end user requested to view the top two non-functional requirements that were mostly used in this domain and type of system. Therefore, the tool will display performance with a percentage of 100% and security with a percentage of 80%. The percentage is calculated within the tool by knowing that five projects out of a total of five projects did use performance as a non-functional requirement and also four projects out of five projects did use security as a non-functional requirement.
53998 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.    To have better and clear recommendations, the tool uses the above information and provides three views of recommendation: 1) The first view is a recommendation from the type of domain.
2) The second view is a recommendation from the type of system. 3) The third view is historical data from previous projects in the tool.

2) REQUIREMENTS ELICITATION
One of the key activities in requirement engineering is the elicitation of requirements. It is the foundation for whether the project will continue successfully or not. Early in the project's lifecycle, non-functional requirements should be identified to help with project estimations of effort, size, and cost. This will help to reduce rework. [8]. Non-functional requirements can be identified in the project life cycle in one of the following stages [3]: 1) During sprint zero, resulting in the definition of a general software architecture. 2) During the initial stages of development.
3) During the initial iteration of the project, then refined to more details in later iterations. 4) During each iteration. 5) In the late stages of the project which causes a lot of re-work because non-functional requirements were not considered in the initial stages In our proposed solution, the non-functional requirements are identified during the initial iteration of the project and then can be refined into more details later if needed. The following are the steps for non-functional requirements elicitation in our proposed solution: 1) The first step is where the product owner/business analyst accesses MANoR to receive the recommendations of non-functional requirements based on previous projects and pre-defined data which are based on research.
2) The second step is that the product owner/business analyst conducts a non-functional requirements session with the client. The following are the details of the session: (a) Description of the session: it is one session with a maximum duration of two hours to discuss the non-functional requirements of the software being developed. (i) List of non-functional requirements given by the client and to be further analyzed (f) People involved in the session: (i) Technical side: the product owner/business analyst will attend as he or she is responsible for the product backlog which includes non-functional requirements (ii) Client-side: key stakeholders of the system.

B. MANoR: STAGE II
In this section, we discuss the next three components of the framework. The first component of Stage II is the requirements analysis which is discussed in section I. The second component is requirements documentation which is discussed in section II. The third component is requirements validation which is discussed in section III.

1) REQUIREMENT ANALYSIS
The main task is to determine whether the elicited requirement is clear, complete, unambiguous, and not contradicting. Conflicts mean interference or inconsistency between requirements (functional or non-functional requirements) [49]. Conflicts are resolved in this activity by negotiation with stakeholders. In our proposed solution, the focus is on the non-functional requirements. Conflicting non-functional requirements refer to situations in which meeting one requirement may have an impact on another [50]. For example, a specific module requires an extra security mechanism which increases the complexity of the module and therefore increases the difficulty of the user interaction [50]. This would cause a conflict between security and usability. Another example is between security and performance, where the user wants the specific functionality to be finished in a minimal time and in addition, specifies a high-security protocol [49]. Conflicts between requirements can occur for a variety of reasons, for example, in case there is a huge quantity of requirements, changes that may occur during software development, software with different stakeholders with different requirements or interests, or by adding a new stakeholder in the project [49]. Given how many individuals are engaged in software development, conflicting requirements are one of the main causes of software failure [51]. Between 40% and 60% of requirements conflict, according to a study of two-year multiple-project analysis [52], [53], [54]. Among those requirements are non-functional requirements that involve the greatest conflict which nearly takes half of the total requirements' conflicts [52], [53]. Figure 2 shows the conflict matrix between non-functional requirements where the relationship of conflict among non-functional requirements is presented in four ways [55], [50]: 1) Absolute conflict: labeled as ''X'' which means there is a conflict between two NFRs. 2) Relative conflict: labeled as ''*'' which means they are not always in conflict and it depends on the cases, therefore sometimes they are in conflict and at other times they are not. 3) Never in conflict: labeled as ''0'' which means there is no inherent conflict between the two NFRs. 4) Unknown conflict is labeled with blank space which means there is no information available in the literature about those sets of non-functional requirements. Figure 2 is implemented in MANoR which provides details on which non-functional requirements have conflicts with each other. This helps the users of the tools during the analysis activity.
In general, two main factors can cause conflicts between non-functional requirements [53]: 1) The different needs and perspectives of different stakeholders.
54000 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.  2) The inherent contradiction between non-functional requirements is a result of specific characteristics of some non-functional requirements. There are three main steps in managing conflicts between non-functional requirements [53]: 1) Conflict identification: the purpose is to identify the conflicts early during the software development life cycle 2) Conflict analysis: the purpose is to evaluate and investigate potential conflict 3) Conflict resolution: the purpose is to resolve the potential conflict Given the above information, the tool helps the product owner to identify the conflicts which is step one. The tool provides the non-functional requirement conflict matrix to the end user. Then in step two, the product owner evaluates the conflict and then gets back to the client to resolve this conflict which is step three.

2) REQUIREMENTS DOCUMENTATION
One of the biggest challenges is the minimal documentation. Non-functional requirements documentation is part of that challenge as it should be documented along with the functional requirements. The question is how to document non-functional requirements in Agile software development. Is it better to document it as a separate user story or as a user story parameter? In our proposed solution, a separate user story will be used for each non-functional requirement. Separate user stories for non-functional requirements would be better in the product backlog, instead of having a user story with a non-functional parameter [56]. This will help because most non-functional requirements can be split into different sprints [56]. It is better to create separate user stories for the non-functional requirements in the product backlog, instead of having non-functional requirement parameters in the user story [56]. There are different views for the user stories. The following list explains the different views of the user stories in our proposed solution which is implemented in the tool developed specifically for this solution: 1) Non-functional user story vs. functional user story: The user story can contain functional or non-functional requirements in our proposed solution. The tool allows the user to select the type of requirement and based on the selection, the tool will provide proper fields. An example of a non-functional requirement user story in MANoR is ''performance'', its description is ''the response time shall be one second'', related to the field ''Registration Module''.   2) Standard user story vs. custom user story: A standard user story is the normal user story that is used in Agile. A normal user story is written as the following template: As a <type of user> I want <specific task> so that <achieve some value/goals>. On the other hand, the custom user story is the traditional way of writing any business requirement. Basically, it is one sentence without applying any templates or rules. For example, students can register courses online. The tool allows the user to select how the user wants to write the user story: standard or custom. 3) System vs. module vs. epic vs. functional requirement: In our proposed solution, any non-functional requirement is related either to a system, module, epic, or functional requirement. This means from early development the analyst will know which nonfunctional requirements affect the entire system. Or that it affects a specific module or an epic or if it is related to a very specific functional requirement written in the form of a user story.

3) REQUIREMENTS VALIDATION
This part of the proposed solution is where validation of the non-functional requirements is done. In other words, making sure that both the client and the technical team are on the same page regarding the non-functional requirements for the given software. The technical team confirms the non-functional requirements with the client. Once the validation is done with the client, the normal process of Scrum will take over.

V. VALIDATION & RESULTS
The framework was validated using an evaluation form.  department were involved in evaluating the framework for each department. Involving different departments is meant to provide different perspectives from different roles in software development.

3) The academic team includes eight different instructors
working in three different universities as shown in table 6. Those instructors are working in the Software Engineering Department of those universities. The reason for selecting this department is that Agile development is one of the major research areas in those universities. Figure 3 shows the technical experience in the Agile development process of the people who filled in the evaluation form by showing the number of Agile projects they worked in. As shown in Figure 3, there are 63% of the people did work in between one and five Agile projects, in another word, this means 33 out of 52 people. In addition, 17% of people did work between six and ten Agile projects, in another word, this means 8 out of 52 people. Figure 4 shows two important questions regarding the non-functional requirements. The first question references the high impact of non-functional requirements in software projects. The answers are positive as 34 people strongly agree and 17 people do agree that non-functional requirements have a high impact on the success of the projects. In other words, 51 out of 52 people think non-functional requirements are important. The second question references the reality of applying non-functional requirements in their software projects. As there are 17 different people who strongly agree and 20 different people who agree. This means a total of 37 out of 49 people do consider non-functional requirements in their projects. Comparing the answers to the last two questions, 51 people believe non-functional requirements are important, however, only 37 of those 52 do consider nonfunctional requirements in their projects. Figure 5 focuses on the framework ''MANoR'' by showing six different questions answered by both teams. Each question is a multiple-choice Likert-scale question. The purpose of those questions is to evaluate the framework and see whether it helps in the issues regarding the non-functional requirements or not. The first question targets complexity and 45 people agree that it is simple which is an important point because one of the principles of Agile is simplicity. The second question targets the understandability of the framework and it shows that 50 people find the framework easy to understand. The third and fourth questions target the realism of the framework, and whether people would use it in future projects, respectively. The answers show that 49 people agree that the framework is practical and realistic and 47 people agree that it can be used in their future projects. The fifth question targets whether the framework helps in the issues related to non-functional requirements such as the elicitation, recommendation, analysis, documentation, and validation of non-functional requirements. In this question, a total of 51 agree that the framework helps in those issues which also shows a positive impact of the framework. The sixth question targets the idea of non-functional requirement conflicts. 42 people agree that uncovering the conflicts early on in the project helps in reducing the risk of having residual non-functional requirements conflicts.
The proposed framework was based on the principles and values of the Agile Manifesto and therefore offers a flexible way to handle non-functional requirements in Agile. The above statistics and results show the positive impact of the framework on dealing with non-functional requirements in Agile.

VI. CONCLUSION & FUTURE WORKS
Ignoring non-functional requirements in Agile Software Development greatly impacts the software's success. Therefore, there is a need to focus on the problems of ignoring non-functional requirements in Agile Software Development and accordingly provide a lightweight solution while keeping the principles and values of Agile Software Development intact. The proposed framework ''MANoR'' focuses on non-functional requirements in the activities of elicitation, recommendation, analysis, documentation, and validation in Agile Software Development. Finally, the proposed framework was validated by technical experts and an academic team to prove its objective of focusing on non-functional requirements in Agile without breaking the principles and values of Agile. Future work will include the validation of the framework through real-life case studies. By implementing such a framework, companies will focus on the importance and impact of non-functional requirements in Agile projects. Therefore, it is expected to improve the quality of the resultant software and reduce the risk of profit loss, effort rework, or even project failure.