Requirement Elicitation and its Automated Tools

ABSTRACT

With the rise in technology touching sky high like no one has ever seen this height. Starting from simples automation like a toy car to the highest of AI operated flights and Automated car, everything has started automating. The fast-growing software industry is never an exception. People started hiring people to automate things so that in the later time the hired person will no longer be needed. In a software Industry, everything starts from gathering the requirements which is called Requirement Elicitation. Requirement Elicitation is the most critical part because gathering the wrong requirement and producing the wrong end product directly results in the failure of the product. This Requirement Elicitation or Requirement Gathering is a time exhausting and error-prone when performed by requirement analysts. So that leads to a lot of research to automate the process. This paper aims to figure out the usage of which  automation tool is most widely used in requirement Elicitation Process through relating works and finding the effectiveness of the same .A small survey which was done with the help of limited crowd as a part of the Pilot study later discussed in this paper. The result from the survey helps to identify the effect of this Automation in the requirement Elicitation Process.

Keywords: Requirement Elicitation, Requirement Engineering, Automation, Effects of Automation.

INTRODUCTION

Requirement Engineering is the key stack of any software industry to cultivate and understand what the end-user, Client require to give the project the right direction. The key step in requirement Engineering include gathering, creating articles and verifying the Software Requirement Specifications (SRS). The Requirement Elicitation stands as the prime most step in Requirement Engineering because the wrong gathering of the requirement will absolutely end in the wrong end product. It is an accepted fact that if errors produced in requirement elicitation, if goes undetected till the very end turns out to be a costly mistake[1][2]. The key Stakeholders in this process includes the end-user, customers, product environment, system of implementation. It has been found that it turns out to be very difficult to motivate the customers what they want or even if the customer knows what he wants he might be hesitant to explain because of various reasons like lesser knowledge in the domain, Business politics, not clearly understanding what the end-user needs [3].So this had made the job of requirement analyst , software engineers very tough and requires them to shoot very selective question so as to reduce the aftermath effects.

Mich et al .states that the requirement gathering happens mostly through the medium of natural language[4].At the end of requirement elicitation all the documents in natural language will be formulated into more useful reports and documents which will be helpful in taking forward the project. Even though the natural language is the most prevailing medium in cultivating the requirements , they tend to cause intense problems when using it in specification documents as they might be unclear and uncertain [5].In large scale industry, it has become more challenging as a large number of natural language documents are gathered and has to be analysed. In this state manual requirement analysis turns out to be costly , time-consuming, error-prone[6]. So the above resulting in automating the process of requirement elicitation to a semi and full automated state.

The work presented in this paper is done with an aim to meet two research question .

RQ1:What percentage of companies uses Automation in Requirement Elicitation process?

RQ2: Which category of automation tool is widely used in the  process of requirement elicitation ?

RQ3:How effectively the tools were successful in getting to the best possible desired outcome which is the lesser error in the end product?

In the remainder of this paper, part 3 discusses on the State of the Art, part 4 describe the intended design of the study , part 5 describes the Pilot Study done with results and part 6 explains the conclusions. 

STATE OF THE ART

Categories of Automation tools

In [7] Barry et al. talks about the various categories of tools to support the refining of NL requirements  which are listed below.

1.Model Generation tools from NL descriptions This group of tools is used to generate abstract models like sequence diagram, class diagrams from use case description [7][8]. Dowser is one such tool implemented mainly on the focus to help the human analyst to identify uncertainity and inconsistency in NL SRS[8].

2. Key-Abstracts Identification tools from NL descriptions

This group of tools is used to identify key abstractions from NL documents, e.g. to help the human analyst getting an idea in an unexplored domain. AbstFinder[9] is one such tool developed which helps the requirement elicitor to find the key abstractions present in the natural language.

3.Trace Link finder tools

This group of tools helps to derive the trace links between NL descriptions of requirements or between the requirements and other artifacts used in the development process[7]. Retro [10] is an example of such a tool. Retro uses the information retrieval methods in automating the tracing of textual requirements [10].

4.Quality Analysis tools

This group of tools is used to record faults and discrepancy from good practice in NL requirement documentation[7]. The key aspect of this tool is to investigate the actual requirements rather than the initial detection of requirements in NL Documents. The QuARS [11] (Quality Analyzer of Requirement Specification) is an example of such a type of tool.

Key Issues Faced in Automation tools

Getting the complete and consistent set of document is the most difficult part of this elicitation [2].Van Buren and Cook [2] says that the automation tool naturally fails due to the technology adoption issues.

Several tools have been tested and verified in a very small scale crowd and need more perfection. Forgetting the best output out of Dowser, the input should be written in a constrained language so that it can be fed to the tool, which makes it increase the work rather than decreasing the work for a requirement analyst[8].Retro was able to accomplish high levels of recall at reasonable levels of precision, but accomplishing the high levels of precision without the assistance of filtering was not doable, which in turn implied that the tool needs more methods to address precision[10].To establish the effectiveness of QuARS several requirement documents which were written in natural language was examined and the QuARS found a large number of potential errors and analysts found the results useful for their analysis[11]. But even after so much of time, still, there is no exact proof that establishes the accuracy of these types of tools.

The usage and effectiveness of these automation tools in the real time industry became a key question so as depicting the effects of automation in requirement elicitation.

DESIGN OF STUDY

The key aim of this paper is review the current state of the art in accordance to the automation tools widely used in requirement elicitation.

This lead to an several research question on how far the automation has reached in the current industry with respect to requirement elicitation and what is usage of several widely used categories of the automation tools used in requirement elicitation. Though different companies used several different tools created by themselves or pre-existing tools , the categories which separated these tools remained nearly the same.

Get Help With Your Essay
If you need assistance with writing your essay, our professional essay writing service is here to help!
Essay Writing Service

First step to attain the results for research questions an survey was created to get input on what percentage of companies does the requirement elicitation process is automated . Then another survey getting inputs for which category of tools is widely used and what is the percentage of Error rate which indicates less errors in end product with respect to the requirement elicitation.

The key audience for the survey are a range of Mid-level and Senior Business Analysts ,Product Owners whose day-to-day work goes in and out of requirement engineering from different software companies.

PILOT STUDY

PLAN

In this Pilot study the above mentioned design of study was implemented with a limited group of desired audience (40 people) who had experience in requirement engineering ranging from 5 – 12 years.

The participants were requested to take the survey and give their honest feedbacks .

 ETHICS

All the data collected for this Pilot study is obtained from working professionals who has shared some highly confidential data revealing the process that is happening currently in their company .So all the names been wiped out and only the results of the surveys are documented.

 SURVEYS

Survey-1

The first survey is to filter out amount of companies using the automated tools in Requirement Elicitation.

https://www.surveymonkey.com/r/9WBHB9X

Survey-2

 The Second survey is to quantify which category of automation tool is widely used in the  process of requirement elicitation and how effectively the tool was successful in getting to the best possible desired outcome. This Survey was sent only to participants who had replied that automation was carried in the process of requirement elicitation.

   https://www.surveymonkey.com/r/9RMF9W9

RESULTS & ANALYSIS

Question 1: What type of process does your company follow in Requirement Elicitation?

From the above result it is evident that automation has reached to a very good extent in the current industry with respect to the Requirement Elicitation.

Question 2: Which category of Automation tool is used in your company?

Among the different categories of tools , the Quality Analysis Tools (38.89%) and Key Abstract Identification tools were used predominantly.

Question 3: How much percentage do the Model Generation tools are error-prone?

From the above stats the Model Generation tools seems to have least error-proneness compared to the others.

Question 4: How much percentage do the Key-Abstracts Identification tools are error-prone?

Question 5: How much percentage do the Trace Link Finder tools are error-prone?

Question 6: How much percentage do the Quality Analysis tools are error-prone?

So from the above result which was obtained from the participants , it is evident that almost most of the tools still have some error proneness which has to be covered by further research and works , so that it can be more widely used.

CONCLUSION

This Work gave an overview of what percentage of industry uses the automation currently .Also giving a short view on what automation tool categories were used in automation with respect to requirement elicitation and the error proneness of the tool categories on the whole. The study has been done on a small scale which though gives us a good results needs to be done with large scale participants from all parts of the world to give even more granulated view. There are still certain levels of imperfections in many tools which were proposed in the cited papers .Even though we are unsure of what other tools are personally used by any company ,the category which categorized those tools tends to be the same. The work done on most tools can be carried out in several directions in a view to improve the quality of the tools.

REFERENCES

[1] H. Reubenstein & R. Waters. (March 1991). The Requirements Apprentice: Automated Assistance for Requirements Acquisition. IEEE Transactions on Software Engineering. 17(3), 226-240.

[2] J. Van Buren & D. Cook. (1998). Experiences in the Adoption of Requirements Engineering Technologies. The Journal of Defense Software Engineering. 11 (12), 3-10.

[3] B. Nuseibeh & S. Easterbrook. (2000). , Requirements Engineering: A Roadmap, The future of software engineering. ACM Press. 1 (1), 37-46.

[4]  L. Mich, M. Franch, I.P. Novi. (2004). Market research for requirements analysis using linguistic tools. Requirements Engineering. 9 (1), 40-56.

 [5]  W.M. Wilson, L.H. Rosenberg, L.E. Hyatt. (1997). Automated analysis of requirement specifications, in. Proceedings of the 19th International Conference on Software Engineering (ICSE ’97). 1 (1), 161–171

[6]  W.F. Tichy, S.J. Koerner. (2010). Text to software: developing tools to close the gaps in software engineering, in. Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research (FoSER ’10). 1 (1), 379–384.

[7]  D. Berry, R. Gacitua, P. Sawyer, S.F. Tjong. (2012). The case for dumb requirements engineering tools, in: Requirements Engineering. Foundation for Software Quality, Springer, Berlin/Heidelberg. 1 (1), 211–217.

 [8]  D. Popescu, S. Rugaber, N. Medvidovic, D. Berry. (2008). Reducing ambiguities in requirements specifications via automatically created object-oriented models. B. Paech, C. Martell (Eds.), Innovations for Requirement Analysis, From Stakeholders’ Needs to Formal Designs,. 1 (1), 103–124.

 [9]  L. Goldin, D.M. Berry. (1997). AbstFinder, A prototype natural language text abstraction finder for use in requirements elicitation. Automated Software Engineering 4 . 1 (1), 375–412

[10] Hayes, J.H., Dekhtyar, A., Sundaram, S.K. (2006). Advancing candidate link generation for requirements tracing. The study of methods. IEEE Transactions on Software Engineering. 32 (1), 4-19.

[11]  F. Fabbrini, M. Fusani, S. Gnesi, G. Lami. (2001). The linguistic approach to the natural language requirements quality: benefit of the use of an automatic tool. Proceedings of the 26th Annual NASA Goddard Software Engineering, Workshop, . 1 (1), 97–105.