Requirements elicitation explained

In requirements engineering, requirements elicitation is the practice of researching and discovering the requirements of a system from users, customers, and other stakeholders.[1] 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.[2] 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:[3]

  1. 'Problems of scope'. The boundary of the system is ill-defined or the customers/users specify unnecessary technical details that may confuse, rather than clarify, overall system objectives.
  2. 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.
  3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:[4]

  1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
  2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.
  3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
  4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
  5. Documenting dependencies. Documenting dependencies and interrelationships among requirements.
  6. Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.

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:[5]

Sequence of steps

In 2004, Goldsmith suggested a "problem pyramid" of "six steps which must be performed in sequence":[6]

  1. Identify the real problem, opportunity or challenge
  2. Identify the current measure(s) which show that the problem is real
  3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it
  4. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly
  5. Define the business "wants" that must be delivered to meet the goal measure(s)
  6. Specify a product design how to satisfy the real business requirements

However Goldsmith notes that identifying the real problem "is exceedingly difficult".[6]

Complementary approaches

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.[7]

Non-functional requirements

In 2009, Miller proposed a battery of over 2,000 questions to elicit non-functional requirements.[8] 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:[8]

  1. Operation: how well does the [needs editing] use?
  2. Revision: how easy is it to correct errors and add functions?
  3. Transition: How easy is it to adapt to changes in the technical environment?

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. [9]

Bibliography

See also

Notes and References

  1. Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997
  2. Web site: Kusiak. Jan. How To Interview Your Boss. IRM Training.
  3. Web site: Issues in Requirements Elicitation . CMU / SEI . Technical Report CMU/SEI-92-TR-012 . September 1992 . January 14, 2012 . Christel, Michael and Kyo C. Kang.
  4. Web site: PMI Requirements CoP Webinar on Requirements .Quality.
  5. Sommerville and Sawyer, 1997.
  6. Goldsmith, 2004. Page 12
  7. Learning How To Discover Requirements. Beus-Dukic. Ljerka. Alexander. Ian. 2008. IEEE. 2008 Requirements Engineering Education and Training. 12-14. Barcelona, Spain. 10.1109/REET.2008.3.
  8. Miller, 2009.
  9. Book: 10.1007/978-1-4614-5377-2. Requirements Engineering and Management for Software Development Projects. 2013. Chemuturi . M. . Murali Chemuturi. 978-1-4614-5376-5. 19818654.

This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Requirements elicitation".

Except where otherwise indicated, Everything.Explained.Today is © Copyright 2009-2024, A B Cryer, All Rights Reserved. Cookie policy.