arch:taxonomyofproductrequirementselicitationanddevelopmentmethods [objectoriented.ru]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Taxonomy of product requirements elicitation and development methods ======

By Sabina Belyaeva sabinabeliaeva@gmail.com

===== Introduction =====

Software development is a complicated process that includes many steps. These steps may simplify the whole operation if the approaches for their implementation are chosen in the right way. One of the significant steps is requirements elicitation and development, since requirements should define deliverables and reflect relevant goals. Extensive and well-organised requirements make the process of development understandable and consistent. The eliciting and developing requirecement demands right techniques. But in fact the process of selecting the right techniques is also quite complex. As the result, the taxonomy of requirements elicitation and development methods may simplify this process by giving a brief description of each method and signifying a particular interaction between stakeholders and analysts.

===== Elicitation and development methods =====

A guide to the business analysis body of knowledge provides a lot of different techniques. Almost all of them were taken from social sciences but only a few of them have been chosen for requirements elicitation and development[1]. It goes without saying that each method has its advantages and disadvantages:
Brainstorming is used for generating new ideas and solutions, usually conducted in free-form discussion. Each member presents their own ideas for the solution of the problem. Best idea is nominated by members voting as a solution for the problem[2]. This technique is not suitable for a small group of stakeholders with different points of view. And the success of the method depends on individual creativity and willingness of participants.
Document Analysis is the process of gathering information about business by studying available documents. This process includes analysing each document’s content and recording notes about each theme[3].It is also necessary to find out whether some notes conflict or whether there are some duplicates. This technique is efficient for capturing domain knowledge. Due to this method business analysts do not need to create additional content and existing documents are usually used as a point of reference to find out what has changed. Moreover, results of analysis can be used for validating against the results of other requirements elicitation techniques.
Interviews is the speaking process when an interviewer asks stakeholders specific requirements questions. Conducting the right interview the interviewer can gain a complete view of the system. However, successful interview depends on several factors[4]:

  * the level of understating of the domain by the interviewer,
  * skills and experience to conduct the interviews and take notes,
  * The willingness of interviewee to  provide relevant information

Without these factors the interviewer can collect only imprecise data.
Requirements workshops are formal and highly structured meetings for reviewing requirements. Usually such meetings are of longer duration and they are useful for developing large and complex requirements. Requirements workshops generally include[4]:

  * Group of stakeholders
  * Interactive work
  * An assistant
  * A defined goal

The weaknesses of this method are that this technique is expensive, slow and not useful for small products.
Observation is the process of watching for stakeholders who complete their tasks. Analysts can observe stakeholders in either work environments or artificial conditions. The main advantage of this technique is that real insight about conducted tasks of stakeholders will be gained. But the process of observing can be threading and obsessive for the person who is the target for observation[4]. 
Prototyping presents the initial visualisation of the system. Usually this method is used for confirming system requirements. Prototyping helps to recognise the workflow of the actual system. This technique is costly. The process of creation may be slow since the system can be sophisticated.
User scenarios usually reflect functional aspects of the system. It should specify a sequence of interactions between a system and an external actor[5]. Use scenarios are understandable for stakeholders due to their narrative flow. They also clarify scope and provide a high-level understanding of requirements.[4]

===== Division methods by types =====

At first sight all techniques are different but in fact some of them have little in common and be classified by communication means[6]:

  * **Conversational** - during this method people communicate between each other via asking and replying to the specific questions or just via expressing their own ideas, this process can be structured or not. Brainstorming, Interviews and Requirements workshops are conversational methods. Choosing one of these methods analysts create a basis of other elicitation techniques, since usually during these methods huge amounts of data is gathered.
  * **Collaborative** - such methods use diverse communication channels and develop models for reflecting systems’ characteristics of communication. To this class belong Prototyping and User Scenarios techniques
  * **Analytic** methods suppose the examination of existing system documentation. Document analysis is an analytic technique.
  * **Contextual** methods suppose eliciting information during executing tasks in the context of wherever the software will be located. To this type belongs an Observation method.

This taxonomy shows different types of techniques and gives a brief description that allows one to get acquainted with the methods without deep analysing of each technique. Moreover, this classification can help to combine the techniques. As it was mentioned, all techniques have their strengths and weaknesses and sometimes it will be more useful to combine them in order to get better results. For example, in order to prepare for an interview (collaborative type), it will be useful to conduct document analysis(analytic type) or in order the interviewees get proper information, they need to see a prototype(contextual methods). 

===== References =====

  - Coulin, C., Zowghi, D., “Requirements Elicitation for Complex Systems: Theory and Practice, in Requirements Engineering for Socio-Technical Systems”, 20.0
  - Sajjad Umar and Hanif Muhammad Qaisar, “Issues and Challenges of Requirement Elicitation in Large Web Projects”, Master Thesis, School of Computing, Blekinge Institute of Technology, Sweden, January 2010.[[https://www.diva-portal.org/smash/get/diva2:830517/FULLTEXT01.pdf|https://www.diva-portal.org/smash/get/diva2:830517/FULLTEXT01.pdf]]
  - Arif Mohd. and Sarwar Saoud, “Identification of Requirements using Goal Oriented Requirements Elicitation Process”, International Journal of Computer Applications ,Volume 120 – No.15, June 2015.[[https://research.ijcaonline.org/volume120/number15/pxc3904070.pdf|https://research.ijcaonline.org/volume120/number15/pxc3904070.pdf]]
  - IIBA, “A Guide to the Business Analysis Body of Knowledge (BABOK Guide) Version 3.0,” International Institute of Business Analysis, Ontario, 2015.
  - Pressman, R. Software engineering: a practitioner's approach (7th ed.). New York: McGraw-Hill higher education,2010.
  - Batra Mona and Bhatnagar Dr. Archana Bhatnagar, “An Experimental Survey to Find Application Specific Elicitation Technique”, 4th International Conference on “Computing for Sustainable Global Development”, 01st - 03rd March, 2017 Proceedings of the 11th INDIACom, 2017 New Delhi (INDIA).