Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.
[2] For example, an important first meeting could be between software engineers and customers where they discuss their perspective of the requirements.
In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:[3] Requirements quality can be improved through these approaches:[4] In 1997, Sommerville and Sawyer suggested a set of guidelines for requirements elicitation, to address concerns such as those identified by Christel and Kang:[5] In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence":[6] However Goldsmith notes that identifying the real problem "is exceedingly difficult".
[6] In 2008, Alexander and Beus-Dukic proposed a set of complementary approaches for discovering requirements:[7] 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.
The questions are grouped into three sections, all focused on user needs:[8] In 2013, Murali Chemuturi suggested the usage of Ancillary Functionality Requirements instead of Non-Functional Requirements as "Non-Functional" connotes "never functional".