H3 Eliciting Requirements

Question 1

3 Eliciting Requirements

Answer 1

basis for elicitation = knowledge gathered about system context ( which includes the requirements sources to be analyzed/queried )

Question 2

( 3.1 Requirements Sources )

Three types of requirements sources

Answer 2

1. Stakeholders ( ex users, operators, devs, architects, customers, testers )
2. Documents ( ex, standards, legal documents, organization specific documents like error reports etc )
3. Systems in operation ( can be legacy or predecessor systems as well as competing systems )

Question 3

( 3.1.1 Stakeholders and Their Significance )

Significance of stakeholders

Answer 3

It is the task of the requirements engineer to gather, document, and consolidate the partially conflicting goals and requirements of different stakeholders

Question 4

3.1.1 Consequences of unconsidered stakeholders

Answer 4

= requirements may remain undetected

these overlooked requirements will enter the picture in the form of change requests during system operation - high costs!!

Question 5

3.1.1 Stakeholder lists provide overview

Answer 5

technique for stakeholder identification is maintaining checklists ( updated often and completely to avoid missing project goal or rise in fixing issue costs )

Question 6

( 3.1.2 Handling Stakeholders in the Project )

Managing stakeholders

Answer 6

use tables and spreadsheets with at least:

• name,
• function (role),
• additional personal and contact data,
• temporal and spatial availability during the project progress,
• relevance of the stakeholder,
• area and extent of expertise of the stakeholder,
• stakeholder’s goals and interests regarding the project.

Question 7

3.1.2 Making collaborators out of the affected

Answer 7

Periodic status updates and continuous involvement turns ‘affected’ into collaborators

Question 8

3.1.2 Individual “contracts” with the stakeholders

Answer 8

stakeholders not given enough attention = overly critical toward project

REr = assist PM in convincing stakeholders of benefit of project ( despite their satisfaction with previous system, fear of change, negative bias due to previous experiences )

To avoid misunderstandings and disputes regarding competence, it is useful to formally agree on the tasks, responsibilities, and managerial authority as well as to determine individual goals, communication paths, and feedback loops that can be used by the stakeholders

individual agreements need to be signed off by managers!! ( depending on organization culture verbally or formally in writing )

Question 9

3.1.2 Obligations and privileges of the stakeholders

Answer 9

The stakeholders

1. introduce the REr to the application domain,
2. supply the REr with requirements,
3. document requirements assiduously,
4. make timely decisions,
5. respect the REr’s estimates of costs and feasibility,
6. prioritize requirements,
7. inspect the requirements that the REr documents, such as prototypes, etc.,
8. communicate changes in requirements immediately,
9. adhere to the predetermined change process,
10. respect the requirements engineering process that has been instated

Question 10

3.1.2 Obligations and privileges of the REr

Answer 10

The requirements engineer :

1. speaks the language of the stakeholders,
2. becomes thoroughly familiar with the application domain,
3. creates a requirements document,
4. is able to get work results across (e.g., by means of diagrams and graphs),
5. maintains a respectful relationship with any stakeholder,
6. presents her ideas and alternatives as well as their/her realizations,
7. allows stakeholders to demand properties that make the system user friendly and simple, -
8. ensures that the system satisfies the functional and qualitative demands of the stakeholders

Question 11

3.1.2 Elicitation techniques determine communication and process

Answer 11

the REr :

1. plans and organizes the communication paths
2. drafts a structured schedule for the requirements engineering activities that are to be performed in collaboration with the stakeholders

Question 12

( 3.2 Requirements Categorization According to the Kano Model )
Influence of the requirements on satisfaction

Answer 12

satisfaction categories: :

1. dissatisfiers
   - properties of the system that are self-evident and taken for granted
2. satisfiers
   - are explicitly demanded system properties
3. delighter
   - properties that the stakeholder does not know or expect and discovers only while using the system—a pleasant and useful surprise

As time goes by, delighters turn into satisfiers and finally into dissatisfiers ( user = accustomed to properties of system )

Question 13

3.2 Dissatisfiers

Answer 13

= subconscious requirements

must be fulfilled in any case ( otherwise dissappointed/dissatisfied stakeholders massively!! )

dominantly influenced by existing systems

elicit through = observation and document-centric techniques

Question 14

( 3.3 Elicitation Techniques )

Requirements elicitation: no universal method

Answer 14

tailor reqs elicitation process to given conditions/constraints to completely/comprehensibly elicit reqs

Question 15

( 3.3.1 Types of Elicitation Techniques )

Influencing factors regarding the choice of elicitation techniques

Answer 15

unique project characteristics/constraints but always some elicitation techniques that are compatible!!

influencing factors when choosing:

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

Question 16

3.3.1 Risk factors

Answer 16

first step when choosing elicitation techniques = perform an analysis of constraints critical to the project ( risk factor identification ! )

risk sources =
1. human
+ Assure high quality communication by determining :
- type of req
- desired level of detail
- expereince of REr AND stakeholder with diff elicitation techniques )

+ Social, group-dynamic, and cognitive capabilities of the stakeholders also influence the choice of suitable elicitation techniques significantly.

+ Is elicited knowledge explicit (consciously known) by each individual stakeholder or is it implicit or unconscious (i.e., covert) ?

2. organizational
   - distinction between fixed price contracts and service contracts,
   - whether the system to be built is a new development or an extension of a legacy system,
   - spatial and temporal availability of the stakeholders.

OPERATIONAL INFLUENCES OF THE CONTENT
If the system is very complex, it is advisable to employ a structuring approach during elicitation in order to deconstruct the operational contents into understandable parts.

3. professional influences

Combine techniques with regard to your particular situation to lower risks.

• Desired level op detail :
  1. Abstract requirements can be elicited rather well using creativity techniques.
  2. Abstract requirements can be elicited rather well using creativity techniques.
  3. detailed requirements can be elicited well by making use of document centric techniques, i.e., techniques that use existing documents ( because arbitraty level of detail can be extracted )

It is advisable to combine different techniques because this minimizes many of the risks inherent to the project.

Question 17

( 3.3.2 Survey Techniques )

Eliciting explicit knowledge

Answer 17

Survey techniques aim at eliciting as precise and unbiased statements

assumptions when using:

• respondent is capable of explicitly expressing his or her knowledge
• respondent is committed to investing time and effort for the elicitation

Driven by REr therefore might forget, superseed or disregard stakeholder concerns

Types:

1. Interview
   - predetermined questions + questions that arise + document answers
   - might uncover subconscious reqs through clever questioning
   - very time consuming
2. Questionnaire
   - can elicit a magnitude of information in a short amount of time and at low costs

disadvantages:
- can only gather reqs the REr already knows or suspects
- creating good one is time consuming and tricky
- requires flawless knowledge of domain + psychological guidelines for creating questionnaires
- do not provide immediate feedback

Question 18

( 3.3.2 Survey Techniques )

Eliciting explicit knowledge

Answer 18

Survey techniques aim at eliciting as precise and unbiased statements

assumptions when using:

• respondent is capable of explicitly expressing his or her knowledge
• respondent is committed to investing time and effort for the elicitation

Driven by REr therefore might forget, superseed or disregard stakeholder concerns

Types:

1. Interview
   - predetermined questions + questions that arise + document answers
   - might uncover subconscious reqs through clever questioning
   - very time consuming
2. Questionnaire
   - can elicit a magnitude of information in a short amount of time and at low costs

disadvantages:
- can only gather reqs the REr already knows or suspects
- creating good one is time consuming and tricky
- requires flawless knowledge of domain + psychological guidelines for creating questionnaires
- do not provide immediate feedback ( faulty formulation only becomes apparent after evaluation )

Question 19

( 3.3.3 Creativity Techniques )

Establishing innovations

Answer 19

purpose =

1. developing innovative requirements
2. delineating an initial vision of the system
3. eliciting excitement factors ( delighters )

Types:

1. Brainstorming
   - collect ideas within time frame
   - groups of 5 to 10 +/-
   - ideas documented by moderator
   - no discussing/judging/commenting
   - afterwards idea analysis

especially effective when:

• lage nr of people
• different stakeholder groups

advantages:

• large nr of ideas in short time
• ppl can expand ideas collaboratively
• unbiased so many new solutions

less effective when:
- muddled group dynamics
- participants with varied levels of dominance
In this case use: 6-3-5 method or brainwriting

2. Brainstorming paradox
   - events that must not occur are collected
   - participants realize which actions may entail negative results
   + risks can be identified early and countermeasures can be developed
   same advantages/disadvantages as regular brainstorming
3. Change of perspective
   - adopt different extreme standpoints ( most common ex Six thinking hats debono )

effective when :
- stakeholders that can only express thier knowledge in biased manner and hold on to own options too hard

not to use when:
- high level of detail is desired ( too laborious )

4. Analogy technique (= bionics/bisociations )

In bionics, problems that the project faces are mapped to an analogous situation occurring in nature, and the solutions nature provides are sought and then mapped back to the project.

In bisociation, the analogies need not originate in nature. These techniques assume that each participant is capable of analogous thinking, that a lot of time is available, and that the participants have an in-depth knowledge of the domain with which an analogy will be drawn.

Analogy techniques can be applied covertly or in the open.