In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders. The practice is also sometimes referred to as "requirement gathering". The term elicitation is used in books and research to raise the fact that good requirements cannot 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 or not do (for Safety and Reliability). Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping. Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation process. Requirements elicitation is a part of the requirements engineering process, usually followed by analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements. The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process. In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation: Requirements quality can be improved through these approaches:

Guidelines

In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang:

Sequence of steps

In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence": However Goldsmith notes that identifying the real problem "is exceedingly difficult".

Complementary approaches

In 2008, Alexander and Beus-Dukic proposed a set of complementary approaches for discovering requirements: Alexander and Beus-Dukic suggested that these approaches could be conducted with individuals (as in interviews), with groups (as in focused meetings known as workshops, or via Electronic meeting systems), or from "things" (artifacts) such as prototypes.

Non-functional requirements

In 2009, Miller proposed a battery of over 2,000 questions to elicit non-functional requirements. Her approach is to build a stakeholder profile and then interview those stakeholders extensively. The questions are grouped into three sections, all focused on user needs: In 2013, Murali Chemuturi suggested the usage of Ancillary Functionality Requirements instead of Non-Functional Requirements as "Non-Functional" connotes "never functional". Second, these requirements in fact fulfill some requirements which are supportive to main or Core Functionality Requirements.