In requirements engineering, requirements elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders. [1] The practice is also sometimes referred to as requirements gathering.
The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brain storming, use cases, role playing and prototyping.
Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements.
Christel and Kang [CRI92] identify a number of problems that help us understand why requirements elicitation is difficult: Problems of scope. The boundary of the system is ill-defined or the customers/ users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives. • Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable. • Problems of volatility. The requirements change over time. To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner. Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation, which are summarized in the following steps: • Assess the business and technical feasibility for the proposed system. • Identify the people who will help specify requirements and understand their organizational bias. • Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed. • Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built. • Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings). • Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded. • Identify ambiguous requirements as candidates for prototyping. • Create usage scenarios to help customers/users better identify
References
- ^ Requirements Engineering A good practice guide, Ian Sommerville and Pete Sawyer, John Wiley and Sons, 1997
 |
This software engineering-related article is a stub. You can help Wikipedia by expanding it. |
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
