Comparison Techniques And Categories

Published Date: 02 Nov 2017

Abstract

Introduction

Requirements Elicitation

- Requirements elicitation: quite a number of authors have stated that requirement elicitation is the first phase of the process, by which a project team determines the organizational needs that must be addressed by the project effort (Goguen & Linde, 1993), (Kotonya & Sommerville, 1998), (Escalona & Koch, 2004) and (Loucopoulos & Karakostas, 1995). Particularly, requirements elicitation concentrates on the preliminary pursuit of identified requirements and possibilities of the social actors (e.g., participants, users) most strongly associated with the system.

- A report from IEEE, (2004) claims that, requirement elicitation is concerned with, where software requirements originate from and how the software engineer can gather them. It is the first stage in understanding the problem, which needs the software is required to solve.

- Browne & Ramesh, (2002) have defined requirement elicitation is the first step in the first step in gathering user requirements; it is the process of understanding and acquiring the needs of users and other stakeholders.

The term elicitation is used to capture the idea that, the individuals, who will be engaged within the system on a daily basis, are the appropriate source for the identification of needs and opportunities, and that designers must "draw" the requirements from such stakeholders. It is important to note that the requirements elicitation process focuses on "what" is expected to be achieved by the predicted system irrespective of "how" it is to be achieved.

In the literature, a range of process models have been developed to identify the various features of the requirements phase of the software. One widely employed model suggests three fundamental stages, such as: elicitation, specification, and validation of requirements (Loucopoulos & Karakostas, 1995). It is noteworthy that, requirements elicitation is concerned with the process of determining what issues must be addressed by a design effort. Requirements specification is constructed upon the elicitation activity, and comprises the specific documentation of the specifications for the system (Vessey & Conger, 1994). Generally this constitutes both natural language explanations and official modeling techniques. Ultimately, requirements are carried out to assure the recognition of stakeholders for the requirements, which have been reported and which will be applied in pursuing design initiatives. (Wallace & Ippolito, 1997). While this three-stage model indicates a linear strategy to develop requirements., the three phases are generally employed iteratively, often moving progressively in more detailed levels of requirements gathering.

Just as the requirements phase process is critical to the overall success of software design efforts, the requirements elicitation also plays a crucial initial role in the extensive requirements elicitation process. One of the crucial features of requirements elicitation is that, it is typically one of the most important components, by which the project team members acquire knowledge related to organizational domain. Loucopoulos & Karakostas, 1995 have stated that "the importance of requirements elicitation cannot easily be overestimated; when you have to solve somebody else’s problem the first thing you have to do is to find out more about it".

The emphasis of the requirements process is generally presented as the process revealing the essential obstacles within the business context, generally known as "problem domain." Consequently, traditional requirements elicitation strategies signify a shortfall based mode of inquiry, which is participating "in a study of what is unsuitable, not working, not up to standard, and in need of a ‘fix’" (Whitney, 1998).

As a matter of fact, there are a wide range of techniques that have been employed in requirements elicitation phase (Goguen & Linde, 1993). Each technique comprises quite a number of strengths and contributes towards the understanding of the designer pertinent to the organizational domain in a wide range of ways. A set of techniques have been defined and tested by requirements engineering experts, to make the requirements elicitation step more efficient and precise (Escalona & Koch, 2004). Of course, each requirements elicitation technique comprises certain limitations. In the following section we have presented an overview of the most relevant techniques used in requirements elicitation, in the context of a standard software development process. We have demonstrated the classifications of requirements elicitation techniques and we will briefly highlight a number of the most widely employed methods of requirements elicitation and discuss the associated strengths and the challenges.

Why Requirements Elicitation?

Overall, the goal is to bring the analyst, user, and other stakeholders closer to a mutual understanding of the requirements they want to address. Defining requirements calls for effective interaction and open communication between the user and the developer to generate the necessary requirements they want to address. Defining the requirements calls for effective interaction and open communication between the user and developer to generate the necessary requirements information that can be used to develop the system that meets the needs of the user (Guinan & Bostrom, 1986).

Requirements Elicitation Techniques Categories

The requirements elicitation techniques facilitates the developers to have an understanding of the requirements of users, this phase allows the developers to recognize the requirements of stakeholders, other than the actual users of systems (Browne and Ramesh 2002; Hickey and Davis 2004). Nevertheless, Farzan et al, (2008)have stated that, elicitation is the process, which motivates the dynamic contribution of users in system development, which consequently increases the accomplishments and endurance of information systems.

According to Zhang(2007) specifications progression is an rigorous communication procedure among stakeholders and the programmers, therefore the four kinds of elicitation methods vary depending on the context of communication: observational, conversational, analytic, and synthetic (Zhang, 2007). Each and every kind provides a unique communication model among programmers and stakeholders, and demonstrates the characteristics of a strategy. Realizing the category of method facilitates engineers to comprehend various elicitation methods and guides them to choose an suitable technique, for requirements elicitation.

Conversational methods

The conversational method provides a means of verbal communication between two or more people. As conversation is a normal means to convey requirements and concepts, and ask and answer questions, it is efficient to build and comprehend the issues and to elicit generic product requirements. Methods in this group are also referred as verbal methods (Avison, 1995). A standard conversational strategy is interview. . It is generally used in requirements elicitation (Kotonya & Sommerville, 1998). Other methods under this category include workshop, focus groups and brainstorming. As illustrated in Table 1.

Method

References

Executor

Illustration

Interviews

(Goguen&Linde,1993), (Kotonya&Sommerville, 1998), (Leffingwell & Widrig, 2003) & (Julio & Ana 1996).

An experienced analyst with generic knowledge about the application domain

Interviewer discusses the desired product with different groups of people and builds up an understanding of their requirements (Interviewer asks questions to the specialist or end-users, related to a particular topic). If the interview is conducted with pre-defined agenda and questions, it is called structured interview; otherwise, it is an open ended interview.

Workshop, focus groups

(Goguen & Linde,1993), (Leffingwell & Widrig, 2003)

An experienced Outside facilitator

Stakeholder representatives gather together for a short but intensely focused period to create or review high -level features of the desired products.

Brainstorming

(Leffingwell & Widrig, 2003), (Linn, 2008), (Chauncey, 2006), (Zowghi & Coulin, 2005) & (Tsumaki & Tamai, 2005)

An experienced outside facilitator

Brainstorming is a kind of mini conference, held among six to ten experts. Members from different walks of life involve in the brainstorming, chaired by the organizer, who asserts the topic to be discussed.

Table : Conversational methods

One of the most common types of social relationship is conversation. Generally people are pleased to express about the jobs they perform, and the challenges they encounter. The verbal needs and limitations are generally called non-tacit specifications. As oral communication is realistic and productive to gather non-tacit knowledge, the conversational methods constitute the principal approach to non-tacit requirements elicitation, by carrying out interviews, workshops or brainstorming sessions (Maiden & Rugg, 1996). Conversational strategies are extremely generally used in requirements development, however not by itself, they require combining other kinds of techniques, to accomplish the software development phase. However, they require a lot of human efforts (Christel & Kang, 1992), (Goguen & Linde,1993): conference set up and creating transcript and examining records of a live conversation, and consume a lot of time. On the other hand, it is concern to accomplish the elicitation process, particularly when employing workshop or brainstorming, e.g. organizing the meeting and making sure that the representatives are available for the meeting (Kotonya & Sommerville, 1998).

Observational methods

The observational method provides a means to develop a rich understanding of the application domain by observing human activities. In addition to non-tacit requirements, some requirements are obvious to stakeholders, but difficult to verbalize, which is called as tacit requirements (Maiden & Rugg, 1996). Verbal communication is frequently weak, when gathering tacit requirements. Consequently, observing how people perform their routine work, facilitates gather information, which are challenging to explain in words. Methods under this group are illustrated in Table 2.

Method

References

Executor

Illustration

Social analysis & Ethnographic study

(Kotonya & Sommerville, 1998) & (Maiden & Rugg, 1996)

The observer must be accepted by

the people being studied as a kindred spirit and must be sufficiently familiar that they carry on with their normal practices as if he was not there.

An observer spends a period in a society or culture on making detailed observation of all their practices,

(Interact with a product in a natural environment). User culture and work environment are observed

Observation

(Nuseibeh & Easterbrook, 2000), (Viler & Sommerville, 1999) & (Goguen & Linden, 1993)

Protocol analysis

(Goguen & Linde,1993) & (Maiden & Rugg, 1996)

A subject is engaged in some task, and concurrently speaks out loud and explains his thought.

Table :Observational methods

Observational methods seem to be best suited, when individuals find it complicated to communicate their requirements and when analysts search for a improved comprehension of the perspective, where the preferred product has to be utilized (Viller & Sommerville, 2000). Good examples of tacit information consist of the scheduled work, which individuals accomplish day-to-day, spontaneously and in the organizational or social contexts, which most likely affect the specifications. As people are acquainted with the perspective and scenario of their work, they do not deliberately contemplate about the schedules and the working environment. It is challenging for them to enunciate how work is performed, despite the fact that occasionally the routine work is simple to be revealed to others (Kotonya & Sommerville, 1998). Therefore, to be engrossed in the actual work scenario, to acquire the observational facts, can assist engineers to thoroughly, understand the routine of work, the societal group, the organization, and the wider perspective, within which the product is used.. As observation methods fall into the category of longitudinal studies, in general, it takes longer period than the other methods (Myers, 1999), which is considered as main disadvantage of such methods, especially when the project has tight schedule at the requirements stage. Besides this, observation requires compassion and receptiveness to the physical environment (Zhang, 2007). It is easy for observers to perceive a good image about the work context, but it is normally hard to specify and analyze their perception.

In addition, observational methods are used for understanding complex societies, rather than making judgments about improving or supporting the ways of working (Zhang, 2007) & (Kotonya & Sommerville, 1998). They are beneficial to discover fundamental elements of routine order, such as the standard design of work, and offer the most relevant information towards designing solutions (Hutchings & Knox, 1995). Consequently, it is generally a good practice to begin with an observational method, to get an preliminary comprehension of the preferred product, when the development team falls short of experiences of product development in a given domain.

Analytic methods

Analytic methods provide ways to explore the existing documentation or knowledge and acquire requirements from a series of deductions. They are illustrated in Table 3.

Method

References

Executor

Illustration

Requirement reuse

(Cybulski & Reed, 2000), (Knethen et al, 2002), (Kotonya & Sommerville, 1998), (Woo & Robinson, 2002), (Viler & Sommerville, 1999) & (Goguen & Linden, 1993).

Documentation

In this technique the systems within the same product family is used to identify requirements of the desired system.

Documentation studies /content

(Cybulski & Reed, 2000), (Knethen et al, 2002), (Kotonya & Sommerville, 1998),

Documentation,

A common method consisting of reading

and studying available documentation for

content that is relevant to and useful on

the requirements elicitation tasks.

Analysis Laddering

(Rugg et al, 2002)

Expert ’s

knowledge

It involves the creation, reviewing and

modification of hierarchical content of

expert’s knowledge, often in the form of

ladders (i.e. tree diagrams).

Card sorting

(Rugg & McGeorge, 1999)

Expert’s

knowledge

The expert is asked to sort into groups a

set of cards each of which has the name

of some domain entity written or

depicted on it.

Table : Analytic methods

A wide range of studies have focused on requirements of the preferred product, which consists of problem evaluation, organizational charts, specifications, user manuals of existing systems, research report of competitive systems in market, and so on. By understanding it, the engineers capture the information about the application domain, the work-flow, the characteristics of product, and map it to the requirements specification. Furthermore, they recognize and reuse requirements from the specification of the heritage or identical products. It is always worth searching and filtering for reports and recorded information, relevant to the desired product. The mapping techniques are beneficial for knowledge acquisition, in analytic methods (Byrd et al, 1992). Multidimensional scaling (Byrd et al, 1992) and (Wright & Ayton, 1987) allows users to obtain conceptual structure, to recognize aspects and identify cause-effect associations of a process, and variance analysis (Byrd et al, 1992) and (Hawgood et al, 1978) to use existing system as a basis for determining new system requirements. Generally these techniques are considered as knowledge acquisition strategies; however they are also flexible in requirements elicitation. As explained in Table 3, laddering (Rugg et al, 2002) is utilized to elicit justification and explanation of technological terminologies or subjective terms, and to elicit, how specialists composite their knowledge about a field, and card sorting (Rugg & McGeorge, 1999) offer means to elicit features that are not instantly communicated by the experts. Generally, the analytic strategies are not essential to requirements elicitation, because requirements are grabbed ultimately from other sources, instead of end users and clients. Nevertheless, they form secondary variants, to enhance the performance and usefulness of requirements elicitation, particularly when the information from heritage or relevant products is re-usable.

Synthetic methods

The synthetic strategies incorporate various channels of communication, and offer models to illustrate the characteristics and relationship of system. They deliver good hints for requirement recognition, in the form of abundant semantic models (Maiden & Rugg, 1996). For instance, the prototypes offer an initial version of the system to the users, which can emphasize them about the functions which are usually in any other case ignored. Storyboard technique, which is categorized between scenarios and prototyping. It presents a procession of prospects beginning from sample components to live interactive reports (Leffingwell & Widrig, 2003). Appreciative Inquiry (AI) is a combined method, which includes communication between clients and designers, examine the existing systems, tracking the behaviors of the users and visualize the future system or software, with all the necessary functions. It includes combined strategies, which enhance requirements elicitation process. Examples of synthetic methods are illustrated in Table 4.

Method

References

Executor

Illustration

Scenarios, passive storyboards

(CREWS, 1999), (Kotonya & Sommerville, 1998), (Stuart, 2001), (Leffingwell & Widrig, 2003) & (Zowghi & Coulin, 2005).

Analysts and stakeholder representatives communicate and coordinate to reach a common understanding of the requirements.

This approach describes the precise details of the current and future processes, which comprises the actions and interactions between the users and the system.

Prototyping, Interactive

storyboards

(Kotonya & Sommerville, 1998), (Leffingwell & Widrig, 2003), (Nuseibeh & Easterbrook, 2000) & (Andriole, 1999).

It provides stakeholders with a concrete (although partial) model or system that they might expect to be delivered at the end of a project. It is often used to elicit and validate system requirements. Prototype generally represents and visualizes the actual parts of system.

JAD/RAD

(Maiden & Rugg, 1996), (Zowghi & Coulin, 2005), (Coughlan & Macredie, 2002), (Charles & Francesca, 2008).

It stands for Joint Application Development. Rapid Application Development and emphasizes user involvement through group sessions with unbiased facilitator. This approach is more or less similar to the brainstorming, however, it differs is one aspect, where the stakeholders and the users are also allowed to participate and discuss on the design of the proposed system.

Contextual inquiry

(Holtzblatt & Beyer, 1993)

It is a combination of open-ended interview, workplace observation, and prototyping. This method is primarily used for interactive systems design where user interface design in critical.

Appreciative Inquiry (AI)

Cooperrider&Srivastva,1987), (Cooperrider&Whitney, 2001), (Barrett & Fry, 2005), (Whitney&Trosten-Bloom, 2003),(Stavros&Torres, 2005) &(Kelm, 2005).

Appreciative Inquiry (acronym "AI") is principally an organizational development  method, which focuses on increasing what an organization does well rather than on eliminating what it does badly.

Table : Synthetic methods

Rather than the of methods constrained at the requirements phase, the synthetic methods are generally integrated at other phases of the product development life cycle. As the purpose of synthetic methods is to enhance the communication among programmers and the clients, they are appropriate for various phases of the development process. They efficiently coordinate the requirements stage with the remaining development processes.

Comparison between categories of requirements elicitation techniques

The categories are due to the outcomes of dissimilarities between the requirements elicitation techniques, each and every group has some characteristics, which make all categories to have distinctive characteristics. The table below shows comparison among various groups of elicitation techniques and their benefits and drawbacks.

Category

Example

Stakeholder Participation

Observable phenomena

Future system Knowledge

Understanding the domain

Identifying sources of requirements

Predictive ability of unique attributes elicited

Conversational methods

Interviews

Definitely stakeholders are the main participants

Not applicable

Some hints or guidelines are provided that might guide the future development of systems. Novel ideas might lead the analyst to envisage future system

Diverse, knowledge sharing might make analyst to understand domains

Nil

Nil

Observational methods

Observation

Stake holders do not participate, as this method totally involves the observer to observe the activities of the end-user

The whole process is based on the phenomenon of observation (s), hence this criteria is very crucial

Observing the current methods are not easily applied to the development of future concepts

Observational methods

clearly makes the analyst to understand the domain.

Nil

Depends on the observer

Analytic methods

Requirement reuse

Stake holders do not participate

A lot of factors, including the codes are observed

The analyzing of codes and other existing documents will pave way for getting knowledge about the future system

Again, the code analyzing process will reveal the facts of domain

Definitely, this method needs makes the analysts to understand and identify the source of requirements

Nil

Synthetic methods

Appreciative Inquiry (AI)

involves collaboration between stakeholders and systems analysts to identify needs or requirements

Some parts of the process is based on the phenomenon of observations, hence this criteria is very crucial also Behaviors of people are observed

The strong Synthetic methods

practices, make people to give more ideas about the future systems,. Hence gaining knowledge about future system is one of the biggest advantage of this method. Synthetic methods are a strategy for purposeful change that identifies the best of "what is" to pursue dreams and possibilities of "what could be"

As the experts will be made to converse about the domain, it becomes very effective means to understand the domain. This type makes the analyst to unambiguously understand the domain

Synthetic methods generates volumes of data that provide great detail on the origins and consequences of local needs and resource constraints

It’s one of the most important features is the predictive and find a unique attributes.

Table : Comparison between categories of elicitation techniques.

Discussion

Based on the explanation about the various categories of elicitation methods, it is evident that, each and every category has its own advantages and disadvantages. The above table has clearly illustrated the pros and cons of each method. The conversational methods have a lot of advantages, such as the actual fact, which is very helpful for collecting loaded information about the requirements. Apart from unearthing opinions, the interview technique, indentifies feelings and goals of different individuals. With the help of interviews, it is easy to dig the details by asking follow-up questions. However the conversational methods have the following disadvantages: it is very difficult to master the skills of interviewing. The requirement elicitation depends a lot on the behavior and attitude of interviewer. Moreover, the interviewer has to be always unbiased. Even though we can collect lot information with the interview method, we cannot assure for getting meaningful information.

The benefits of observational methods can be summarized as follows; the observational methods are better option for fetching basic aspects of routine order. Furthermore, they offer crucial information for designing solution. Observational methods are very handy, when the development team lacks experience about product domain. However, there are some problems in practicing the observational methods. The most critical drawback is that, observational methods need a lot of time, and these techniques are not good choice, when schedule is tight. Similar to conversational methods, the observational methods are also very difficult to understand thoroughly. Furthermore, observational methods need sensitivity and responsiveness towards physical environment.

A lot of studies have discussed about the analytic methods and give the techniques that are related to this category as mentioned before, for example reusing the requirements of the existing system as common method of requirements elicitation. There are a lot of advantages of using the existing knowledge to develop the new product, which includes low cost and less time. Despite the disparities of type of users and stakeholders, this method is used very commonly particularly in developing user interfaces, database and security policies.

A lot of projects have failed due to the employment of inappropriate elicitation methods. One such example of big project failure is "Ariane 5 Flight 501 (European Ariane 5 expendable launch System)", where, the requirements specifications of Ariane 4 were reused. However, the flight path of Ariane 5 was very much different, hence, the system developed using the requirements of Ariane 4 was unable to handle the Ariane 5 flight path, this is one of the most important disadvantages of analytic methods, because the failure will be after testing the new software or system, so this methods depends on the old code or software that might completely or partially different from the new software.

The synthetic methods, it is particularly valuable for stakeholders such as, business owners and end users who might not understand the technical aspects of requirements, however, will better relate to a visual representation of the end product. Prototyping as a example may be an interactive screen, a mock-up, a navigation flow or a storyboard. Simple, throwaway prototypes might be executed in the initial stages of discovery, and more detailed, interactive prototypes might be done once business requirements have been identified.

Another example under the same category is appreciative inquiry technique (AI), in order to clearly understand this technique, it is crucial to dissect the terms and comprehend the meaning in the context: appreciation means to recognize and value the contributions or attributes of things and people around us. Inquiry indicates the exploration and identification of possibilities of novel ideas. When combined, this term means that by appreciating what is good and valuable in the present situation, it is possible to discover and understand the means to institute positive change for the future.

The positive aspects of appreciative inquiry are: this approach is constructed upon the advantages of an organization or group, it understands things that are well implemented, and consequently, we can have a very beneficial and optimistic influence on spirits, guarantee and value of individuals and groups, Contributors can become empowered and encouraged, because they feel valued. It is very easy to involve people, who do not generally get engaged in this kind of activity, due to the fact of the conversational style of questioning and specific focus on the participants. However the disadvantages of the appreciative inquiry are: it consumes time, needs periodic commitment, to motivate participants and occasionally we have to do additional works to get people out of the SWOT (strengths weaknesses, opportunities threat) mindset.

Conclusion