A Proposed Process Model for Requirements Engineering using Delphi Techniques for Prioritisation

Published Online December 2014 in MECS DOI: 10.5815/ijitcs.2015.01.09

Every software system needs requirement definition. Requirements drive almost every activity, task, and deliverable in a software development project. Specifically, requirement defines what the software must do to add value for its users; what the software must be to add value for its users; and what limitations there are on the choices that developers have made when implementing the software. The development of this requirement is not just a collection process but a discovery and invention process. In a software development project, these requirements are determined and agreed to by the users (who are legitimate sources of requirements) before the software can be built. These requirements are further engendered through a process. This is with the view to improve system quality and users satisfaction; for easing compliance with standards and systemic regulations; reduction of project cost and delay;

control of complex projects in a way to reduce errors, manage risk and avoid possibly omission and ambiguities; and then to improve team communication. In particular, the success of a software system depends on how well it fits the needs of its users and its environment. Therefore, software requirements comprise these needs, and Requirements Engineering (RE) is the process by which the requirements are determined [1]. If the requirements are not right, the execution of the entire project during development will be faulty. In essence, RE lays the foundation for  successful software  and system development projects regarding cost and quality [2].

According to the ISO/IEC/IEEE FDIS 29148:2011 [3], requirements are defined as: “statement which translates or expresses a need and its associated constraints and conditions” The word ‘statement’ used in the definition can be captured in tabular form, in diagrammatic form as in notation such as Unified Modeling Language (UML), in formal notations, or in domain-specific notations. In most cases, software developers just talk about requirements without a prior knowledge of the different levels of requirements. Understanding the various levels of requirements is an important step towards system development with effective quality improvement in mind. In [4], the different levels of requirements were presented as shown in figure 1. The user requirements as shown in the figure are utmost in every development process. These requirements are based on the business requirements of the entire system. In particular, the users have vested interest in both the functional and nonfunctional requirements. All of these levels of requirements can be facilitated through the requirements engineering process.

However, in the context of SE, many approaches to the software development process have been formulated, In spite of their differences, virtually all of them includes the Requirements Engineering (RE) phase. This is because, RE addresses the first software development step and lays the foundation for a successful system. According to [5], “one of the main objectives of RE is to enrich systems modeling and analysis potentials so that businesses can better comprehend vital system aspects before they actually develop the system”. The functional requirements together with quality attributes and other nonfunctional requirements will establish the software requirements specification [6]. RE has been defined as the “the branch of software engineering concerned with the real-world goals for functions of and constraints on software systems” [7]. In [8], RE is defined as “the subset of systems engineering concerned with discovering, developing, tracing, analysing, prioritising, qualifying, communicating and managing requirements that define the system at successive levels of abstraction”. The authors in [9] defines RE as “a process of identifying the stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation”. In the opinion of [10], “RE is the structured process of elicitating, defining, negotiating, prioritising and validating the requirements of a system”. These definitions lists carefully selected key activities that are considered proper to RE within the scope of this paper, specifically when considering prioritisation issues.

Fig. 1. Levels of Requirements (adapted from: [4])

According to [11], these activities will naturally involve a subset of the stakeholders of the system, such as analysts, developers, system architects, the client, the end users, domain experts, etc. In practice, stakeholders communicates their requirements to the analysts, who may specify them and communicate them back to the origin for validation, and to other stakeholders such as developers, who need the requirements. This initiates a process that needs to be followed in order to ensure quality improvement. The authors in [1] observed that RE is about defining precisely the problem that the software is to solve (i.e., defining what the software is to do). In reality, [12] observed that budget and schedule constraints limit the number of requirements that can be worked on for a software system and is thus necessary to select the most valuable requirements for implementation.

Hence, the justification for ‘prioritisation’. This is true in a situation where there are multiple and conflicting requirements elicitated from stakeholders in the process of developing and/or implementing complex and service-oriented systems, for example, the healthcare system. However, selecting from a large number of requirements is a decision problem that requires negotiating with multiple stakeholders and satisficing their value propositions [12]. Requirements will come from many different stakeholders, involve multiple disciplines, and be presented at varying levels of abstraction [13].

Therefore, there is need for an analysis process model that represents requirements in a prioritised multiple dimension.

Finally, this paper is organised into six sections. This section, being the introduction, provides an exhaustive overview of requirements, RE and a brief discussion of requirements prioritisation. Section 2 deals with problem statement and motivation that justifies requirements engineering processes. In section 3, the relationship between requirements engineering process and prioritisation issues were established. The Delphi technique application to requirements prioritisation was discussed in section 4, and the proposed model was presented in section 5. The conclusion and implication of this paper is articulated in the last section.

• II.    Problem Statement and Motivation

The ability to identify problems and suggestions for improvements in the RE process opens up significant potential for increasing the success of software projects. In order to improve RE processes, the current practices need to be examined within the scope of a defined software development project.

The authors in [14] opined that “inaccurate, inadequate, or misunderstood requirements are the most common causes of poor quality, cost overruns and late delivery of software systems”. Requirements problems are widely acknowledged to reduce the quality of software and to impact on the effectiveness of the software development process [15]. Despite the importance of requirements engineering, little work has been done on developing ways to improve requirements process. As observed in [16] and [17], Information System (IS) projects deliver 42 to 67% of their original requirements and 48% of Information Technology (IT) development relates to requirements engineering. Consequently, many information system development problems could be traced to RE [18, 19, 20, 21].

Even with the significant varieties of software development processes and project management techniques, software projects may still fail due to vague definitions of project goals, ambiguous requirements, communication and coordination problems (e.g. conflicts that leads to omission in requirements and inconsistencies of requirements) among the stakeholders. From existing literature, prevailing techniques in RE processes do not provide a blended approach of understanding, capturing and representing different stakeholders’ expectations in a way to prevent omission, ambiguity and inconsistency of requirements. As a result, requirements are prone to issues of disputes, collision of concerns, disparity and disagreement among the stakeholders [22, 23].

Therefore, there is need for requirements negotiation and prioritization techniques that will help the developers to obtain consensus among stakeholders; and there is need for understanding and modeling current RE processes towards improving RE practice and thereby increasing the success of software development. In fact, when improving the software engineering process, the area, which may have the largest effect on the result, is RE. This is because, requirements are the first things produced, and projects are conducted and finalized in strict concordance with them. So, the ability to improve the software product in order to meet the needs of all stakeholders in software development is a great concern in the software industries. Hence, requirements engineering process is required to provide the appropriate mechanism for quality assurance, resolving ambiguities, vagueness and fuzziness subject to the conflicting concerns of stakeholders [24, 25].

• III.    Requirements Engineering Process And Prioritisation Issues

Holistically, the RE process is naturally collaborative in nature where validation issues are crucial and mandatory, thereby involving agreements among the stakeholders. According to [26] and [27], “broad mastering is generally infeasible for a single person” in the RE process. As such, an individual cannot claim knowing all that is required for developing any system, since lots of stakeholders with different backgrounds and perspectives are involved. As observed in [28], RE process censoriously has effect on the success of software development process. Figure 2 shows the modified processes from [29] for capturing requirements in a development process. The figure indicates that all other activity from the analysis level to validation can be made to return back to elicitation when need be. In addition, at the analysis level where the desired behaviour need to be understood and modelled, requirements prioritisation can be performed. To check that the specification matches the users’ requirements at the validation level, prioritisation can be made useful.

A typical RE process as shown in figure 3, can have a number of inputs and outputs. Inputs to the RE process includes existing system documents, stakeholder’s requirements (elicitated, gathered or collected through appropriate methods and techniques), business and organisation procedures, domain knowledge. The outputs usually includes the final requirements listing, specification of system and system models. Within the specified phases as shown in figure 3, the requirements analysis phase can be enhanced with the inclusion of prioritisation. This is because, the intensiveness from both knowledge and human perspectives during analysis process opens up the problem of decision making on requirements that can be facilitated by requirements prioritisation. At this level, the requirements are graded or ranked in their order of importance.

Fig. 2. The Process for capturing requirements (Modified from [29]).

Fig. 3. A typical RE Process showing the need for including prioritisation of requirements at the analysis stage

With respect to prioritisation issues, the RE process is knowledge-intensive [30] and human-intensive [31], demanding an extensive analysis and tradeoff to be performed in order to prioritise requirements according to certain parameters to overcome the challenge of inconsistence, omission and ambiguity of requirements. This makes the RE process valuable when followed in evolving a system or in a software development project early stage. The activities, which are performed as part of the RE process, aim at the discovery and specification of requirements that unambiguously reflect the purpose of a software system as well as the needs of all relevant stakeholders [9]. It is with this in mind that the paper aimed at proposing a process model for RE using the Delphi technique that allows experts involvement in the prioritisation of requirements in producing the requirements lists and specification. In most cases the problem of unclear descriptions of requirement always occur, which often leads to terminological misalignment between analyst and stakeholders, and then potentially wrong requirements [32] are elicited. As a result, negative consequences of these wrong requirements are felt during all downstream activities such as architecting, design, implementation, and testing. As observed in [33], Poor-quality requirements greatly increase development and sustainment costs and often cause major schedule overruns. More to this problem is the elicitation of partial information due to stakeholder’s omissions [34].

However, requirements prioritisation aims at selecting the ‘right’ requirements from a set of candidate requirements so that all the different key interests, technical constraints and preferences of the stakeholders are fulfilled [10]. Requirements prioritisation involves the allotment of priorities to different stakeholder’s requirements. This facilitates requirement engineering process. It also helps requirement engineer’s makes crucial decisions about requirements in a software development process. It is used to determine which candidate requirement of a software project should be included in a certain release and different techniques are used to facilitate that. The various techniques used different approaches and consider different factors for prioritisation e.g. cost, value, risk, benefit etc. Specifically, prioritisation is performed to grade or rank requirements in their order of importance and subsequent implementation releases during RE [35]. As such, it is a major step taken in making crucial decisions so as to increase the economic value of a system. The authors in [36] opined that the priority of a requirement is a characteristic that can be used for different purposes, depending on the program and company needs. According to [10], various approaches are recognised by researchers for requirements prioritisation. In [37], prioritisation using the cost and benefit pertaining to every requirements was established. The authors in [22] opined that a prioritisation method using the relationship matrix utilizes the concept of correlation to compute weighted priorities of the requirements from the multiple perspectives of the stakeholders. In this paper, we are of the opinion that involving experts from the specified domain to prioritise these multiple requirements in a number of rounds will be useful to resolving consensus that will arise from the various stakeholder’s expectations and requirements.

• IV.    The Delphi Technique and Requirements Prioritisation

The underlining philosophy for the choice of using the Delphi technique for prioritisation is based on New Lanchester Theory (NLT) and the fact that the technique involves experts in making consensus based on stakeholders’ inputted requirements. NLT links business requirements to market share using quantitative model [38]. The theory postulate that the strength of two or more forces in contention are equal if both suffer the same proportional loses. In specific terms, during requirements prioritisation, the theory can be applied to decide which requirement to specify for the expected software product. We infer from the NLT that getting the necessary requirements for any system requires prioritisation. Secondly, analysing the requirements gathered for a system requires prioritisation in order to avoid conflicts (in terms of inconsistency). In a way, we view requirements gathering and collection as a warfare process where various requirements are to be contended for in terms of making adequate choice on which requirement to use for system development. In such scenario, we are of the opinion that these elicited requirements need to be prioritised (i.e. graded and ranked) in their order of importance. To achieve this, the Delphi technique becomes suitable for the ranking, where experts are expected to participate in the process. In essence, prioritising the requirements plays a significant role in reducing requirement problems and increasing customer satisfaction.

However, [39] opined that the Delphi Technique is based on structural surveys, it makes use of the intuitive available information of the participants, who are mainly experts, and it delivers qualitative as well as quantitative results. The technique is widely recognized as a ‘consensus-building tool’, which has been applied as a means of cognition and inquiry in a variety of fields, including RE. The Delphi Technique is said to be particularly appropriate in facilitating decision-making by a number of individuals in environments characterized by antagonistic or strongly opposed political or emotional factions, or when personality differences or intellectual style would be distracting in face-to-face settings [40, 41]. The technique consists of a number of rounds of questions to progressively identify, clarify and expand on issues and ideas. In this case, the issue in need of identification, clarification is the requirements. The first round usually consist of general questions to gain a broad understanding of the views, opinions or needs of the range of experts. The responses from this round are collated and summarized and this forms the basis of the next round of questions which will investigate further or clarify the issues raised in round 1. Again the results are collated and used to formulate a third (and usually final) set of questions which will generally consist of obtaining a consensus on the relative importance of the requirements identified in the previous rounds. A key aspect of Delphi is the anonymized feedback that the experts receive between each round of questioning; general feedback is provided to the experts between rounds and individuals are given the opportunity to revise judgments as a result of the feedback. This actually qualifies the technique to be an iterative method. Whilst in the author in [42] defines the Delphi Technique as ‘an interactive and personality free team approach’, [43] proclaims its purpose is to ‘elicit information and judgments from participants to facilitate problem-solving, planning, and decision making’ capitalizing on respondent’s creativity, whilst simultaneously maximizing the merits and minimizing the liabilities of group interaction. Since the technique involves noninteractive groups, it is possible to draw upon experts who are based at considerable geographic distances.

• V.    The Proposed Model

Figure 4 shows the conceptual basic flow of the proposed model. The Delphi technique will be used to resolve the inputs arising from the requirements. This makes the approach a multilevel prioritisation technique with the involvement of experts. In contrast to other analysis techniques, Delphi employs multiple iterations designed to develop a consensus of opinion concerning the various requirements elicitated. In the proposed model, Delphi involves the use of stakeholder’s and experts at various stages or rounds to iteratively prioritise the requirements. The experts’ iterative prioritisation is with the view to ensuring the evaluation of requirements in order to produce the specified requirements listing.

• A.    Requirements Elicitation

Requirements will be elicited from stakeholders using interview, case study, observation and secondary data. Elicitation process starts at the early stages of RE. In particular, the input to the model comes from the various stakeholder’s requirements and/or expectation to be elicited. In addition, iterative and interactive means of eliciting requirements can also be a source of input. At this level, we envisage that appropriate algorithm be defined and used to facilitate requirements elicitation. In particular, we can have other inputs from the algorithm that defines a set of one or more partial orders ( ord 1 … ord n ), derived from the requirement documents. In this case, we specify the priority, value, dependences, etc. from the requirements documents. Another source of input during requirements elicitation in the model can come from the business and organisation procedures. The algorithm can be used to support initialization of the various stakeholders with a set of totally ordered requirements. All of these requirements elicitated from the stakeholders and the stakeholders’ profiles will be kept in the stakeholders’ requirement database. The stakeholders’ profile includes a brief description of themselves, their expectations about the system and the system functionalities of their choice. At this stage, the first round of the Delphi technique is initiated. The stakeholders’ requirements elicitated will be used for the second round of the Delphi technique.

• B.    Expert Prioritisation

After the first round of requirements elicitation in the Delphi technique, experts are invited in the second round. During the second round, experts reviews the stakeholders’ requirements and profiles as elicitated. Accordingly, the experts are required to rate or “rankorder the requirements to establish preliminary priorities among the requirements. As a result, areas of disagreement and agreement are identified. It is possible at this level to request that experts justify the rating order of priorities among the various stakeholders’ requirements. An interesting aspect of this round is the possibility of establishing consensus.

• C.    Expert Ranking of Requirements

In this level of prioritisation, the experts are given the opportunity to make further clarifications of both the information and their judgment of the relative importance of the requirements ranked. However, compared to the previous round, only a slight increase in the degree of consensus can be expected [44, 45, 46, 47]. The possibility of providing a final opportunity for the experts to revise their judgments can be establish in the third round of the Delphi technique or allowed to pass on to the fourth round. In a way, Delphi iterations depends largely on the degree of consensus sought by the investigators and can vary from three to five [48, 49]. Specifically, during the experts ranking of requirements, if the target consensus has not been reached a feedback for experts of subsequent round is initiated, otherwise, if target consensus has been reached, the result is reported.

• VI. Conclusion

Going further, it was generally discovered that the involvement of experts in decision-making on which requirement to pass on for development is crucial. The Delphi technique has been suggested in this paper to facilitate and enhance the process of requirements prioritisation in a multilevel prioritisation dimension, conceptualized in a model. Therefore, the proposed model on implementation will contribute to the formulation of an interactive framework for requirements prioritisation to produce a requirement ordering which complies with the existing priorities.