• Table of Contents

Introduction

As we have discussed requirement inception last week and briefly touched based on requirement elicitation. For Week 4, we will dive more deep regarding the topic of requirement elicitation — more specifically how to prepare for one and conduct one.

Definition

We briefly covered this in Week 2, but to give a quick recap:

• The bare bones definition of requirement elicitation is basically to understand how the system works from users, stakeholders, or other sources.
• A more formal definition would be to acquire (or elicit) all the relevant knowledge needed to produce a requirements model of a problem domain.

The problem domain consists of those that are affected by the problem in question or that may be impacted by a solution to that problem. That is to say, one should not care much about other aspect that are not affected by it.

Figure 4.1 The process of user requirements elicitation.

The requirements elicitation process is aimed at gathering all the information about business and project needs and objectives, which is described in Figure 4.1. As you can see, each step has feedback loop, in which we can go back to the previous step if needed.

Elicitation Techniques

There are many elicitation techniques on the market.

• These techniques are quite important for obtaining critical information from Subject Matter Experts (SMEs) and stakeholders.
• There isn’t a universally methodology that everyone uses, as there maybe different techniques suited for certain situation.

We can classify these into two categories.

1. Before software engineering became mainstream, classic requirements elicitation techniques have been used in the field for a long time.
2. Now, the modern requirements are the new and improved elicitation technique.

The key difference between the two is a shift towards more user-centered and data-driven approaches, while still retaining the core principles of identifying and documenting the requirements.

Classic Requirements Elicitation Techniques