Lecture 4: Elicitation

This is the phase of requirements engineering where requirements are gathered.

Requirements Sources

There are 3 different kinds on requirements sources.

  • Stakeholders: people or organizations that (directly or indirectly) influence the requirements of a system
    • e.g. users of the system, operators of the system, developers, architects, customers, and testers
  • Documents: they often contain important information that can provide requirements
    • e.g. standards, legal documents, organization-specific documents, error reports of legacy systems
  • System in Operation: The legacy system + competing systems

Elicitation Techniques

The main goal of all elicitation techniques is to support the requirements engineer in ascertaining the knowledge and requirements of the stakeholders. How and when a technique can be applied depends on the given conditions.

Every project has its individual constraints and characteristics that make certain elicitation techniques more suitable than others. The most important factors when choosing a certain technique are:

  • The distinction between conscious, unconscious, and subconscious requirements that are to be elicited
  • The time and budget constraints, as well as the availability of the stakeholders
  • The experience of the requirements engineer with a particular elicitation technique
  • The chances and risks of the project

Survey Techniques

Aim at eliciting as precise and unbiased statements as possible from stakeholders regarding their requirements. Survey techniques are usually driven by the requirements engineer because she asks the questions. They include:

  • Interview: asks predetermined questions to one or more stakeholders and documents the answers

    • An experienced interviewer ensures the completeness of the answers (follow-up questions)
    • very time-consuming

  • Questionnaire: use of open and/or closed questions (MCQ)

    • If there is a large number of participants that must be surveyed, an online questionnaire is a viable option

    • can elicit a magnitude of information in a short amount of time and at low costs

    • can be employed only to gather requirements that the requirements engineer already knows or conjectures

    • often tricky and time-consuming; requires thorough knowledge of the domain in question

    • As opposed to interviews, do not provide immediate feedback

Creativity Techniques

Creativity techniques serve the purpose of developing innovative requirements, delineating an initial vision of the system, and eliciting excitement factors.

They are usually not well-suited for establishing fine-grained requirements for the system behavior. Examples include

  • Brainstorming: ideas are collected within a certain time frame, usually in groups of 5 to 10 people.
    • ideas are documented by a moderator without discussing, judging, or commenting on them at first
    • use ideas of other participants to develop new original ideas or to modify existing ideas
    • After collection, ideas are subjected to a thorough analysis
    • effective when a large number of people from different stakeholder groups are involved
    • A large number of ideas can be collected in a short amount of time
    • Less effective when the dynamics of the group are muddled, or when participants with very varied levels of dominance are involved
  • Brainstorming Paradox: modification of regular brainstorming in that events that must not occur are collected
    • risks can be identified early on, and countermeasures can be developed
    • Advantages and disadvantages are identical to brainstorming
  • Change of Perspective: One example is the 6 hats, where each hat represents a certain perspective that is adopted by each of the participants.
    • resulting solutions approach the problem from different standpoints
    • stakeholders who are very convinced of their own opinion is persuaded to adopt a different standpoint
    • useful when stakeholders can only express their knowledge in a biased way
    • cannot be applied if the requirements require a fine-grained level of detail

Document-Centric Techniques

Document-centric techniques reuse solutions and experiences made with existing systems.

Document-centric techniques should be combined with other elicitation techniques so that the validity of the elicited requirements can be determined and new requirements for the new system can be identified.

Examples include:

  • System archaeology: extracts information required to build a new system from the documentation or implementation (code) of a legacy system or a competitor’s system

    • applied when explicit knowledge about the system logic has been lost
    • leads to a large amount of very detailed requirements
    • very hard to apply
    • the only technique that can ensure that all functionalities of the legacy system will be implemented in the new system

  • Perspective-Based: applied when documents need to be read with a particular perspective in mind

    • Ignores document aspects that do not pertain the current perspective

    • allows for an analysis that is strictly focused on particular parts of existing documentation

  • Reuse: Reusing requirements that have been previously compiled and brought upto a certain quality standard

    • e.g. login-security, online payment

    • significantly reduces the costs involved with the elicitation procedures

    • original requirements have to be stored to be reused

Observation Techniques

Observation techniques are helpful when domain specialists are unable to spend the time needed to share their expertise with the requirements engineer.

During observation, the requirements engineer observes the stakeholders while they go about their work.

Observation techniques are well-suited to elicit detailed requirements

Examples include:

  • Field Observation: requirements engineer is on location with the specialist or the users of the system and observes and documents the processes and operational procedures carried out

    • can be further aided by audio and video recordings

    • well-suited for operational procedures that are difficult to express verbally

  • With Apprenticing: the requirements engineer must actively learn and perform the procedures of the stakeholders

    • The requirements engineer is encouraged to question unclear and complex operational procedures to gain domain experience