Eliciting requirements is an effort to get information from stakeholders and subject matter experts. Elicitation is not a step, it is a set of techniques that must be applied during the requirements phase of the Software Development Life Cycle. It is common to use the terms “gathering” and “eliciting” to refer to the same process. However, “eliciting more accurately describes the process of revealing not-so-observable requirements”, it consists in a planned and deliberate search, and gathering is more about taking what you see.
Projects tend to fail when the requirements are not well defined, this might happen because people involved in the project dont’t know what the real problem is. Here is a 10 step guide to detect the real problem.
So, you discovered the problem, now the application of elicitation techniques comes to action. The most common and effective techniques are:
- Interviews: It’s used frequently by business analysts, it has to be one-to-one and open ended questions.
- Brainstorming: This group technique takes place in two sequential activities. The first part consists in raising as many ideas as possible. The second part analyzes and organizes the ideas.
- Focus groups: They bring together knowledgeable interested parties to examine a topic. These groups tend to be expensive to make and are used most commonly in marketing.
- Requirements workshops: They bring together as broad a group of stakeholders, they have to keep the whole group involved.
- Tests: They can be static or dynamic. Static testing reviews requirements directly, while dynamic testing consists in testing the code with previously designed tests. The effectivity of dynamic testing relies on the quality of the test, if it’s not well developed, the project will fail.
- Project-related documents: It’s important to do background research that is not specific to the project.
- Observing: Developers elicit requirements
Continue reading "Elicitation and SRS"
