Presented to Dr. Vicki Sauter
Produced by: Ying Chen
Date: 11-08-12
“Requirements engineering is branch of software Engineering concerned with the real world goals, for Functions of and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families” [3]
v Four Methods of Communication
v Advantage and Disadvantage of Requirement Elicitation
Nowadays the usage of computer applications and software is increasing day by day and these systems play a vital role in the management of business existing today. Most of the software products developed today is to extend the existing system functionalities. Due to the today’s commercial on the shelf products development the vast range of fields that uses the computer to day[18] , different services are expected by stakeholders, which make it difficult to develop software that fulfills the expectations of the users. Since the 1960’s the development of computers based system has faced many problems [19] that leaded to too many projects being delayed and over budget. The systems that were delivered also did not meet the requirements, or satisfy the intended purpose which resulted in the dissatisfaction of the users. The main reason that could be stated for this problem is difficulties faced in the gathering of requirements, as requirements engineering is the first step in the software developments. Whenever the requirements engineers lack the knowledge of the performance and characteristics of the different elicitation methods, the activities related to requirements will fail, thus leading to wrong gathering of requirements that makes the wrong specification document never meets the stakeholder’ expectations and intended services. Moreover, the change in the requirements in the middle of the project developments phase will lead to delay and increased cost.
A major goal of Requirements Elicitation is to avoid the confusions between stakeholders and analysts. This will often involve putting significant sort into requirements elicitation. Unfortunately, Requirements Engineering is an immature discipline, perhaps not entirely unfairly characterized as a battlefield occupied by competing commercial methods, firing competing claims at each other, and leaving the consumers weary and confused[ 1].
The goal of this paper is to analyze and compare of the different methods of the requirements elicitation process, which will be useful to compare the different characteristics and the performance of the different elicitation methods. Hence, all the requirement elicitation techniques are very handy for extracting the requirements and different organizations, which can use different requirement elicitation techniques according to organizational culture and needs.
As requirements elicitation is a
process in which intensive interaction between stakeholders and the analysts,
so for finding the interaction between stakeholders and analysts will be easy
for improving the quality of extracted requirements. It is important to
distinguish different elicitation methods according to the four methods of communication
[21]:
1. Conversational
2. Observational
3. Analytic
4. Synthetic
Each category presents a specific interaction model between analysts and stakeholders. Understanding the method category helps engineers understand different elicitation methods and guides them to select appropriate method for requirements elicitation.
The conversational method provides a means of verbal communication between stakeholders and Analysts. As conversation is a natural way of communication and an effective mean of expressing needs and ideas, and the conversational methods are used massively to understand the problems and to elicit generic product requirements. The Conversational Methods are also known as verbal methods [], such as Interviews, Questionnaire, and Brainstorming.
Interviews: A typical conversational method is interviews. It is most commonly used method in requirements elicitation. An Interview is generally conducted by an experienced analyst, who has some generic knowledge about the application domain as well. In an interview, Analyst discusses the desired product with different stakeholders and develops an understanding of their requirements. Generally Interviews are divided in two groups. [2]
1. Closed Interview: In this interview the requirements, we have to prepare some predefined questions and try to get the answers for these questions for the stakeholder.
2. Open-ended Interview: In this interview, we do not need to prepare any predefined questions, and the information from the stakeholders in open discussions.
Questionnaire: Questionnaires are one of the methods of gathering requirements in less cost []. Questionnaires reach a large number of people, not only in less time but also in a lesser cost. The general factors which affect the usage of the questionnaire are [20]
1. The available resources to gather the requirements mainly depends on the available resource
2. Type of Requirements that has to be gathering depends on the level of the respondent’s knowledge and background.
3. Anonymity provided to the respondent
Brainstorming [11]: Brainstorming is another conversation method. It has some similarities with workshops and focus groups as in Brainstorming stakeholders are gather together for a short time period but in this short time period they develop a large and broad list of ideas. In this meeting “out -of-the-box” thinking approach is encouraged. The brainstorming involves both idea generation and idea reduction.
Conversation is one of the most prevalent yet invisible forms of social interaction. People are usually happy to describe their work and difficulties they face. The verbally expressive demands, needs and constraints are often called non-tacit requirements [13]. Conversational methods are very commonly used in requirements development. However, they are labor intensive [5]: meeting setup and transcript producing and analyzing from records of a live interaction take time.
The observational method provides means to develop a better understanding about domain of Application. Observation methods work by observing human activities at environment where system is expected to be deployed. In addition to state able requirements, some requirements are apparent to stakeholders, but stakeholders find it very hard to verbalize.
The observation methods come into play where Verbal communication becomes helpless for collecting tacit requirements. Therefore, observing how people carry out their routine work forms a means of acquisition of information which are hard to verbalize. The observational methods appear to be well suited when stakeholders find it difficult to state their needs and when analysts are looking for a better understanding of the context in which the desired product is expected to be used. Observational methods is including, Social analysis, Observation, Ethnographic study, and protocol analysis.
Social analysis, Observation,
Ethnographic study[19]: An observer spends
some time in a society or culture for making detailed observation of all their
practices. This practice gives the initial understanding of system, work flow
and organizational culture.
Protocol analysis[13]: In protocol analysis a
stakeholder is observed when he is engaged in some task, and concurrently
speaks out loud and explains his thought. With the protocol analysis it is easy
to identify Interaction problems in existing systems and it gives better and closer
understanding of Work context and work flow.
For Observational methods, the observer must be accepted by the people being studied and the people being studied should carry on with their normal activities as if the observer is not there.
In both Conversational and Observation methods, requirement elicitation is done by studying some individuals but a variety of documentation may prove out to be handy for extracting the requirements of the desired product. The documentation may include problem analysis, organizational charts, standards, user manuals of existing systems, survey report of competitive systems in market, and so on. By studying these documents, engineers capture the information about the application domain, the workflow, the product features, and map it to the requirements specification.
Conversational or Observational methods are used to directly extracted requirements from people’s behavior and their verbalized thought. But still there is a lot of knowledge that is not directly expressed, for example expert’s knowledge, information about regulation and legacy products are some examples of such sources. All the stated sources provide engineers rich information in relation to the product. Analytic methods provide ways to explore the existing documentation or knowledge and acquire requirements from a series of deductions.it will include Requirement reuse, documentation studies, laddering, and repertory grid [16]
Requirement reuse: In this technique, glossaries and specification of legacy systems or systems within the same product family is used to identify requirements of the desired system.
It has been observed that many requirements in a new system are more or less same as they were in a legacy system’s requirement. So it is not a bad idea to reuse the details of requirements of an earlier system in a new system.
Documentation studies [7]: In this technique different available documents (e.g. Organizational policies, standards, legislation, Market information, Specification of legacy systems) are read and studied to find the content that can prove out to be relevant useful for the requirements elicitation tasks.
Laddering: This technique can be divided in 3 parts: creation, reviewing and modification. Laddering method is a form of structured interview that is widely used in the field of knowledge elicitation activities to elicit stakeholder’s goals, aims and values Analyst used laddering method to create, review and modify the hierarchical contents of expert’s knowledge in the form of tree diagram. It was first introduced by the clinical psychologists in 1960 to understand the people “score values and beliefs [8.] Its success in the fields of psychology allows other researchers in the industries to adapt it in their fields. Specifically software developers have adapted the laddering techniques for gather the complex user tacit requirements.
Repertory grid: Stakeholder is asked for attributes applicable to a set of entities and values for cells in entity -attribute matrix. [14]
In general, the analytic methods are not vital to requirements elicitation, since requirements are captured indirectly from other sources, rather than end users and customers. However, they form complementary ones to improve the efficiency and effectiveness of requirements elicitation, especially when the information from legacy or related products is reusable.
So far, we have discussed Conversational, Observational and Analytic methods. It is apparent that No single method is sufficient enough to develop all the requirement of a system. All these methods are good and very handy in some certain context and circumstances. It is often a good idea to combine different elicitation methods for developing requirement. The combination helps the engineer uncover the basic aspects and gain a generic knowledge of the application domain. Instead of combining different of individual methods, the synthetic method forms a coherent whole by systematically combining conversation, observation, and analysis into single methods. Analysts and stakeholder representatives communicate and coordinate in different ways to reach a common understanding of the desired product. Synthetic methods are known as collaborative methods as they are collaboration of multiple requirement elicitation methods. Requirement elicitation techniques of Synthetic methods are including scenarios, passive storyboards, prototyping, interactive storyboards, JAD/RAD sessions, and Contextual inquiry [6].
Scenarios, passive storyboards: It is an interaction session. In this session a sequence of actions and events described for executing some generic task which the system is intended to accomplish. With the help of this technique, clear requirement related to procedure and data flow can be achieved. With this technique initial set of requirement can be prepared in lesser cost.
Prototyping, Interactive storyboards: In this technique, a concrete but partial system is discussed with stakeholders. This concrete but partial system is expected to be delivered at the end of project. The purpose of showing this system to stakeholders is to elicit and validate functional requirement. The p
JAD/RAD sessions [18]: It stands for Joint Application Development/Rapid Application Development and emphasizes user involvement through group sessions with unbiased facilitator. JAD is conducted in the same manner as brainstorming, except that the stakeholders and the users are also allowed to participate and discuss on the design of the proposed system. The discussion with the stakeholders and the users continues until the final requirements are gathered.
Contextual inquiry:[ 9] this technique is a combination of open-ended interview, workplace observation, and prototyping. This method used for interactive systems design where user interface design is critical.
All four requirement elicitation methods are
commonly used but the selection of requirement elicitation method entirely
depends on the needs and organizational structure. No matter what development
project is, requirements development nearly always takes place in the context
of a human activity system, and problem owners are people [16].
It is essential for requirements engineers to study how people perceive, understand,
and express the problem domain, how they interact with the desired product, and
how the physical and cultural environments affect their actions.
The conversational methods provide a direct contact channel between engineers and stakeholders, and the requirements are mainly no tacit. The observational methods provide an indirect channel by observing user’s interaction with his work setting and context, and the requirements fall into tacit knowledge. The analytic methods form one complementary indirect contact channel to extract requirements proactively. The synthetic methods focus more on collective effort on clarifying the features of desired products, and the communication channel is therefore a mix of direct contact and indirect contact. Each type of techniques has trade-offs. In reality, of course, the boundary between different types of method is blurred.
After the discussion the different of the four group of requirement elicitation method. In order to understand the each Requirement elicitation Methods and effective use them in the real case ,we have to focus on the advantages and disadvantages of different requirement elicitation methods: Conversational, Observational, Analytic and Synthetic one by one.
1) As conversation is a natural and effective way of communication, that’s why the conversational methods are used massively. Conversational methods include techniques such as: interviews, Questionnaire and Brainstorming.
Advantages of Conversational Method: Conversational techniques are really helpful for collection rich information about the requirements. Along with the requirements, conversational methods uncover opinions, feelings and goals of different individuals. With the help of conversational methods it is easy to dig into the details with the help of follow up questions to what the person has told you.
Disadvantages of Conversational Method: Along with the number of advantages there are certain disadvantages of conversational methods as this skill is very hard to master. Conversational Methods for requirement elicitation depend a lot on the behavior and attitude of conductor [4]. A Conductor is supposed to be neutral. As a result of conversational method, a collection of information can be obtained and getting meaningful information from gathered information will be difficult. In Conversational Methods the contexts of conversation plays a very important role as well.
2) Observational methods are helpful in understanding the application domain by observing human activities Observational methods are inefficient when the project have very tight schedule at requirement stages. Method like ethnography and protocol analysis methods falls under this category [22]. The Observational method involves: Social analysis, Observation, Ethnographic study and Protocol Analysis.
Advantages of Observational Methods: The observational methods are good choice for uncovering basic aspects of routine order. Moreover they provide vital information for designing solution. Observational Methods are very handy when the development team has lack of experience about product domain.
Disadvantages of Observational Methods:
Along with the advantages of observational methods there are certain
disadvantages as well. The Biggest disadvantage is that observation methods
need a lot of time and these techniques are not good choice when schedule is
tight. Just like conversational techniques, observational techniques are also
hard to master [10].
Moreover observational techniques require sensitivity and responsiveness to
physical environment.
3) Conversational or Observational methods are used to directly extracted requirements from people’s behavior and their verbalized thought. But still there is a lot of knowledge that is not directly expressed. For extracting this kind of knowledge and information analytical skills are used. Analytical Skills include Requirement Reuse, Documentation Studies, Laddering and Repertory Girds.
Advantages of Analytical Methods: Analytic Methods have numerous advantages as “People” are not the only source of information in terms of requirements. Experts Knowledge and Opinion plays an important role in requirement maturity. Moreover, reuse of already available information saves time and cost. Analytical methods have hierarchical flow of information as well.
Disadvantages of Analytical Methods: Along advantages, Analytical methods have certain disadvantages as well. The biggest disadvantage is that an analytical method requires some empirical data, documentation or expert’s opinions without these it is difficult to elicit proper requirements. Similarly analytical methods can narrow the vision of product. As analytical methods deal with some earlier knowledge so possibility of error replication is a serious and constant threat. Analytical methods are never a good choice when you are going to develop an altogether new system. [12]
Requirements elicitation is a critical step in the requirements development process. It is consequently imperative that requirements engineers apply appropriate methods to perform the process sufficiently. Based on which a practical guideline for method selection is suggested, we have attempted to present meaningful insights into the feature of different types of requirements elicitation techniques. The classification of requirements elicitation methods is based on the nature of the techniques. It reveals the different communication channels for the analysts to elicit requirements, and provides the contextual situation for method selection.
It is worth outlining that the techniques discussed in this paper are based on the implicit assumption that the human stakeholders and the requirements analysts are cooperative and sincere. The stakeholders are willing to share knowledge with the analysts and the analysts prepared carefully before conducting an elicitation session. Requirements engineering is a complex social interaction process, the techniques discussed in our paper provide analysts a proper and contextual means to perform the process. Besides, the analysts should possess interpersonal skills to help build consensus between heterogeneous groups of stakeholders. Such social skills are as important as the techniques used in the engineering process.
1. “Master thesis in computer science” http://www.ukessays.com/essays/computer-science/master-thesis-in-computer-science.php
2. “Requirements Gathering and Determination” http://baggins.nottingham.edu.my/~sdaniel/G52LSS/Lecture%20Notes/Requirements%20Gathering.pdf
3. Bashar Nuseibeh, Steve Easterbrook “Requirements Engineering: A Roadmap” http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf
4. Byrd, T.A., Cossick, K.L. and Zmud, R.W. “A Synthesis of Research on Requirements Analysis and Knowledge Acquisition Techniques.” MIS Quarterly, 16 (1). 117 – 138
5. Christel, M.G. and Kang, K.C.” Issues in requirements elicitation Technical report”, Carnegie Mellon University, Pittsburgh, PA, 1992, 80.
6. Cook, D. A., 2002, “Verification & Validation of Requirements” http://www.sstc-online.org/Proceedings/2002/SpkrPDFS/ThrTracs/p961.pdf, Software Technology SupportCenter (STSC)
7. Gump, F., 2009, Requirement Elicitation Techniques http://www.docstoc.com/docs/17037477/Requirements-Elicitation-TechniquesDocument-ID-SWENG-DI
8. Hawley, M., 2009, “Laddering: A Research Interview Technique for Uncovering Core Values” http://www.uxmatters.com/mt/archives/2009/07/laddering-a-research-interview-technique-for-uncovering-core-values.php.
9. Holtzblatt, K. and Beyer, H. “Making customer-centered design work for teams”. Comm. ACM, 36 (10). 93 – 103
10. Hudlicka, E., “Requirements elicitation with indirect knowledge elicitation techniques: comparison of three methods”. in Requirements Engineering, (Colorado Springs, CO, 1996), 4 – 11
11. Leffingwell, D. and Widrig, D. “Managing Software Requirements” - A User Case Approach, 2nd Ed. Addison-Wesley, 2003.
12. Lloyd, W.J., Rosson, M.B. and Arthur, J.D., Effectiveness of elicitation techniques in distributed requirements engineering. in IEEE Joint International Conference on Requirements Engineering, (2002), 311 – 318
13. Maiden, N.A.M. and Rugg, G. ACRE: Selecting Methods for Requirements Acquisition. Software Engineering Journal, 11 (3). 183 – 192
14. Nan Niu, Steve Easterbrook “Discovering Aspects in Requirements with Repertory Grid” http://trese.cs.utwente.nl/workshops/early-aspects-ICSE2006/Papers/6%20Niu%20Easterbrook.pdf
15. Nielsen, D., 2009a, “Requirements Gathering - Choosing the Right Tools” http://ezinearticles.com/?Requirements-Gathering---Choosing-the-Right-Tools&id=2439512. last checked 2009-11-11]
16. Nuseibeh, B. and Easterbrook, S., Requirements engineering: a roadmap. in Proceedings of the Conference on The Future of Software Engineering, (Limerick, Ireland, 2000), ACM Press, 35 - 46.]
17. Roel Wieringa, “Practical Requirements Engineering Solute” http://csdl.computer.org/comp/mags/so/2004/02/s2016.pdf
18. Rottmann, D., 2009, “Joint Application Development” http://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm.
19. Stephen Viller ,Ian Sommerville “Social analysis in the requirements engineering process: from ethnography to method” http://archive.cs.st-andrews.ac.uk/STSE Handbook/Papers/SocialAnalysisREProcess-Viller.pdf
20. Suzanne Robertson, James Rovertsonions:” Mastering the requirements process”1998
21. Wai-Ching Leung; “how to design questionnaire”. University of East Anglia http://student.bmj.com/back_issues/0601/education/187.html
22. Zhang, Z., 2007, Effective Requirements Development - A Comparison of Requirements Elicitation techniques, Tampere, Finland