Requirements Elicitation

Requirements elicitation is one of the crucial tasks of the requirements engineering process, as it allows one to discover which requirements the users want to see incorporated into the system at hand. The core content of this chapter is the description of some techniques that can be applied to elicit requirements. The chapter presents a non-exhaustive, but sufficiently representative, set of requirements elicitation techniques that can be used in engineering projects. Additionally, the chapter discusses a generic process that can be adopted for eliciting requirements and it describes some of the potential stakeholders of the system.

1. 1.

   There are other perspectives about prototyping, but only this one is assumed here for simplicity in the discussion.

Authors and Affiliations

1. Departamento de Informática, Universidade do Minho, Braga, Portugal

   João M. Fernandes

2. Departamento de Sistemas de Informação, Universidade do Minho, Guimarães, Portugal

   Ricardo J. Machado

Corresponding author

Correspondence to João M. Fernandes .

Further Reading

To find out more about requirements elicitation techniques, we recommended reading (Zowghi and Coulin 2005), which presents an excellent summary and comparison. Goodwin (2009) discusses, in a product design perspective, various techniques that can be useful for requirements elicitation. Macaulay (1996) presents some elicitation techniques divided in three groups: (1) approaches for capturing political and organisational requirements, (2) approaches based on group sessions for facilitating the communication among the involved persons, and (3) interactive approaches for understanding the work of the users.

Some ideas about how to conduct interviews can be obtained in journalism and social communication books, for example, (Fleisher and Gordon 2010). The example of an interview, presented by Goodwin (2009, Chap. 8, pp. 155–181), deserves to be analysed. To learn more about how to prepare surveys and questionnaires, many books can be consulted, for instance, (Brace 2013; Gillham 2008).

There are a lot of books about how to develop software with objects. Mandatory books are (Booch et al. 2007; Budd 1997; Coad and Yourdon 1991; Meyer 1988; Rumbaugh et al. 1991). These object-oriented development approaches are, from an historical point of view, a natural evolution of the structured analysis approaches, since they adopt many of their principles and introduce others with the aim of solving some of their problems and weaknesses. Although the use of structured approaches has no longer the same popularity that was witnessed in the 1980 decade, the interested reader should consult some of the landmark works of this methodological trend that left some interesting ideas, concepts and practices on the way software is developed nowadays. Thus, (DeMarco 1978; Gane and Sarson 1979; Page-Jones 1980; Davis 1983) are worth reading.

Different types and forms of prototypes, including active and passive, high- and low-fidelity, horizontal and vertical, are discussed by Constantine and Lockwood (1999, Chap. 10) and (Stevens et al. 1998, Chap. 10). Another interesting book, authored by by Warfel (2009, Chap. 10), provides a mixture of theory with many practical guidelines on prototyping for user experience.

There are some goal modelling approaches. The most popular are KAOS (Dardenne et al. 1993) and i* (Yu 1997). A systematisation of the available approaches, made by Horkoff and Yu (2011), provides some clues about which criteria to use for selecting the most appropriate approach in a given situation.

Gottesdiener (2002) presents and discusses how workshops can be used as a technique for eliciting requirements based on group dynamics. A workshop is a structured meeting in which a group of stakeholders carefully selected works jointly to define, create, and refine the user requirements. The book is useful not only for software-intensive systems, but also for other types of engineering systems.

The book organised by Alexander and Maiden (2004) is a reference in the subject of scenarios and includes various techniques that can be used in business contexts. The utilisation of storyboards in cinema is explained by Rabiger and Hurbis-Cherrier (2013, pp. 307–308) and Simon (2007).

Exercises

Exercise 5.1 (Naveda and Seidman 2006, pp. 63–64) Imagine that a software engineer, who concluded recently his degree at a given university, is leading a requirements engineering team for a project to improve the software application that permits students to enroll and register in degrees offered by that university. Which of the following requirements elicitation techniques are adequate for capturing the typical and atypical activities involved in the use of the application?

(a) Observation, (b) Prototypes, (c) Interviews, (d) Surveys.

Exercise 5.2 (Naveda and Seidman 2006, pp. 69–70) For the system indicated in the previous question, during the requirements elicitation process, some students were interviewed. They have indicated the functionalities that they would like to see incorporated in the final solution. Afterwards, the client has requested to remove some of the requirements proposed by the students. Which of the following arguments is the less strong for justify the removal of those requirements?

1. 1.

   The requirements from the students are not representative of those from the student population.

2. 2.

   The requirements from the students are ambiguous and cannot be tested.

3. 3.

   The requirements from the students are contrary to the interests of the client.

4. 4.

   The client does not consider the students as system stakeholders.

Exercise 5.3 (Naveda and Seidman 2006, pp. 51–52) Which of the following arguments is the strongest to justify the use of the observation technique in a company?

1. 1.

   Direct interaction with users permits a continuous discussion about the various forms of work.

2. 2.

   Observation permits one to see not just the normal workflow, but also less typical situations.

3. 3.

   Observation is a traditional technique for capturing requirements and the company has experience in using it.

4. 4.

   Observation aids in the observer/observed interaction, when they exchange ideas in real-time.

Exercise 5.4 Suppose that the analysts of a software product project have a reduced knowledge about the respective domain. Which requirements elicitation techniques are the most appropriate in that case?

Exercise 5.5 Explain the main reasons why the combined use of ethnographical techniques with prototyping is useful for eliciting requirements.

Exercise 5.6 Identify the problems that are present in the following questions that are part of a questionnaire for collecting information about a software application:

1. 1.

   Why do you prefer the menus on the left rather than the right side?

2. 2.

   Do you normally use the same password on different systems?

3. 3.

   Where do you download email messages?

   \(\Box \) at home       \(\Box \) at the office       \(\Box \) at school

4. 4.

   When you go to the canteen, do you drink orange juice and eat soup?

   \(\Box \) yes       \(\Box \) no

5. 5.

   How many hours did you sleep last night?

   \(\Box \) 9–12       \(\Box \) 6–8       \(\Box \) \(<\)6       \(\Box \) \(>\)12

6. 6.

   How many email messages do you receive on average each day?

   \(\Box \) \(<\)30       \(\Box \) 30–50       \(\Box \) 50–70       \(\Box \) \(>\)70

Exercise 5.7 Identify all the stakeholders for the following systems:

1. 1.

   lifts in a hotel (see Illustration 5.1);

2. 2.

   commercial plane;

3. 3.

   train station;

4. 4.

   web application to reserve rooms in hotels and B&Bs;

5. 5.

   web application for buying tickets for musical concerts and cultural events.

Exercise 5.8 Select an engineering system in which you are currently working. If it is not possible to select a system, imagine that you are involved in a project for developing a system for a logistics company (in which trucks are used). The objective of that system is to permit truck drivers to receive radio messages with delivery instructions.

1. 1.

   List the types of stakeholders in the system.

2. 2.

   List the job titles and roles of the persons that you consider relevant to interview for each type of stakeholder identified in question 1.

3. 3.

   If you have considered a real project, speak to the persons listed in question 2; ask them whom they interact with (for instance, clients and suppliers) to achieve their business objectives. Exclude persons that not do not seem relevant.

4. 4.

   Repeat the previous steps, until the list of stakeholders stabilises.

Exercise 5.9 Consider the following situations in which you were supposed to apply the observation technique. Answer and justify the questions.

1. 1.

   You are developing a product to help a pastry business. Do you think that it is ethical to go to a competitor, sit down at a table, ask for a coffee, and observe the customers and the employees?

2. 2.

   You are developing a game for teenagers. Do you think that it is ethical to go to a school to observe how they behave? And what is your opinion about approaching some of them and asking some questions?

3. 3.

   You are developing a product for a hospital. Do you think that it is ethical to observe the behaviour of the persons in the waiting room? do you think that it is ethical to attend the appointments that patients have with their doctors? And what is your opinion about approaching some of them (patients or doctors) and asking some questions?

Exercise 5.10 (Gregory et al. 2013) The objective of this exercise is to gain some experiment in interviewing someone and taking notes.

before :

Make an appointment about ‘mobility’ (or another topic that matches your academic or professional interests) with a person that you know (friend, family member, or co-worker). Prepare a set of questions to ask the interviewee.

during :

During one hour, conduct an interview. The topic is mobility, which the interviewed person may interpret in a variety of forms and for which you can decide how to ask the questions. Develop the interview as a conversation, using the answers to conduct it in a natural way. Listening and understanding the perspective of the person are fundamental for the success of the interview. Don’t record the interview, but take notes of the most important terms and sentences.

after :

Describe (3–4 pages) the interview, including: your name; a pseudonym of the interviewee, sex, age and occupation; a short description of the scenario in which the interview took place. Include your pre-prepared questions and describe the conversation. Conclude with your thoughts about the interview: the interactions and the dynamic that was established with the interviewed person, her analysis of the addressed topics, and any other observations that may seem pertinent.

Exercise 5.11 (Gregory et al. 2013) The objective of this exercise is to experiment observing the behaviour of the persons in a given public place and to take notes.

before :

Choose a public place that seems interesting to observe. Examples of possible places are: airport, train station, car park, hospital waiting room, post office, bank, supermarket, canteen, bar, gymnasium, museum, library. The local should allow you to observe and take notes without being disturbed.

during :

For a time span of 60 min, observe and register the movements, interactions, sounds, space and everything that captures your attention. Take short notes while you observe. If someone asks you what you are doing, tell her that you are doing a school project.

after :

Elaborate on the material that you have collected. You are expected to write at least three pages. Justify the place you selected and present the respective blueprint. Describe what you have observed (indicating who, where, when, how) and provide your own interpretation. Conclude the text with your interpretation of a rule that is applicable to the local. What patterns were you able to identify? what exceptions were detected? are there persons that behave distinctly from the others?

Reprints and permissions

© 2016 Springer International Publishing Switzerland

Policies and ethics