A framework for software requirement ambiguity avoidance

ABSTRACT


INTRODUCTION
For software projects, Requirements Elicitation (RE) is crucial. As we know that in the later stages of the software, correcting errors becomes a very tedious job as errors escalate exponentially. Therefore, during the elicitation process, if we can identify these incorrect and ambiguous requirements that can decrease the cost of correcting these errors in the software significantly. Digging out Requirements is not easy as they are deep in the social and organizational structure of organizations. There exist a variety of elicitation techniques, each and every technique has its own pros and cons. There is no single technique, which can be effectively used for all type of problems.
Most of the time root cause of failures of software development projects are the poor quality SRS [1][2][3]. As per [4] the commonly used method of the software quality measurement is the empirical method, and few researchers adopted an AHP and Fuzzy technique in determining the software quality. There are many challenges associated, that it must be clear, correct, consistent, unambiguous, modifiable, verifiable and traceable, with a good quality SRS. Ambiguity is one of the major problems in the requirements specification. Ambiguity rarely surfaces during the development of a requirements model. Ambiguity is a challenge because the various readers may perceive different contextual information from requirements specification. Although, there are many solutions provided by different authors to resolve ambiguity in the form of frameworks, models, procedure, techniques, and tools. There are plenty of techniques available for handling different types of SRS ambiguities [5][6][7][8][9][10][11][12]. Although there are many techniques to resolve ambiguity but to date, there is no effective method to handle it. Apart from different frameworks and techniques, there exist a variety of automated tools mentioned by [8] e.g. SREE, QuARS, RESI, ARM, NAI, NL2OCL, and WSD etc. used to detect and resolve ambiguities.
We are planning to work on a technique which can avoid ambiguity so that it shouldn't prevail to SRS document. Finding ambiguity and then removing it is a lengthy and expensive process. We will try to eliminate the ambiguity during elicitation or in the initial phases of SRS development. To avoid ambiguity, we propose framework SRAAF which will select effective elicitation technique and then verify each and every elicited requirement using the W6H technique. The first task is to select an elicitation technique based on the significant parameters from a large set of elicitation techniques. After choosing the selection technique suggested by the SRAAF, start elicitation process, before finalizing a particular requirement applies W6H technique in a manner to avoid ambiguity. In this paper, we propose a two-phase framework to select the technique based on the available parameters related to project, domain knowledge, stakeholders, elicitor and list of elicitation techniques, which can influence the selection. By using all set of parameters we apply a mapping in the framework to check which technique fits with a particular set of available parameters. After the selection, we will apply W6H to remove a particular type of ambiguity on the elicited requirements. In [13] author provided the set of ordered interrogatives questions for requirement elicitation as W6H pattern extended from W5H.  Major categories: thing (what); person (who); place (where); selection (which);  Minor categories: time (when); manner (how);  Incidental categories: reason (why); To process natural language, apart from W6H, domain specific Anaphora resolution [14] can aslo be used that focuses on the problem of resolving what a pronoun, or a noun phrase signifies.

PROBLEM DESCRIPTION
The process of Requirements Elicitation (RE) is formulating the actual requirements of the customer, to construct a system so that software developers can describe the customer problems in a more systematic way and can focus on their actual requirements. To understand customer requirements in a proper way is still a challenge, as natural language is used as a major tool to communicate with the stakeholders, and they may describe ambiguous and incomplete requirements. As we know requirements are unstable and may change with the passage of time. Selection of RE techniques is influenced by many factors, technical as well as social and greatly affected by many other issues as well. The selection of elicitation technique by requirement engineer is based on the following ideas [15]. That is:  They use a heuristic approach  They are comfortable with a particular technique and select it.  The technique worked good last time, so it will work again in the same manner  It's the intuition of the requirement engineer that the technique is useful in the present situation.  The engineer has his own specific methodology for the selection based on it and he recommends a technique. Many authors study and discovered about the problems related to RE [16][17][18][19], and they found that the problem is considerably at higher scales then it seems to be. "Surveys confirmed the project failure rate is much higher, as one-third of the projects started were never completed, and one half of them succeeded only partially". Weaker RE process is the root cause for such failures, more accurately, the lack of stakeholder's interest, unclear objectives, incomplete requirements, ambiguity in requirements, and impractical expectations. Once we are able to select the correct RE technique most of our problems will be solved. As the solution to effective RE is not possible purely through technological way because there are several factors which can affect the selection other than the technical one [20]. Different stakeholders are involved in the process of RE with different level of knowledge, understanding, and experience, to bring all of them together on a common platform and elicit unambiguous requirement is a tedious task.

LITERATURE SURVEY
In the recent decades, the research field of requirements has broadened. The selection of appropriate RE technique for a particular domain is crucial. Need to support requirement engineer, to take decision for the effective selection of elicitation tools, and techniques to elicit requirements from the stakeholders. In [21] author explains the relationship between the end user requirement and accuracy of Project Management Software. Numerous research papers elaborated various elicitation techniques and prepared guidelines on how to use them [20,[22][23][24]. A framework is proposed by Maiden et al. [16,25] to describes the RE selection method. A model proposed by Hickey et al. [17,19], that focus on the selection of elicitation technique and to elaborates the RE process. Bickerton et al. [19] suggested a model based on the social assumptions, to classify the elicitation techniques. Macaulay [26] proposed a list of the selection of elicitation techniques. Kotonya et al. [27] claim there are attributes that can be useful for the effective selection of the elicitation technique.
S. Lauesen, [28] discussed various techniques that can be applied for elicitation and elaborated that the issues of RE are not tackled appropriately. Extensive research can be performed in the direction, by developing an appropriate methodology for the selection of effective elicitation technique. Whereas Viviane et al., [29] proposed a combined approach, to elicit requirements more effectively. The process of elicitation is based on knowledge model, build around scenarios and stories about the required system and a supporting tool for interaction. For the efficient selection of elicitation technique, Yan Tang et al., [30] proposed a framework based on Bayesian Belief Network to provide the guidance to the stakeholders but didn't focus on many important parameters. We can see that Sumaria et al., [31] presented a method to select elicitation technique, on the basis of parameters and priorities of the project. Zhying [32] worked on a technique, which provides a practical guideline for selection of elicitation technique based on the context of different projects. There are few empirical surveys on the comparison of elicitation techniques. The lack of experiments and experimental environment, techniques, and variables studied by them, make it tough to reach the application environment for elicitation technique [19].
Lauesen's [28] proposal missed three important criteria: basic and fundamental information is based only on the authors' judgment; contextual factors considered only stakeholders and problem domain attributes; and workable supporting tool, as he wasn't able to deliver any provisional tool or software. The proposal by Davis and Hickey's [33] failed on the following four criteria: basic theoretical information; unclear values of attributes; improper subjective fitness or adequacy check; and non-availability of a practical tool to support his model. Proposals described by different authors in [16,[34][35][36] were unsuccessful on similar criteria as defined above.
In our framework, we will use a selection of effective elicitation technique along with W6H technique to avoid ambiguity. There are seven basic types of interrogatives words in the English Language: which, where, who, why, when, and how [37]. Author extended the W5H set with which to make it W6H. An interrogative word is a function word used to "generate" an interrogative sentence (question). For example, the interrogative sentence 'when will you reach the destination?' is created using interrogative when. In [13] author developed a technique, on the basis of semantic and lexical rules of English Language, to frame interrogative questions for effective requirements elicitation. For better requirement elicitation, he suggested and outlined how to systematize stakeholder viewpoint.

THE PROPOSED FRAMEWORK (SRAAF)
Requirement Elicitation is a tedious process and can lead to ambiguous requirements. The proposed SRAAF deals with requirement elicitation involved majorly two phases, the first selection of appropriate elicitation technique for effective elicitation based on situational attributes and second applying the W6H technique to handle ambiguity, the detail about the technique is explained in the framework. Implementation of different phases of the framework is as shown in Figure 1.  Questionnaires. Apply W6H Technique: ask a question in a sequence as defined in W6H technique to avoid ambiguity and to get documented unambiguous requirements.

FRAMEWORK DETAILS
The purpose of the framework is to avoid ambiguity in SRS while requirements elicitation. Figure 2 shows the detailed steps of the framework. As we know there are two phases, the first phase of the framework is how to select an effective requirement elicitation (RE) technique for a particular situation. To proceed, we need detailed information about significant parameters along with elicitation techniques which are in practice and used by academic and industrial partners. Selection of effective RE depends upon various parameters and can be performed in a variety of situations, which may include many aspects like project details (Size, Complexity, and Time etc.), Requirement Engineer(Experience, Training, Domain Knowledge etc.) and stakeholders or participants.
Based on the mapping of situational parameters with significant parameters, we will choose one of the elicitation techniques. Once the effective RE technique is selected according to the situation, we can progress to the next phase, which is how to apply W6H technique to avoid ambiguity. The detail of each and every step is as follows: Figure 2. Proposed framework to avoid ambiguity

RE expert knowledge
To create an RE Expert knowledge we searched different databases to identify relevant literature. We initiated a search using a query on IEEE, ACM, Springer, Scopus, Science Direct and books. We made a comparison to check whether our findings include publications from these peer-reviewed papers. We scanned all sources resulting from this selection process. We applied inclusion and exclusion criterion, based on the title and abstract, to select appropriate literature. If we are not able to take a decision based on the title and abstract then further we go into the detail. In order to select elicitation techniques, several papers [20,22,23]

Determining significant parameters
Before we select the most suitable elicitation technique, it is important to determine the significant parameters that can affect technique selection. In [38] D. Carrizo et al. listed preliminary set of 34 significant attributes and used only a few in his selection process. Author aggregated and eliminated most of them, but in our framework, we are using 19 important parameters. We clustered the recognized parameters along with possible values into three classes named as Project as shown in Table 1, Requirement Engineer/ Requirement Analyst as shown in Table 2 and Stakeholders as shown in Table 3. Quantity and nature of available information in the form of parameters may affect the selection process and can lead to new selection technique.

List of elicitation techniques
A "technique" is a way of performing or applying the practical method to complete some useful tasks [36]. On the other hand, an "Approach" is an organized arrangement, in the form of ideas, steps, or actions performed to deal with a situation or problem. There are plenty of RE techniques described by authors. Most of the time, we look for a simple and easy RE technique to elicit requirements. We can't apply the same RE techniques as the situational parameters may vary for different projects in the real-life situation. There are many approaches and techniques that can be applied to elicit requirements. All these techniques can be arranged into majorly four groups, Traditional, Group-Based, Scenario-Based, and Contextual.
Requirement Engineers apply different RE technique to elicit requirements, according to the project domain and there comfort level. Here we will focus on the techniques shown in Figure 3. As for the rest of the techniques, we won't be able to collect the values for the significant parameters, which we will use in the selection process of elicitation technique.

Situational parameters
Here, we will identify the situational parameters of the project under consideration. The current status and settings of the project will define the situational parameters or contextual parameters. In this step, we will check the values of all significant parameters for the current project and will register required in a tabular format so that we can map these values with our RE Expert Knowledge as shown in Table 4 (a, b, c) to select the appropriate RE technique.

Check the suitability of the technique
This is one of the important steps, as we are going to select the effective elicitation technique based on the situational parameters. To check the suitability we will use the situational parameters and map it with significant parameters in Table 4(a, b, c). To verify the result we need the significant parameter values for each and every technique. To get the data for all techniques we searched many sources and generated a two dimensional matrix. This matrix contains significant parameters value all RE techniques under consideration.

Selection of appropriate technique
We have all necessary information in line, to select an appropriate RE technique for explicit elicitation sessions. Our selection process is based on the adequacy table in which we populated information of various parameters for different elicitation techniques. As we know, it's a significant extraction of the information, but still, there can be deficiencies. How to combine this adequacy table information to select the effective technique is solely depend upon requirement engineer's decision. A complete and final solution should select more than one technique according to the fitness of the techniques. Now by judging conditions and based on the situation, requirements engineer will be able to take a decision, that which technique can be applied to a particular elicitation session.

Selection of different elicitation technique (by improving parameters)
The selection process offers a list of adequate or less adequate techniques. When there are no adequate techniques, or we wanted to select a different technique we can improve the values of situational parameters. Here we are using 19 different situational parameters, most of them are either fixed (Project Size and Complexity, etc.) or rigid, and there are only few which are flexible (Experience with elicitation technique, Elicitation Experience, Domain Experience, Time Availability, Location, People Per session, etc.). To choose a different technique we can always improve the flexible situational parameter.

Elicitation process
The process of Requirements elicitation is uncovering, seeking, obtaining, and elaborating requirements for a system. It is a process, in which we elicit and understating the meaning of requirements instead of just captures or gather a requirement. RE can be performed using many tools, techniques, and approaches and it involves plenty of activities. So we won't go into the detail of the elicitation process rather we will follow the process defined by various authors and academicians for the technique selected by our framework. Our focus is on the selection of the technique and applying W6H on elicited requirements to handle the issue of Ambiguity.

Applying W6H on requirements
In [13] author explained, how W6H pattern is used to formulate questions to be asked by requirement engineer or analyst to the stakeholders. He also explained the order of the interrogative question, in which order they must be asked for effective RE. Both requirements elicitation and gap bridging are widespread challenging tasks. Using W6H pattern structured approach we can tackle these issues. As Cysouw [39] describes the interrogative categories:  Major classes: who (person), what (thing), which (selection), where (place);  Minor classes: how (manner), when (time);  Incidental classes: why (reason).
Here we will use the same approach but in a different way to remove ambiguity from the elicited requirements. We will apply the interrogative question to all statements in the same order.

Documenting and reviewing requirements
The required documentation is concerned with the controlling and organizing a large number of requirements elicited for a particular project. After applying the W6H technique, requirements engineers are liable for documenting & reviewing the requirements elicited. The role of documentation is especially important as it signifies the final step of the requirement elicitation using the framework and of great importance for successful execution of next phases of the project. Review of the elicited requirement and the work completed by the analyst or Requirement Engineer is based on the output produces in the previous step of documentation. As we know, software projects have fixed budget and time constraint, therefore documented requirements should come as approved document based on the user's real need [22].

CONCLUSION
Ambiguous statements written in the Natural language is very common and gained the focus of researchers, linguists, and academicians. Most of the previous work to handle ambiguity in SRS has focused only on detecting and then removing it. Despite so many tools and techniques, the problem of ambiguity is still a challenging issue. But our focus is on how to avoid ambiguities before we write any statement to the SRS. There are two major issues encountered by every Requirements engineer: choosing the effective RE technique and how to control ambiguity. The SRAAF can handle both issues effectively and can be applied to small and medium scale projects. Our future work will provide the basis to automate the effective selection of RE method described in this paper. As we know the full automation would involve advanced natural language processing (NLP) technologies that can apply W6H technique, which is not currently available.