Requirements elicitation

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.

Problems

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]

  • 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 or use cases to help customers/users better identify key requirements

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 2009, 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
  • Alexander, Ian F.; Beus-Dukic, Ljerka (March 2009). Discovering Requirements: How to Specify Products and Services. John Wiley. ISBN 978-0-470-71240-5.
  • Goldsmith, Robin F. (2004). Discovering Real Business Requirements for Software Project Success. Artech House. ISBN 1-58053-771-5.
  • Miller, Roxanne E. (2009). The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements Into Focus; Proven Techniques to Get the Right Stakeholder Involvement. MavenMark Books. ISBN 978-1-59598-067-0.
  • Sommerville, Ian; Sawyer, Pete (May 1997). Requirements Engineering: A Good Practice Guide. John Wiley. ISBN 0-471-97444-7.

References
  1. Requirements Engineering A good practice guide, Ramos Rowel and Kurts Alfeche, John Wiley and Sons, 1997
  2. Kusiak, Jan. "How To Interview Your Boss". IRM Training.
  3. Christel, Michael and Kyo C. Kang (September 1992). "Issues in Requirements Elicitation". Technical Report CMU/SEI-92-TR-012. CMU / SEI. Retrieved January 14, 2012.
  4. "PMI Requirements CoP Webinar on Requirements .Quality".
  5. Sommerville and Sawyer, 1997.
  6. Goldsmith, 2004. Page 12
  7. Alexander and Beus-Dukic, 2009.
  8. Miller, 2009.
  9. Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5. S2CID 19818654.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.