requirement elicitation techniques in software engineering
Requirement elicitation is the activity which software requirements are discovered, articulated, and revealed from the stakeholders or derived from the requirements.
Sources of requirements elicitation may be system requirements documentations, customers, end-users, domain specialists or market analysis.
Although it is important that all the stakeholders are involved, it is particularly important that the be involved. The users know what the system should be do and have the domain expertise. On the other hand, the users have some problems articulating their needs.
Ways to get the user involved.
Various methodologies/techniques have been developed to involve users. Each methodology/technique varies in the level of user involvement. The range of variation can be classified into three main styles.
In this design, decision making power is in the hands of the developers and users the sources of information with little or no influence.
The common techniques used in this style.
Representative Design
In this, user representatives are involved in the design formulation and decision-making. The common techniques of this style are
Consensus Design
System development is the prime responsibility of the user and thus users are continually involved throughout the design process. The user are the driving force in this style.
Techniques of this style are
Requirement Elicitation Process
A very common process of requirement elicitation is:
- Identify the all stakeholders who could be source of requirements.
-Users
-Customers
-Domain experts
- Ask relevant questions in order to gain an understanding of the problem, issues and constraints.
- Analyze the information looking for the conflicts, ambiguities, inconsistencies, problems or unresolved issues.
- Confirm your understanding of the requirements with the stakeholders.
- Create requirements statements.
Problems in Requirements Elicitation
Problems that are generally encountered during requirements elicitation process.
- Users may know what they want, but are unable to articulate the requirements.
- User may not know what is technological capable and may not consider what is possible.
- User may have reasons for not wanting to communicate their requirements.
- Users and Developers sometimes don’t speak the same language.
- No single user has all the answers; the requirements will not likely come from many sources.
- Developers may not have the necessary skills to get the requirements from the users.
- Developers may be unable to develop a report or understanding the users needs.
- Developer sometimes don’t appreciate the needs or concerns of the users.
- Developer sometime tends to bulldoze the users into agreeing on the developers requirements.
Social Aspects of Requirements Elicitation
Requirements elicitation is very much a social activity and thus requires an understanding of:
- Personality types
- Cultural Issues
- Organizational Issues
Requirement elicitation supporting techniques
Only two main supporting techniques of requirements elicitation.
Prototyping
- To elicit the requirements by allowing the user to see what the requirements engineer thinks he user needs.
- To try clarifying poorly understood requirements.
- To try to understand how the user actually does his/her work.
- To develop the user interface(UI).
User Scenario
User scenarios are an extremely powerful mechanism to use. These are also known as: use-case analysis, use-case scenarios, or operational scenarios. User scenarios are a description between the user and the system. It describes how the user will interact and what occurs during that interaction.
Originally published at https://www.csmates.com.
