Issues In Non Functional Requirements Elicitation Information Technology Essay

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

Keywords: Requirement Engineering, Non-Functional Requirements, Literature Survey, Approaches, Techniques, Issues.

1. Introduction

The success of a system generally depends upon the degree of satisfaction it provides to its users. Fulfillment of requirements is one the measure towards this satisfaction. The common industry practice is to primarily focus on functional requirements and other important concepts such as non-functional requirements are not considered till the design and development. This approach leaves a serious flaw in the resultant system because many stakeholders’ preferences and their specifications are not fully addressed.

Non-functional requirements (NFRs) is an important concept in requirement engineering which plays an important role in the success of a system [2]. Inconsistency or ambiguity in NFR often results in the failure of the system such as the famous example of London Ambulance System [1]. Recent research in requirement engineering has focused on the necessity of the software that meets the user requirements but also copes with non-functional requirements such as reliability, security, performance as well as others [3]. These requirements should be treated from the beginning of software development process, throughout the whole life cycle [3] [4].

From the perspective of existing literature, most of the work, focused on dealing NFR, is still partial and incomplete. Incorporating NFR into different phases of software development process is still a difficult task. Researchers face numerous challenges including great diversity of NFRs, formal specification of requirements, NFRs subjective nature, incorporating these requirements into models used for specifying functional requirements and resolving conflicts among NFRs [2]. Most of the work is derived from Chung’s NFR framework [4], but it lacks the integration of NFR into conceptual modes [5].

This research work, on the basis of a literature survey, identifies some key challenges and issues while elicitation and analysis of non-functional requirements. It also find-outs the approaches and methods that are suggested in literature to deal with these issues. Our literature survey is based on the following two research questions:

Research Question 1: What are the issues, problems and challenges while elicitation of Non-Functional Requirements ?

Research Question 2: What are the techniques / approaches for the elicitation of NFRs?

Although some quality work has been done for construction of NFR elicitation tools such as the Language Extended Lexicon (LEL) [6], but it was not our primary focus, so such work was not included in this literature survey.

This paper is organized as follows. Section 2 briefly reviews some of the literature and background material. Section 3 synthesizes the results that were extracted from the existing literature based on our research questions. To conclude, we summarize our research and discuss various issues left open in the existing research.

2. Literature Survey

The current industrial practice is to specify only functional requirements at the initial of software development process [2]. Non-functional requirements are not even considered as second class requirements; they are normally evaluated in the final product. As a result, initial levels of software development (elicitation and analysis) may not reflect the NFRs properly and thus may result in a product that does not fully address the requirements of a user [2].

In order to resolve this issue, different researchers have created a general awareness that non-functional requirements should be tied up with functional requirements [2] [6] [7]. It has been concluded to consider / elicit NFRs along with other requirements right from the beginning of requirement elicitation and analysis. Different approaches have been proposed ranging from unstructured and informal text to highly formal mathematical approaches [2]. These approaches generally depend on the goals of the project and available resources. In general, these approaches can be classified in the following categories:

Goal driven approaches (possibly along with use cases) with the use of catalogues/ Library of reusable goals;

Aspect oriented / View point oriented approaches;

Templates and Patterns based approaches;

Use cases and misuse cases based approaches; and

Other approaches.

2.1. Goal Driven Approaches / Library of reusable goals

The NFR Framework is the most popular work to model and analyze non-functional requirements. It treats NFRs as soft goals (goals that are hard to express) to be addressed during the development process [4]. The NFR framework consists of five major components: softgoals, contributions, methods, correlation rules, evaluation procedure.

The Framework makes the relationships between the NFRs and intended decisions explicit. This approach helps understanding the impact of multiple design decision positively or negatively. This widely accepted framework has been researched and reused by many authors.

Figure 1 shows the softgoal interdependcy graph proposed by chung. In using the NFR Framework, one constructs an initial softgoal interdependency graph by identifying the main non-functional requirements that the particular system under development should meet. In the credit card system example (as given in the figure), these may include security of account information and good performance in the storing and updating of that information. These non-functional requirements are then treated as softgoals, to be achieved, i.e., they are goals which need to be clarified, disambiguated, prioritized, elaborated upon etc. Next step is the decomposition of requirements that are quite broad and abstract and assignment priorities to them. At some point, when the non-functional requirements have been sufficiently refined, one will able to identify possible development techniques for achieving these NFRs and then choose specific solutions for the target system [4].

Figure 1. Softgoal Interdependency Graph

( reproduced from [4] )

Luiz Marcio et al. [8] present a reusable catalogue with strategies to satisfice usability requirements. Their aim of study is developing a usable ontology or classification of measurable aspects that can be used to aid in the specification of usability requirements. These ontologies should be represented in a way that facilitates their use as guidelines for the requirements elicitation process. Their work is built on review of literature in the area of human computer interaction and the emerging field of usability engineering in developing a catalogue used to guide the requirements engineer through alternatives for achieving usability.

Although goal-oriented method can support the elicitation of NFRs in the same way as FR’s elicitation, it lacks the integration of NFRs into FRs and to get an integrated description based on the use cases [9].

2.2. Use Cases and Misuse Cases Based Approaches

Use cases are based on the idea of describing a system’s desired behaviour by mentioning a story (along with alternatives and exceptions) and associated information from point of view of an external entity (actor). Misuse cases are based on the idea of negative scenarios i.e. a situation desired not to occur by an actor. Misuse cases (based on negative scenarios and malign actors) can enhance the elicitation process by identifying and analysing threats to system operation. They threaten use cases with failure, and appropriate use cases can mitigate known misuse cases. Misuse cases seem naturally to lead to non-functional requirements such as for safety and security. In [10], the authors outline concepts for an analysis of NFRs of a software system and develop a misuse based method for deriving detailed NFRs.

2.3. Templates and Patterns Based Approaches

Templates and Patterns are a better solution for managing the complexity of non-functional requirements elicitation process. In [11] and [12], the authors have considered usability features as functional usability requirements using patterns that have been termed usability patterns to elicit requirements. The goal is to propose artefacts (patterns) for reusing usability knowledge and supporting developers during the usability requirements elicitation stage. These patterns (Feedback, Undo/cancel, User input error prevention, Wizard, User profile, Help, Command aggregation) will then be able to be used to extract all the information required to fully and unambiguously specify the system’s usability features.

Figure 2. Process of eliciting the usability requirements

( reproduced from [11] )

Figure 2 describes the process of incorporating usability features for software functionality at the requirements elicitation stage. The usability requirements elicitation patterns can be added to the mechanisms and techniques to be used in the process of eliciting the requirements of the new software system to be developed and be used to specify all the usability requirements that have a direct impact on system architecture [11].

2.4. Aspect Oriented / View Point Oriented Approaches

I. Sommerville et al. [13] have introduced an approach to multi-perspective requirements engineering (PREview) which has been designed for industrial use. The authors showed how ‘concerns’, which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders. The proposed approach helps improve the quality of requirements specification by providing a framework for requirements elicitation, analysis and negotiation and support analysis based on the key business concerns which define the success or failure of a project.

2.5. Other Approaches

In [14], the authors have presented the secure software development process AEGIS, which provides important tools for developing secure and usable systems. They have defined a UML meta-model identifying assets, the context of operation and supporting the modelling of security requirements. This semantics allows the developers and the users to formulate constraints and needs for the security aspects of the system in a simple but clear way. By modelling the context in which the system operates and the interactions of the operatives and the assets of the system, this notation also allows the documentation of usability needs.

3. Results and Discussions

NFRs are generally considered as quality attributes or constraints on the software. They are normally hidden somewhere in the software specifications, or mentioned in the form of comments or special requirements. Consequently NFRs are frequently ignored or even forgotten leading to changes in software that will take place after the software was deployed. It has been observed that the corrections of NFRs are much more expensive and difficult to correct. Not eliciting NFRs or eliciting it inconsistently has led to the failure of many software projects. NFRs have surprisingly received little attention in the literature and are much poorly understood than other less critical aspects of the software development [3].

Elicitation of NFRs is not a straight-forward activity. NFRs are scattered to the functional requirements so called cross-cutting concerns to the FRs. Elicitation approaches which deals with producing requirements can run the risk of creating requirements which are ambiguous to the user community. The elicitation issues discussed in [15] are :

Problem of scope;

Problem of understanding; and

Problem of volatility.

These issues of elicitation are common both in functional and non-functional requirement elicitation. For non-functional requirements elicitation, we have found the following issues as cited in the literature:

Integration of NFR with FR;

Conflicts of Requirements; and

Ambiguously specification of the system’s features.

3.1. Integration of NFR with FR

Although Non-functional requirements have been increasingly accepted as the critical success measure of the success of the projects, it is under less focus in the industrial practices of software development in comparison to functional requirements. There are many guidelines available to sketch and model functional requirements i.e. UML views like use cases. Explicitly dealing with NFR and specifying NFR in concert to FR is a still a future research area. In most of the cases, NFRs are written in the form of special requirements in use cases and this informal approach leads towards different problems in the later stages of software development such as requirement tractability. All NFRs cannot be treated in the same way, for instance usability and security requirements need to be treated differently. The different communities concentrating on the different NFRs exemplify this. Thus, it seems difficult to define one method to cope with all NFRs [16] [7] .

3.2. Conflict of Requirements

Views and preferences of different stakeholders in the elicitation of functional and non-functional requirements are generally different. NFR elicited from different stakeholders can be in conflict with each other. An NFR can rarely be said to be satisfied. That is, treating NFRs as goals we bring the notion of partial satisfaction (satisfice) to refer to the solutions that are good enough even if they are not optimal [17] . So, the conflicts should be explicit including all the derived dependencies. Furthermore the decisions to solve the conflicts should be based on the rank of priorities [18].

3.3. Ambiguous specification of the system’s features

Certain features / quality attribute needs to be specified in a formal and consistent way so that they may be properly reflected in the system under development. These concerns are normally of highest priority and the absence / deficiency /inconsistency of these requirements normally results in a system where user satisfaction remains a question mark. Some of the important attributes based on literature work are as under:

3.3.1. Usability Requirements

Usability plays an important role in the success of a system as it is strongly influences the acceptance of the system by end users. Users can range from novice to experts and can have different levels of experience, knowledge and expertise. In most cases, neither users nor developers are good sources of the information that can be used to specify a usability feature. Dealing with usability features in isolation does not provide developers with enough information about what kind of artifacts to use to satisfy such requirements [12]. Most of the research in usability issues is focused on providing a better user interface (UIs), but there is a need of systematic approach to analyze and model usability in the early stages of software development along with functional requirements.

3.3.2. Security Requirements

Security, being a largely neglected area in requirement engineering, has become an increasingly growing concern in the information age. Keeping sensitive information secure is increasingly important within the context of electronic commerce applications [19]. Usually security requirements are specified at later stages of development; results in the compromise on system’s vulnerability. The number of security incidents reported has been growing exponentially over the past decade. Attackers can exploit many weak points in the system if the integrity and security requirements are not properly identified and ensured in the system. The elaboration, specification, analysis and documentation of application-specific security requirements is an area that has been left virtually unexplored by requirements engineering research to date [20].

3.3.3. Privacy Requirements

Privacy requirements play a critical role in the personal information system that deal with human-subjects data. These requirements capture privacy goals and their associated measures for a system under development. In order to ensure privacy we must identify the elements that dictate protection for sensitive information. The identification of such elements is not a straight forward task. These elements are normally difficult to quantity and precisely specify. There is a need for systematic approaches for reasoning, modeling and analyzing privacy from the early stages of the software development [21].

The following tables list some of the results that were concluded on the basis of this literature survey. Table 1 illustrates a part of available literature based on our research questions. Table 2 shows the relevant studies along with proposed approaches to handle the NFR elicitation issues, mentioned in the literature.

Table 1 : Paper Objective, Issues and Proposed Approaches

S.Id

Title

Research Objective

Research Question 1

Research Question 2

Eliciting Efficiency Requirements with Use Cases

An approach developed in the context of the EMPRESS project, which allows efficiency requirements to be elicited in conjunction with use case [7].

Abstraction levels for the elicitation and alignment of FR, NFR and AOs;

Views of different stakeholders in the elicitation of NFRs, FRs;

Identification of dependencies among FRs, NFRs and AOs; and

Compact description of the solution space

1. Use of a quality model and quality attribute types to capture general knowledge on NFRs, while specific NFRs are captured in a template.

2. A detailed checklists on how to elicit NFRs in concert with use cases and architecture.

A Framework for Integrating Non-Functional Requirements into Conceptual Models

Presents a framework for integrating NFRs into the ER and OO models [6].

Search for NFRs can be harder since neither the stakeholders nor the requirements engineers are used to dealing with them

Combination of the LEL and ethnography. Proposed The Non-Functional Model. The strategy is

Catalogue NFR knowledge using a tool that extends the concepts of the LEL to represent knowledge of NFRs;

A strategy for searching for NFRs in the UofD using the knowledge base together with elicitation methods suited to NFR acquisition; and

Represent these NFRs using an adaptation of the NFR graph proposed by Chung.

Non-Functional Requirements Engineering – Quality is Essential

Defines the requirements on a NFR method, compare this with current approaches and sketch ideas how to fill the gap between the current methods and their requirements [18].

Scenarios, ethnographical methods for elicitation. A practical template asking for specific NFR is VOLERE.

WinWin-approach (group decision), Aspect-oriented approaches algorithms and tools such as QARCC for the management of conflicts.

Non-Functional Requirements: Size Measurement and Testing with COSMIC-FFP

This paper contributes to the achievement of more precise project size measurement through incorporating NFRs into the functional size quantification process [22].

Every system goal cannot be entirely fulfilled, tradeoff must be made; the process is informal, it leaves the knowledge and the rationale that led to decisions undocumented. This makes it difficult to trace back to the selection criteria on which the decisions were developed.

Integrating FRs and NFRs: A Use Case and Goal Driven Approach

In order to encourage practitioners to focus more on much deserved NFRs, there is a need for frameworks to provide a smooth transition from the use case modeling. This paper proposes such a framework for integrating NFRs with FRs in the use case model [16].

Description of NFR is mentioned in special requirements section of use case description; this process is manual and error prone as the process is manual and thorough proof read of all use case description is required due to the lack of visual representation of NFR in the UML models.

Use case and goal-driven framework for integrating FRs and NFRs.

Transformation Based Approach for Weaving Use Case Models in Aspect-Oriented Requirements Analysis

This paper discusses techniques for combining non-functional requirements (NFRs) with functional requirements (FRs) in requirements analysis phases, based on aspect-oriented approach [9].

It is a problem to embed the elicited NFRs into the FRs and get an integrated description based on use case modeling, because the NFRs are scattered to the FRS, so called cross-cutting concerns to the FRs.

Goal-Oriented Analysis and Use Cases.

Evaluating the Effectiveness of Using Catalogues to Elicit Non-Functional Requirements

Understanding what the software must implement in order to cope with the needs is a challenging task. One way of addressing the need for help on NFR elicitation is the use of catalogues. It is shown that teams using catalogues performed significantly better [17].

When the requirements engineer decides to satisfice (operationalize) a non-functional requirement he may cause conflicts with other nonfunctional requirements.

The paper presents a framework for reusing knowledge on satisficing NFRs for goal-oriented approaches (Based on NFR Framework) with Use of catalogue.

Reusable Knowledge for Satisficing Usability Requirements

It is necessary to develop a usable ontology or classification of measurable aspects of usability that can be used to aid in the specification of usability requirements. These ontologies should be represented in a way that facilitates their use as guidelines for the requirements elicitation process [8].

In order to ensure usable systems we must ensure identification of appropriate requirements regarding these critical aspects of systems. However, a number of difficulties exist, for example it may be difficult to quantify and precisely specify these qualities in software systems.

Usability Catalogue

In this catalogue, usability is interpreted by refining it into subgoals and subsubgoals.

Non-Functional Requirements: From Elicitation to Modeling Languages

This work aims at filling this gap, proposing a strategy to elicit NFRs and to integrate them into conceptual models [3].

Lack of integration of NFRs to functional requirements results in conceptual models can result in projects that will take more time to be concluded, as well as to bigger maintenance costs.

Identifying Aspectual Use Cases Using a Viewpoint-Oriented Requirements Method

The crosscutting nature of requirements can be managed using aspect-oriented concepts. Aspects could be integrated to Vision, a viewpoint-oriented requirements method that integrates UML models [23].

NFRs can conflict with each other

Vision (Viewpoint-oriented requirements approach with UML which was extended to include aspect-oriented concepts). Proposed NFR Template.

A Survey of Non-Functional Requirements in Software Development Process

This survey paper reviews the NFR concepts, relates them to the overall software development process and identifies new areas of further work [2].

NFRs are subjective nature, formally specifying requirements, incorporating these requirements into models used for specifying functional requirements and resolving conflicts among NFRs.

RESPONSIBILITIES IN THE USABILITY REQUIREMENTS ELICITATION PROCESS

Details an approach to deal with usability features in the early software development stages. The authors consider usability features as functional usability requirements using patterns to elicit requirements, used to extract all the information required to fully and unambiguously specify the system’s usability features [11].

Proposed artefacts (patterns) for reusing usability knowledge and supporting developers during the usability requirements elicitation stage.

Proposed patterns include:

Feedback, Undo/cancel, User input error prevention, Wizard, User profile,

Help and Command aggregation.

Elaborating Security Requirements by Construction of Intentional Anti-Models

The paper presents a constructive approach to the modeling, specification and analysis of application specific security requirements. The method is based on a goal-oriented framework for generating and resolving obstacles to goal satisfaction [20].

Requirements need to be explicit, precise, adequate, non-conflicting with other requirements and complete.

Proposed Specification Patterns for Security Goals. The patterns are associated with specializations of the SecurityGoal meta-class, namely, Confidentiality, Integrity etc.

Identifying Stakeholders and Their Preferences about NFR by Comparing Use Case Diagrams of Several Existing Systems

Presents a method to identify stakeholders and their preferences about non-functional requirements by using use case diagrams of existing systems. They focus on the changes about NFR. Comparing different use case diagrams of the same domain helps us to find the changes that can occur. They utilize the Goal-Question-Metrics (GQM) method to identify variables that characterize NFR [24].

Identify stakeholders and their preferences about non-functional requirements using use case diagrams of existing systems.

Misuse Cases Help to Elicit Non-Functional Requirements

The proposed approach analyses Use and Misuse Cases in a game-like sequence to discover successively more detailed threats and NFRs to mitigate these threats. Misuse Cases seem naturally to lead to Non-Functional Requirements (NFRs) such as for safety and security [10].

Use Cases and Misuse cases to elicit Non-Functional Requirements.

Experiences in Eliciting Security Requirements

In this article, the author describes a trade-off analysis that he used to select a suitable requirements elicitation method and presents results detailed from a case study of one method and a series of two other methods, used in a series of case studies [25].

Elicitation Methods for Security:

1. Misuse Cases

2. Quality Function Deployment

3. Controlled Requirements Expression

4. Soft Systems Methodology

5. Joint Application Development

6. Feature-Oriented Domain Analysis

7. Critical Discourse Analysis

8. Accelerated Requirements Method.

A Requirements Elicitation Approach Based in

Templates and Patterns

Presents requirements templates that can improve requirements elicitation and expression, and two kinds of patterns: linguistic patterns, which are very used sentences in natural language requirements descriptions, and requirements patterns, which are generic requirements templates that are found very often during the requirements elicitation process and that can be reused with some adaptation [26].

Requirements engineers do not usually have good writing skills, and sometimes semantically correct requirements, expressed in natural language, are not understood because of the way they are written. Current elicitation techniques such as Joint Application Development (JAD), brainstorming or interviews do not address requirements expression.

Proposed Non-functional Requirement Template.

The Treatment of Non-Functional Requirements in MIKE

In this paper it is shown how non-functional requirements are modelled in MIKE, an approach to the development of knowledge-based systems [27].

Proposed NFR Context for providing the vocabulary to express NFRs in a structured way.

Integrating Security And Usability Into The Requirements And Design Process

Describes AEGIS (Appropriate and Effective Guidance for Information Security), a methodology for the development of secure and usable systems [14].

AEGIS

Viewpoints for requirements elicitation: a practical approach

Introduces an approach to multi-perspective requirements engineering (PREview). The authors show how ‘concerns’, which are key business drivers of the requirements elicitation process, may be used to elicit and validate system requirements. They are decomposed into questions which must be answered by system stakeholders [13].

PREview

Reusable Knowledge for Achieving Privacy: A Canadian Health Information Technologies Perspective

There is a need for systematic approaches for reasoning, modeling and analyzing privacy from the early stages of the software development. It is necessary to develop a usable ontology or classification of measurable aspects of privacy that can be used to aid in the specification of privacy requirements [21].

Privacy requirements may be difficult to quantify and precisely specify.

The work, built using the i* framework, presents a reusable knowledge base showing possible alternatives to operationalize privacy requirements using a Privacy Catalogue.

The Use of Goals to Extract Privacy and Security Requirements from Policy Statements

Addresses the use of goals to extract non-functional requirements from policy statements. It presents a summary of a goal-based approach for extracting standard security and privacy requirements from policy statements [19].

By employing the library of reusable privacy and security goals, requirements engineers and policy makers can identify potential conflicts and inconsistencies within policy statements and between system requirements and policies.

Guidelines for Eliciting Usability Functionalities

Discovering and documenting usability features is likely to be beyond the usability knowledge of most requirements engineers, developers, and users. It proposes an approach based on developing specific guidelines that capitalize upon key elements recurrently intervening in the usability features elicitation and specification process. The use of these guidelines provides requirements analysts with a knowledge repository [12].

In most cases, neither users nor developers are good sources of the information needed to completely specify a usability feature. Users know do not know what kind of feedback can be provided,. Neither do software engineers have the necessary HCI knowledge to completely specify such functional usability requirements since they are not usually trained in HCI skills.

Proposed a Pattern-Based Solution For Gathering Functional Usability Requirements.

Table 2: NFR Issues along with Solutions / Approaches

Serial No.

Issue

Solution (Approach)

Study Reference

Integration of NFR with FR

Use case and goal-driven framework for integrating FRs and NFRs

Goal-Oriented Analysis and Use Cases

A detailed checklists on how to elicit NFRs in concert with use cases and architecture.

(5)

(6)

(1)

Conflicts of Requirements

Vision (Viewpoint-oriented requirements approach with UML

WinWin-approach (group decision), Aspect-oriented approaches algorithms and tools such as QARCC for the management of conflicts.

Reusing knowledge on satisficing NFRs for goal-oriented approaches (Based on NFR Framework) with Use of catalogue

(10)

(3)

(7)

Ambiguous specification of the system’s features

1. Usability Requirements

2. Security Requirements

3. Privacy Requirements

Artefacts (patterns) for reusing usability knowledge

Usability Catalogue

AEGIS

Pattern-Based Solution For Gathering Functional Usability Requirements

Specification Patterns for Security Goals

Misusecase

Quality Function Deployment

Controlled Requirements Expression

Soft Systems Methodology

Joint Application Development

Feature-Oriented Domain Analysis

Critical Discourse Analysis

Accelerated Requirements Method

AEGIS

Reusable knowledge using a Privacy Catalogue

Library of reusable privacy and security goals

(12)

(8)

(19)

(23)

(13)

(15) (16)

(16)

(19)

(21)

(22)

A detailed discussion on other security requirements elicitation techniques such as Abuse Case and Attack Trees can be found in [28].

4. Conclusions and Future Work

Non-functional requirement is an important concept in the requirements engineering which plays an essential role in the success or the failure of a system. Unfortunately, NFR concerns are normally dealt at design and implementation level and this approach results in the failure of most of the systems. There was a need to find-out the issues, problems and challenges while eliciting NFRs. This literature survey is a first effort of its kind to seek NFR issues and their potential solutions at the elicitation level of requirement engineering. We have identified several key issues like conflicts of requirements, integration of NFR with FR and ambiguous specification of system features. We have found some of the solutions of these stated problems based on the available literature.

Most of the literature is based on NFR framework [11], which is an informal approach [3], and there is a need to produce a formal framework considering the mentioned solution in this paper based on the available literature. In the future, we would like to redesign the framework and eliminate the stated issues.

Order Now