Tabular Elicitation Techniques

In this category, we use tables to capture and note stakeholders requests to be met in the system. The nature of these technique makes it more precise and unambiguous. Two techniques under this category are widely used: decision tables and state tables.

A. Decision tables
According to [1], this technique is common tabular techniques. Rows  represent conditions, columns represents rules. This technique is useful when capturing business workflow or rules. One famous example is the tax tables [irs.gov], in the table rows are cases, while columns are conditions such as (single, marrid, etc). 



B. State tables
State tables is a technique that uses the idea of state machine (in computer science) to capture the process (or workflow). As state machines, only one start point is allowed, and one or more final state. Although book[1] classified this as elicitation techniques, I only can see this as modeling technique.

Quality Function Deployment (QFD) Method

QFD was developed by Mizuno and Akao in 1990. QFD goal is to identify customer needs to be translated into the product design. According to QFD Institute [http://www.qfdi.org/], QFD can do the following:

• Seeks customer needs spoken and unspoken.
• Discover qualities that impress the customer.
• Translate the above into design characteristics.
• Deliver product quality to achieve goals and customer satisfaction.

currently, QFD is often a part of Six sigma program[1].

Ethnographic Techniques (Surveys and Interviews)

Ethnographic Techniques are techniques originated from ethnographic research which focuses its effort on studying specific community or culture. The most common ways to conduct this type of elicitation techniques is through interviews and surveys. This method is very useful when studying large population where statistical analysis is used to represent the entire population.

Kano Modeling
Kano modeling is a survey model. According to [1] it is the most common survey method to analyze customer preferences in system features. Kano modeling has three variables: one-dimensional, expected, and attractive quality.

• One-dimensional (or linear quality) is when a system feature increases linearly with the potential customer value to the product. Example [1], in refrigerators, the more energy efficient, the more likely for customers to buy it.
• Expected quality is a feature that is essential to the successful of system.
• Attractive quality is a non required feature of the system, however if it was added it would give a good reason for users to use your system. Some attracted quality can be changed into expected with time, for example, cell phone camera used to be attracted but now its an expected feature.

One good fact about Kano modeling is that it is sensitive to the cultural differences. This means that values can change between different cultures and countries, and even states.

Surveys and interviews in general can capture the emotional and cultural responses and preferences to the end-users.

Note: Interviews technique is explained in this blog entry.

Brainstorming

Brainstorming Sessions are a common techniques to elicit stakeholders initial requirements for a system. Typical session would include many stakeholders to think and discuss the needed system together. This technique needs an experienced facilitator to manage discussions and conflicts between stakeholders. Typically, such sessions can take between one to two days [1,2].
Session time and duration should be agreed on before the start of the session. In the session, participants may start throwing ideas that they think are important to the product, facilitator can use sticky notes to note every idea on the board. The facilitator can use the following flow:

1. Allow everyone to bring up their ideas on the upcoming system (even if they're redundant).
2. group the ideas into different groups, and remove related ideas
3. assign ideas into categories with participants agreement (or the majority of them)
4. break brainstorming group into multiple groups to study in details each category.
5. in each group, ideas will be expanded and prioritize.
6. the meeting is concluded with the results being presented to the whole group and agreed on
7. If customer was not involved, further session might be needed.

The figure below gives an abstract view of the process:

Goal models

One important step in requirements elicitation is the identification of business goals [1]. This step can be ignored if not needed, however in most cases since business people are the driving force for software projects, their goals needs to be accommodated and put in mind when requirements are elicited. Goal modeling is a common techniques to elicit business goals. Goals can be break down into different levels. Typically, the higher level of goals would be more abstract and general, while lower level of goals would be more specific. In other words, the more levels you break goals, the more details you get. Goals can be conflicted with each other, thus once goals are collected it should be followed by a refinement step where those nonfunctional requirements can bring some important issues in regard to the system requirements. Goal model can be as simple or as complex as it needed. No standard for the level of details, it just the current need drive the modeling.
Another approach to use goal model is to use it along with quality assessment methods (QAMs). QAMs are used to identify identify the quality goals that meets business goals. The goal behind using QAMs with goals models is to make sure that important nonfunctional requirements are not missed. Also, to make sure that nonfunctional requirements can be tested.

The following figure contain a simple example of a simple goal model

Requirements elicitation

requirements elicitation: is the process of identifying and understanding the needs and constraints for a system that can be transformed into manageable requirements that meets stakeholders expectations [1].

Elicitation is sometimes confused with the analysis. Elicitation is to interact with stakeholders to write down their needs, while in the analysis, requirements are refined to meet stakeholders expected needs into more formal refined specification [1].

I will write different blog posts about different elicitation techniques. I've used the following sources books:
[1] Berenbach, Brian, Daniel J. Paulish, Juergen Kazmeier, and Arnold Rudorfer. "Chapter 3 - Eliciting Requirements". Software & Systems Requirements Engineering: In Practice. McGraw-Hill/Osborne. © 2009.
[2] Weese, Susan, and Terri Wagner. CBAP/CCBA: Certified Business Analysis Study Guide. Sybex. © 2011.
[3] Jonasson, Hans. "Chapter 7 - Ways to Gather Requirements". Determining Project Requirements. Auerbach Publications. © 2008.

I will refer to each source with its number between brackets.

Robot tracing (2005)

Adams, J. A. (2005). Human-Robot Interaction Design:Understanding User Needs and Requirements, In Proceedings of the 2005 Human Factors and Ergonomics Society 49th Annual Meeting, September 2005.


In contrast to the previous paper (Robot), this paper uses robots to help in the safety and rescue missions. Author was working in cooperation with the Nashville Metro Police department's Bomb Squad and the Nashville Metro Fire Department’s HAZMAT team. Their aim is to let robots do the job instead of humans. Another goal is to advance Human-Robot Interaction (HRI) research by allowing single human to supervise large number of robots (up to 100 robots). With the current robot design, human can only supervise up to 5 robots at a single time! Author argue that the current robot design needs to be changed to accommodate that initiative. Later, they discussed the initial movement for to change the design of robots to be a Human Centred Design (HCD).

For their multi-robot design to be controlled by single human, they needed to employee Situation Awareness (SA) when designing their robots. SA is a representation of the human understanding of the current situation around him/her and the upcoming consequences in the future.

They used GDTA to identify robot operator to identify: basic goals, major goals, and SA requirements. In their methodology, they started by obtaining HRI SA requirements as its the core part of this work. In order to do that, they used GDTA and SA principals to help them in identifying and modeling the UCD and SA requirements. Since they're working in the field of CBRNE search and rescue domain, they started in two directions: (a) interviewing domain experts to gain a generic understanding of the rescue field, and (b) exploring the supporting document that was provided to them by Nashville Metros Bomb Squad. The previous directions helped them to identified the basic high-level goals and action steps in this field. Their next future step was to use their resulted high-level requirements analysis, and conduct a more focused interviews, and observations to sterengthen their requirements and detailed them.

This work still in its early stages, thus a preliminary results were only discussed on this paper. They provided a goal hierarchy for the communication, in addition to the special task force tasks breakdown. Author, discussed the communication as an essential part of their analysis, he indicated that communication can be very different from a robot controlled to human. For example, a human does not need to communicate while navigating a building, while on the other hand, robot needs to do so.