PM I Vorlesung 2 Teil 1

It is about defining what the project is supposed / expected to deliver

Determining the project scope and the specific requirements is crucial for each project independent of the project management approach

The project scope defines the range or extent of matter bing delt with in a project

• System boundaries provide a basic frame for requirement capturing and analysis

• Important in case of many and / or complex interfaces to the system environment

• Negative list is useful to clearly define the system boundary against its environment

• Unclear system boundaries bear risks (-> risk of scope creep)

A requirement is a statement about a condition or capability

A documented representation of a condiction or capability as in 1 or 2

1. A condition or capability needed by a user to solve a problem or to achieve an objective

2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents

Stakeholders, their goals and their requirements regarding the product / project are closely related to each other

Stakeholder analysis and management are an important success factor for Requirements Engineering

Collecting and analysing requirements is based on the goals of the stakeholders

Good understanding of the stakeholders and of their goals increases the probability to capture the requirements completely / comprehensively

Product requirements refer to the functionality and quality of the product

Functional requirements

Non-functional requirements

Project requirements

Actions that can be operated independently by a system

Human-system-interaction

Technical requirements

Security requirements

Performance requirements

Requirements regarding the user interface

Quality requirements

Legal and contractual requirements

Requirements of how the project shall be managed and run

• Requirements regarding the project management, quality management, executing activities

• Delievery requirements

• Legal and contractual requirements

Classifying requirements helps to ensure that all requirements are captures (“completeness”)

Opportunities and risks in a project

Skills and experience of the stakeholders

Known / explicit or unconscious / subconscious existing information, see also Kano-Model: performance factors, basic factors, dedication factors)

Experience of analyst with tools and techniques

Organizational situation

Technical content of the requirements

Survey techniques

Observation techniques

Creativity techniques

Backward-looking techniques

Supporting techniques

Performance factors, explicit knowledge

Implicit knowledge / exitement factors

Performance factors in case of communication problems with the stakeholders

Identification of new functionalities

Solution finding

Gathering of basic factors

Increase effectiveness of other requirement gathering techniques

To address a large number of individuals

Questionnaires with multiple-choice and / or open questions

Electronic or on paper

Reach a large number of stakeholders

Especially suitable during product development: product evaluation by as many people as possible

Reach a large number of stakeholders with relatively small amount of time and cost

Poorly suited to identify tacit knowledge / requirements

Non-functional requirements can hardly be raised

Direct queries are not possible

Direct conversation with the stakeholders

One or several stakeholders are asked predefinde questions and the answers are recorded

Personal, electronic etc.

Formal or informal

Immediate clarification of questions occurring during the conversation

Experienced stakeholders, Subject Matter Experts etc.

Comprehensive reply to questions

Individual adaption and modification of the course of the conversation

Time consuming with many stakeholders

Effectiveness depending on the experience of the interviewer

To evaluate workflows

Produce a job description by someone who has the needed knowledge

Supplement for new requirements, change or optimization suggestions

If necessary support ba an analyst who knows the subject

Capturing of existing processes

Written, audio or video recording

Low expenditure of time for the analyst

Often only aware requirements documented

Possibly rework required

Difficult to enforce in case of low motivation of the relevant stakeholders

In case of many stakeholders high effort to evaluate data

For clarifying and evaluating requirement details very fast

Stakeholder representatives on-site at the developer team

Permanently available

Clarification of questions possible on short call

Immediate test of results possible

Especially well suited for individual development

For critical systems risk reduction due to fast customer feedback

Often used in development processes

Quick transmission of requirements

Quick clarification of questions, contradictions, missing information etc.

Very high effort for the customer

High coordination effort for on-site-customer to align with stakeholders who are not on-site

Risk that the requirements of other stakeholders are not recognized or not evaluated properly

Field observations allow the analysis of complex processes and the identification of implicit requirements

Analyst records acitivities of the stakeholders (temporal dependencies, workflows, manual activities etc.)

Analyst can ask questions, unclear processes can be explained to him

Possibly use of video records

Complex and / or complicated workflows

Identification of unconscious work and implicit requirements

Enables the detection of unconscious work

Documentation of processes that are difficult to describe

Very effective for analysis of deviations in processes

Not useful for hardly observable processes and exception

Risk of unbiased results if observed persons feel uncomfortable

For analyzing processes which are difficult to observe

Analysts learn the work of the stakeholders with their guidance

Acquired knowledge allows the derivation of detailed requirements

Obtain detailed knowledge about processes which are difficult to be observed

If stakeholders do not have the necessary linguistic abilities

Effective requirements engineering in case of communication difficulties

Low risk of biased results because the stakeholder does not feel observed, however the observer’s experience could influence the result

Inappropriate in a (security-) critical work environment

Very time and cost-intensive for analysts

Rather unsuitable in product development with not exactly differentiate stakeholder groups

One of the most known (creativity) techniques

Developed by Alex Osborne in 1939

Original aim: increase quality and quantity of promotion ideas

Step 1: Group of 5 to 10 members collect ideas (typically 20 min)

Step 2: Analysis of the ideas

Particularly effective with persons from different stakeholder groups

Effective in a good atmosphere

Ideas can be refined mutually

Risk of poor results in case of complicated group dynamics

Difficult to perform if stakeholders are distributed spatially

Written Brainstorming variant

6 participants write down 3 ideas…

… pass them to the neighbour for additions or comments (5 iterations)

Last step: summary and idea evaluation

Even feasible with critical group dynamics

Also applicable if stakeholders are spatially distributed

Less effective than a usual Brainstorming because the participants are not together in the same room

Change of perspective technique

Perspectives can be taken in spatial and temporal different places

Three perspectives:

• Dreamer / Visionary: fantasy, new ideas, creativity

• Realist: feasibility

• Critic: reasonableness, weak spots, negative aspects

New ideas can be developed and tested on their feasibility

Acceptance by stakeholders very important

Good facilitator is important

If stakeholders can’t meet in person difficult to moderate

Consideration of a problem from different perspectives

Six symbolically coloured hats to represent six perspectives:

• White: facts and data

• Red: emotions

• Black: Objective negative arguments

• Yellow: Objective positive arguments

• Green: new ideas

• Blue: process control (e.g. Moderation)

Provides an “escape” in stuck situations

Acceptance by stakeholders very important

Good facilitator is important

If stakeholders can’t meet in person difficult to moderate

Bionics: Use of an analogy example from nature as working hypothesis to find a solution

Bio association: models not limited to nature

Development of solution findings for an existing problem by applying / transferring existing solutions from different fields of expertise

Complex problems or hardly conveivable dependencies are more comprehensible through analogy

Opportunity to develop creative solutions

Time-consuming (analogy finding, reverse transformation)

Risk of lacking stakeholder acceptance

Special form of a questionnaire

• Different use

• Imitate

• Change

• Increase / decrease

• Replace

• Convert

• Combine

• Transform

Find “answers” for each category

Usage for

• Test of the acceptance of a product

• Collect improvement suggestions

Provides good results in case of substantive objects

Provides hints for improvement possibilities of a product

To complex for comprehensive products, then only used for overall functionality or a few part-functions

Analyse an existing system

Recognise basic factors

Identify behaviour of an existing system

Base: existing system and the documentation delievered with it

Analysis of existing systems and the documentation about it

Especially, field logic can only be derived out of the system

Ensures that consistent functionality is completely recognised

Can be very complex and time consuming

Risk: documentation outdated and / or of a poor quality

A similar system is analysed and parts of its implementation and / or documentation reused

Analogue to System Archaeology

Base: Similar system and its artefacts (especially requirement document)

Ideal: Use of a requirements database

Analogue to System Archaeology

At latest after the gathering of the goals and their requirements

High cost savings

Risk to not find the right requirements

Relatively hgih documentation effort in previous projects

Workshops can support capturing, analysing etc. of requirements

Cooperative requirements capturing by a few to many stakeholders

Previously defined procedure / workshop agenda

Use of a facilitator or moderator

Gather and develop requirements

Clarify open questions

Concretise, bundle, prioritise requirements

Direct communication promotes a mutual understanding, willing to compromise and receiving of information assessed by the team

Difficult to perform due to many or spatially spread stakeholders

Risk: negative group dynamics

With Mind Maps ideas and dependencies can be visualized in a structured way

Developed by Tony Buzan in 1971

Systematic arrangement of related ideas and terms by graphical representation

Can stimulate creativity

Structuring of gained ideas

Documentation of conversations, thoughts, plans, ideas etc.

Good suitability for a visualisation and structuring of thoughts / requirements

Mind Map mostly only interpreted in the right way by the author

As a long-term documentation for a third party rather inappropriate

Audio recordings allow a seamless posteriori wrap-up of interviews / Video recordings can support observation techniques effectively

Recording of a conversation / interview with a voice recorder

Recordings of processes with video cameras

Complementing questioning techniques

Support of observation techniques especially

• with time responses

• complex processes

Quick accomplishment of the survey is possible

No loss of information

Efficient documentation of processes

Simple measurements of the duration of the work stages

Additional effort to compile the results

Conversation partner can feel observed

Additional technical effort to compile results

Affected stakeholders can feel observed -> Can distort th results