PM-I Scope-Req WiSe2223

Project Management I
Wintersemester 2022 / 23
Prof. Dr. Andreas Pfnür / Dr. Bettina Hornung
Technische Universität Darmstadt / Institut für
Betriebswirtschaftslehre
Änderungshistorie / Change History
Version / Dateiname / File Name Upload in moodle Changes compared to previous version
PM I – Scope & Requirements – WiSe22/23 – FB Immobilienwirtschaft & Baubetriebswirtschaftslehre - Dr. Bettina Hornung 2
Project Management I
SCOPE AND REQUIREMENTS
MANAGEMENT
Scope & Requirements Management
1 OVERVIEW
1.1 Overview
Scope and Requirements Management is about defining what the

project is supposed / expected to deliver
According to the PMI Pulse of the Determining the project scope and the
Profession Survey1) specific requirements is crucial for each
project independent of the project
34% management approach
of projects run in 2020 experienced scope

creep
1) answers of 3,950 professionals world-wide
1.2 Motivation and Challenges
What the customer What the Project How the Analyst What the Programmer How the Consultant
explained it Leader understood designed it implemented described it
How the project was What operations What the customer How it was What the customer
documented installed was billed for maintained actually needed
1.3.1 Definition: Project Scope
The project scope defines the range or extent of matter being dealt
with in a project
Context (but out of scope!)

(interfacing systems,
Scope System1) adjacent components,
organizations, etc.)
Environment
1) or application or app in case of an IT 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)
1.3.2 Definition: Requirement
A requirement is a statement about a condition or capability
A documented representation of a condition 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.
(IEEE610)
1.4 Processes
The International Requirements Engineering Board (IREB) defines

similar processes for the Requirements Engineering than PMI
PMI IREB
1. Collect Requirements Collect Requirements
Document Requirements 1. Capture and

2. Define Scope document
3. Create WBS*)
2. Validate the Scope

4. Validate Scope Verify Requirements (can cover formal
approval / confirmation)
3. Control the Scope
5. Control Scope Manage Requirements (covers management
of changes)
*) Work Breakdown Structure
2 CAPTURE REQUIREMENTS
2.1 Origin of Requirements
Stakeholders, their goals and their requirements regarding the product

/ project are closely related to each other
Stakeholder Goals*) Requirements**)
• 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
*)
The outcome / the benefits the (main) stakeholders what to achieve with the project.
**)
Requirements describe the expected output of the project
2.2 Classification of Requirements - Product
Requirements
Product requirements refer to the functionality and quality of the

product
Functional requirements
• Actions that can be operated independently by a system
• Human-system-interaction
Non-functional requirements
• Technical requirements
• Security requirements
• Performance requirements
• Requirements regarding the user interface
• Quality requirements
• Legal and contractual requirements
2.3 Classification of Requirements -
Project Requirements
Project requirements refer to the way the project is managed and on

the way certain other project activities are executed
Project requirements
(requirements of how the project shall be managed and run)
• Requirements regarding the project management, quality
management, executing activities
• Delivery requirements
• Legal and contractual requirements
ents
requirem l
g al
ifyin that ed
Class to ensure re captur
ps a
hel ents ”)
irem
requ pleteness
(“com
2.4.1 Choosing Requirements Gathering
Techniques
For efficient and effective requirements gathering the right choice of

tools and techniques can be important
Factors to consider when deciding for a tool / method
• 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
2.4.2 Techniques for the Requirements
Gathering
There is a variety of requirements gathering techniques
Survey techniques
• Performance factors, explicit knowledge
?
Observation techniques
• Implicit knowledge / excitement factors
• Performance factors in case of communication problems with the
stakeholders
Creativity techniques
• Identification of new functionalities
• Solution finding
Backward-looking techniques
• Gathering of basic factors
Supporting techniques
• Increase effectiveness of other requirement capturing techniques
2.4.3.1 Survey Techniques - Questionnaire
Questionnaires are useful to address a large number of individuals

?
Basics Implementation
§ Questionnaires with multiple-choice- § Reach a large number of stakeholders
and / or open questions § Especially suitable during product
§ Electronic or on paper development: product evaluation by as
many people as possible
Advantages Disadvantages
§ Reach a large number of stakeholders § Poorly suited to identify tacit
with relatively small amount of time knowledge / requirements
and cost
§ Non-functional requirements can
hardly be raised
§ Direct queries are not possible
2.4.3.2 Survey Techniques – Interview
Requirements can be raised in interviews (direct conversation with the

stakeholders) ?
One or several stakeholders are asked § Personal, electronic etc.
predefined questions and the answers § Formal or informal
are recorded
§ Immediate clarification of questions
occurring during the conversation
§ Experienced stakeholders, Subject
Matter Experts etc.
§ Comprehensive reply to questions § Time consuming with many
§ Individual adaption and modification of stakeholders
the course of conversation § Effectiveness depending on the
experience of the interviewer
2.4.3.3 Survey Technique – Self Recording
Self recording is well suited to evaluate workflows

?
§ Produce a job description by someone who § Capturing of existing processes
has the needed knowledge § Written, audio or video recording
§ Supplement for new requirements, change
or optimization suggestions
§ If necessary support by a analyst who
knows the subject
§ 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
2.4.3.4 Survey Technique – On-Site-Customer
Requirement details can be clarified and evaluated very fast by the on-
site-customer-technique ?
§ Stakeholder representatives on-site at the § Especially well suited for individual
developer team development
§ Permanently available § For critical systems risk reduction due to
§ Clarification of questions possible on short fast customer feedback
call § Often used in development processes
§ Immediate test of results possible
§ Quick transmission of requirements § Very high effort for the customer
§ Quick clarification of questions, § High coordination effort for on-site-customer
contradictions, missing information etc. to align with stakeholders who are not on-
site
§ Risk that the requirements of other
stakeholders are not recognized or not
evaluated properly
2.4.4.1 Observation Technique – Field
Observation
Field observations allow the analysis of complex processes and the

identification of implicit requirements
§ Analyst records activities of the stakeholders § Complex and / or complicated workflows
(temporal dependencies, workflows, manual § Identification of unconscious work and
activities etc.) implicit requirement
§ Analyst can ask questions, unclear
processes can be explained to him
§ Possibly use of video records
§ Enables the detection of unconscious work § Not useful for hardly observable processes
§ Documentation of processes that are difficult and exception
to describe § Risk of biased results if observed persons
§ Very effective for analysis of deviations in feel uncomfortable
processes
2.4.4.2 Observation Technique - Apprenticing
Processes which are difficult to be observed can be analysed by

Apprenticing
§ Analysts learn the work of the stakeholders § Obtain detailed knowledge about processes
with their guidance which are difficult to be observed
§ Acquired knowledge allows the derivation of § If stakeholders do not have the necessary
detailed requirements linguistic abilities
§ Effective requirements engineering in case § Inappropriate in a (security-) critical work
of communication difficulties environment
§ Low risk of biased results because the § Very time and cost-intensive for analysts
stakeholder does not feel observed,
§ Rather unsuitable in product development
however the observer’s experience could
with not exactly differentiate stakeholder
influence the result
groups
2.4.5.1 Creativity Technique - Brainstorming
Brainstorming is the most known creativity technique
§ One oft the most known techniques § Step 1: Group of 5 to 10 members
§ Developed by Alex Osborne in 1939 collect ideas (typically 20 min)
§ Original aim: increase quality and § Step 2: analysis of the ideas
quantity of promotion ideas
§ Particularly effective with persons from § Risk of poor results in case of
different stakeholder groups complicated group dynamics
§ Effective in a good atmosphere § Difficult to perform if stakeholders are
§ Ideas can be refined mutually distributed spatially
2.4.5.2 Creativity Technique - Method-6-3-5
The Method 6-3-5 is a written Brainstorming variant
§ Written Brainstorming variant § 6 participants write down 3 ...
§ ... pass them to the neighbour for
additions or comments (5 iterations)
§ Last step: summary and idea evaluation
§ Even feasible with critical group § less effective than a usual
dynamics Brainstorming because the participants
§ Also applicable if stakeholders are are not together in the same room
spatially distributed
2.4.5.3 Creativity Technique – Walt Disney
Method
The Walt Disney-Method is another Change of Perspective technique
§ Change of perspective Three perspectives:
§ Perspectives can be taken in spatial - Dreamer / Visionary: fantasy, new
and temporal different places ideas, creativity
- Realist: feasibility
- Critic: reasonableness, weak spots,
negative aspects
§ New ideas can be developed and § See Six Thinking Heads
tested on their feasibility
2.4.5.4 Creativity Technique – Change of
Perspective
A change of perspective is supported by e.g. the Six Thinking Hats
§ Consideration of a problem from different Six symbolically coloured heads to represent six
perspectives 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
2.4.5.5 Creativity Technique –
Bio Association
Bionics und bio-association can help to find or to develop solutions by
analogies
§ Bionics: Use of a analogy example from § Development of solution findings for an
nature as working hypothesis to find a existing problem by applying / transferring
solution existing solutions from different fields of
§ Bio association: models not limited to nature expertise
§ Complex problems or hardly conceivable § Time-consuming (analogy finding, reverse
dependencies are more comprehensible transformation)
through analogy
§ Risk of lacking stakeholder acceptance
§ Opportunity to develop creative solutions
2.4.5.6 Creativity Technique – Osborne-
Checklist
An Osborne-Checklist is a special form of a questionnaire

Basics: Implementation
Special form of a questionnaire
§ Find “answers” for each category
§ Different use
§ Imitate § Usage for
§ Change § Test of the acceptance of a product
§ Increase / decrease
§ Collect improvement suggestions
§ Replace
§ Convert
§ Combine
§ Transform
§ Provides good results in case of substantive § To complex for comprehensive products,
objects then only used for overall functionality or a
§ Provides hints for improvement possibilities few part-functions
of a product
2.4.6.1 Backward-Looking Technique –
System Archaeology
System archaeology analyses an existing system
§ Recognise basic factors § Analysis of existing systems and the
§ Identify behaviour of an existing documentation about it
system § Especially, field logic can only be
§ Base: existing system and the derived out of the system
documentation delivered with it
§ Ensures that consistent functionality is § Can be very complex and time
completely recognised consuming
§ Risk: documentation outdated and / or
of a poor
2.4.6.2 Backward-Looking Technique – Reuse
For Reuse a similar system is analysed and parts of its implementation

and / documentation reused
§ Analogue to System Archaeology § Analogue to System archaeology +
§ Base: Similar system and its artefacts resuse
(especially requirement document) § At latest after the Gathering of the
§ Ideal: Use of a requirements database goals and their requirements
§ High cost savings § Risk to find not the right requirements
§ Relatively high documentation effort in
previous projects
2.4.7.1 Supporting Technique - Workshops
Workshops can support capturing, analysing etc. of requirements
§ Cooperative requirements capturing § Gather and develop requirements
by a few to many stakeholders § Clarify open questions
§ Previously defined procedure / § Concretise, bundle, prioritise of
workshop agenda requirements
§ Use of a facilitator or moderator
§ Direct communication promotes a § Difficult to perform due to many or
mutual understanding, willing to spatially spread stakeholders
compromise and receiving of
information assessed by the team § Risk: negative group dynamics
2.4.7.2 Supporting Technique – Mind Maps
With Mind Maps ideas and dependencies can be visualized in a

structured way
§ Developed by Tony Buzan in 1971 § Structuring of gained ideas
§ Systematic arrangement of related ideas § Documentation of conversations, thoughts,
and terms by graphical representation plans, ideas etc.
§ Can stimulate creativity § Example
§ Good suitability for § Mind Map mostly
a visualisation and only interpreted in
structuring of the right way by the
thoughts / author
requirements
§ As a long-term
documentation for
a third party rather
inappropriate
Miro – miro.com
2.4.7.3 Supporting Technique –
Audio / Video Recordings
Audio recordings allow a seamless posteriori wrap-up of interviews /

Video recordings can support observation techniques effectively
§ Recording of a conversation/ interview § Complementing questioning techniques
with a voice recorder § Support of observation techniques
§ Recording of processes with video especially
cameras - with time response
- complex processes
§ Quick accomplishment of the survey is § Additional effort to compile the results
possible
§ Conversation partner can feel observed
§ No loss of information
§ Additional technical effort to compile results
§ Efficient documentation of processes
§ Affected stakeholders can feel observed à
§ Simple measurement of the duration of the can distort the results
work stages
Exercise 1 – Scope Clarification
Regard this course as a project and slip into the lecturer’s role. For
which topics would you ask whether there are in or out of scope?
In Scope / Out of Scope Scope
• topics of the course

• course administration (explicitly)
out of scope
• moodle course: set-up and administration
• script
e
• lecturers / guest lecturers om cours
ers fr
Answ , Nov 12
4
• exam: content, corrections / scoring unit
• interaction / communication with participants
PM I – Scope & Requirements – WiSe22/23 – FB Immobilienwirtschaft & Baubetriebswirtschaftslehre - Dr. Bettina Hornung
33
Exercise 2
Regard this course as a project and slip into the lecturer’s role. Which
techniques would you apply to capture the requirements for this
course?
Stakeholder Technique(s)
Professor • interview
• backward looking (information from previous course)
Attendees • survey technique

• backward looking (e. g. HDA course evaluation)
• practical scenario visit (of a course that implements / covers
most of the attendees requirements) à survey technique
e
om cours
ers fr
Answ , Nov 12
4
unit
Exercise 3
Regard this course as a project. What are your requirements as course

attendees regarding this course?
Requirements
a) registration in the moodle PM

b) good time management (start and end on time)
c) applicability of course content, of what is explained
d) easy access of material
e) real life examples for clear understanding
f) exam preparation
g) techniques to pass the exam at first attempt
e
om cours
ers fr
Answ , Nov 12
4
unit
3 DOCUMENT REQUIREMENTS
3 Document Requirements
3.1 GENERAL CONCEPTS
3.1 Glossary
A glossary can help to avoid misunderstandings due to different

interpretation of terms
Centrally administered
A specific person is responsible
Is maintained continuously
Is generally accessible
It is useful to start creating a
It’s use is mandatory and binding glossary at project start to
avoid later effort to align on
Contains origin of terms terms and definitions
Is aligned with the stakeholders
Records have a consistent structure
38Bettina Hornung
PM I – Scope & Requirements – WiSe22/23 – FB Immobilienwirtschaft & Baubetriebswirtschaftslehre - Dr.
3.2 CLASSICAL APPROACH
3.2 Documenting (Individual) Requirements
Requirements can be written in different formats and languages

§ formal, informal
§ Graphical (e. g. flow chart), text
§ are usually combined in a document and / or entered
into a database
Quality criteria for requirements
§ Coordinated
§ Rated / evaluated [IEEE Std 830-1998]
§ Unique [IEEE Std 830-1998]
§ Valid and current
§ Correct [IEEE Std 830-1998]
§ Consistent [IEEE Std 830-1998]
§ Testable [IEEE Std 830-1998]
§ Implementable
§ Traceable [IEEE Std 830-1998]
§ Complete [IEEE Std 830-1998]
§ Comprehensible
3.2.2.1 Overview Requirements Template (1/2)
The use of a template facilitates capturing and documenting individual

requirements with high quality and in a time and cost efficient way.
• Blueprint for the syntactical

structure of an individual
1. Determination of the legal liabilities
requirement
• Lexical uniqueness can be
achieved by a connection to a 2. Formulation of the core of the requirement
glossary
• Application in five steps
3. Characterisation of the activities of the system
4. Insert objects
5. Formulation of logical and temporal conditions

Source: Klaus Pohl, Chris Rupp, Basiswissen Requirements Engineering, dpunkt.verlag
3.2.2.1 Overview Requirements Template (2/2)
The use of a template leads to standardized and easier 1. Determination of the legal liabilities
to understand sentences each describing a requirement 2. Formulation of the core of the requirement
3. Characterisation of the activities of the

system
4. Insert objects
5. Formulation of logical and temporal

conditions
MUST <process verb>
When? <whom> <object &

THE
Under which SHALL PROVIDE THE supplement of
SYSTEM
conditions? POSSIBILITY the object>
BE ABLE
WILL
<process verb>
3.3.1 Documenting the Scope
The set of all requirements should cover the project scope. There are
various tools to compile and maintain them
§ Scope statement / document

§ Database with all the individual requirements
§ …
Quality criteria for requirements documents
§ Uniqueness and consistency [IEEE Std 830-1998]

§ Clear structure and reasonable scope
§ Modifiability and expandability [IEEE Std 830-1998]
§ Completeness [IEEE Std 830-1998]
§ Traceability [IEEE Std 830-1998]
3.3.2 Requirements Documentation:
Standard Structure
Due to its complexity a good structure of the requirements documentation is
important
Standardised document structure

• Predefines the structure of the requirements
Advantages
• Quick embedding and +
document determination of the contents
• To be adjusted for the specific product • Enables a selective reading and
review
Most know standard structures • Simple reuse of contents
• Rational Unified Process
• Business Modell (customer)
• Software Requirements Specification
(contractor)
• IEEE-Standard 830-1998
• V-Modell
• Specification sheet (contractor)
3.3.3 Requirements Documentation:
Minimum Scope
Every requirements documentation should have a minimum scope:
1. Introduction
Purpose, Systems scope,
Stakeholder, Definitions,
Abbreviations, References, Overview
of the document structure
2. General Overview
System environment, Architectural § Minimum scope
description, System functionality, § In practice standard
User und target groups, Boundary structures are
adjusted according
conditions, Assumptions to project specific
3. Requirements circumstances
1. Functional Requirements
2. Non-Functional Requirements
3. Project Requirements
4. Appendix Example of what
a scope
5. Index document could
look like.
3.3 AGILE APPROACH
3.3.1 Documenting (Individual) Requirements
In Agile Approaches requirements are usually kept individually, if

necessary relations to other requirements are documented
§ formal, informal
§ Graphical (e. g. flow chart), text
§ Very often based on User Stories
Quality criteria for requirements: INVEST

Independent
Negotiable
Valuable
Estimatable
Small
Testable
3.3.2 Requirements based on User Stories
In agile approaches requirements usually reflect the functionality requested by

the customer
User Story Card*) based on the role-feature-reason**) template
Title Priority:
Perspective (Who?) As a <role> …
Aim / wish / requirement (What?) I want …
Reason (Why?) So that …
Created by: Created on: Estimation: Acceptance Criteria
flip the card for …
Describes a functionality or property that creates value for the customer

Created in communication with the customer: “Card – Conversation – Confirmation”
Level of detail evolves over time and when necessary
Quality Criteria: INVEST (independent, negotiable, valuable, estimatable, small, testable)
*) **)
Example following the Connextra format also 3-R – role-requirement-reason
3.3.2 Documenting the Project Scope
The Project Scope is usually represented and managed as a Backlog

(Product Backlog in Scrum) which contains all the user stories (PBI*))
Quality criteria: DEEP
Detailed appropriately
§ Top PBI most detailed à input for next sprint
§ Detailing in just-in-time fashion
Emergent
§ Continuous rebalancing, reprioritizing and adding of PBIs
Example Product Backlog Structure
Estimated (granularity decreases as stories are
selected from top to bottom)
§ Each PBI has a size estimate
Prioritized
§ Near-term items are prioritized (not the entire backlog)
*) Product Backlog Item
4 VALIDATE SCOPE / VERIFY
REQUIREMENTS
Processes
The International Requirements Engineering Board (IREB) defines

similar processes for the Requirements Engineering than PMI
PMI IREB
1. Collect Requirements Collect Requirements
Document Requirements Capture and

2. Define Scope document
3. Create WBS*)
Validate
4. Validate Scope Verify Requirements (covers formal
approval / confirmation)
Control
5. Control Scope Manage Requirements (covers management
of changes)
*) Work Breakdown Structure
4.1 Definition
Validate scope is the process of formalizing acceptance of the

completed project deliverables
§ Key Benefits:
- brings objectivity to the acceptance process
- increases the probability of final product, service, or result
acceptance
§ Performed periodically throughout the project as needed
§ Most common technique used: Inspection, Testing
§ Outputs
- Accepted deliverables
- Work performance information
- Change Requests
4.2 Implementation
Scope verification is usually organized in dedicated and formal

meetings
Classical Approach Agile Approach
§ Dedicated approval meeting / § Sprint Review (Scrum)

Format
workshop
§ Customer § Product Owner

§ Project Manager § Project Team
Participants
§ Depending on the project: § opt.: (relevant) Stakeholders
(part of) the team
§ Inspection § Inspection
§ Walk Through § Walk Through
Activities
§ Presentation § Presentation
(“how it’s done”)
§ Test § Test
§ … § …
5 MANAGE REQUIREMENTS /
MANAGE CHANGES
5.1 Integrated Change Control
Integrated change control is the process of reviewing all change

requests, approving changes and managing changes
§ Key Benefit:
- Allows for documented changes within the project
§ Performed periodically throughout the project
Classical Approach Agile Approach
§ More or less formalized à Change § Not formalized as a separated process,

Request and Change Process part of the clarification and detailing of
§ Addressed to the Project Manager user stories in the product backlog
§ Authorised by the instance and based on § Addressed to and authorized by the
the process defined at the project start Product Owner
(can be part of the contract) § Can only be considered as part of the
§ Implemented as decided during the Sprint Planning – no change
change authorization process implementation during a Sprint
5.2. Change & Change Request - Definition
A “Change” is every change that has an effect either on the project output
or on its approach and can be documented in a Change Request
Change Request
Implement a product different than planned or requested – Change of a

Change
Requirement / Part of the Scope / Entire Scope
- Corrective actions
- on a delivery item / (partial) product of the project (Bug Fix)
- with regard to the approach / the processes of the project
- Preventive actions
is associated with a risk whose impact and / or its probability is
reduced if the action is implemented
5.3 Change (Request) Management
Change (Request) Management ensures that all CR are documented

and managed during the entire project duration
1 2 3 4 5
Register Assess Approve / Manage
Raise Change
Change Change Reject Change Change
§ Each § Every CR is § Analysis of the § Approval / § Manage

stakeholder stored in a CR refusal of the implementation
can formulate a Change- § Documentation CR by of the change
CR Control-System of the impact of appropriate § Ensure the
§ Every CR / Con- the intended authorised role alignment of
should be figurations- changes in a project, the affected
formulated in Management- e.g. PM plans,
written form System § Normally by documents,
Change baselines in a
Control Board project
(CCB)
Scope / Requirements Management -
Literature, Links
IREB (International Requirements Engineering www.certified-re.de

Board) e.V.:
SOPHIST www.sophist.de
Chris RUPP & die SOPHISTen „Requirements-Engineering und Hanser Verlag, ISBN: 978-3-446-
Management“ - Professionelle, iterative 40509-7
Anforderungsanalyse für die Praxis
Klaus Pohl, Chris Rupp ,, ISB„Basiswissen Requirements dpunkt.verlagN 978-3-89864-613-
Engineering“ - Aus- und Weiterbildung nach 0
IREB-Standard zum Certified Professional
for Requirements Engineering Foundation
Level
Project Management Institute „Practice Standard for Work Breakdown Second Edition, PMI
Structures“
PMI (Project Management Institute) PMI‘s Pulse of the Profession In-Depth PMI, www.pmi.org
Report Requirements Management
Appendix – NOT exam relevant
REQUIREMENTS TEMPLATE IN
DETAIL
3.2.2.2 Determine Legal Liabilities
The legal liability is defined by a defined set of modal 1. Determination of the legal liabilities
verbs. 2. Formulation of the core of the requirement

system
4. Insert objects
§ Recommended modal verbs
- Must conditions
- Shall
- Will MUST
§ Differentiation of requirements –
prioritisation (three gradations)
THE SYSTEM SHALL
- Legally binding =
implementation in any case
- Highly recommended WILL
- Is implemented if necessary
3.2.2.3 Formulation of the Core of the
Requirement
The core of each requirement is the required 1. Determination of the legal liabilities
functionality 2. Formulation of the core of the requirement

system
§ Example: print, calculate, save, 4. Insert objects
display 5. Formulation of logical and temporal

conditions
§ Functionality often called

„process“
MUST
§ Processes
- Procedures and activities
- Described by active verbs THE SYSTEM SHALL <process verb>
only
- Semantic of the process
verbs has to be defined WILL
bindingly
3.2.2.4 Characteristic Activity of the System
Activities of a system can be classified into three 1. Determination of the legal liabilities
relevant types 2. Formulation of the core of the requirement

system
§ Independent system activity 4. Insert objects

§ User interaction conditions
§ Interface requirements
<process verb>
MUST
<whom>
THE SYSTEM SHALL PROVIDE THE POSSIBILITY
<process verb>
WILL BE ABLE
<process verb>
3.2.2.5 Insert Objects
Some process verbs need one or more objects 1. Determination of the legal liabilities
2. Formulation of the core of the requirement

§ If a process verb needs one or more objects they system
are identified and added in this step 4. Insert objects
§ Example for „print“: what and where 5. Formulation of logical and temporal
conditions
MUST <process verb>
<whom> <object &

THE
SHALL PROVIDE THE supplement
SYSTEM POSSIBILITY of the object>
WILL BE ABLE
<process verb>
3.2.2.6 Formulation of Logical and Temporal
Conditions
Many requirements apply typically only under specific 1. Determination of the legal liabilities
conditions 2. Formulation of the core of the requirement

system
§ Temporal condition: WHEN, AFTER, DURING, AS LONG
4. Insert objects
AS, etc., logical condition: in case of
§ IF difficult because interpretable temporal and logical conditions
MUST <process verb>
When? <whom> <object &

THE
Under which SHALL PROVIDE THE supplement of
SYSTEM
conditions? POSSIBILITY the object>
BE ABLE
WILL
<process verb>

PM-I Scope-Req WiSe2223

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PM-I Scope-Req WiSe2223

Uploaded by

Copyright:

Available Formats

Project Management I

Scope and Requirements Management is about defining what the

of projects run in 2020 experienced scope

Context (but out of scope!)

1) or application or app in case of an IT project.

A requirement is a statement about a condition or capability

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

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

2. A condition or capability that must be met or possessed by a system or

The International Requirements Engineering Board (IREB) defines

1. Collect Requirements Collect Requirements

Document Requirements 1. Capture and

2. Validate the Scope

Stakeholders, their goals and their requirements regarding the product

Stakeholder Goals*) Requirements**)

• Stakeholder analysis and management are an important success factor for

Product requirements refer to the functionality and quality of the

Project requirements refer to the way the project is managed and on

For efficient and effective requirements gathering the right choice of

Factors to consider when deciding for a tool / method

• Opportunities and risks in a project

Questionnaires are useful to address a large number of individuals

Requirements can be raised in interviews (direct conversation with the

Self recording is well suited to evaluate workflows

Field observations allow the analysis of complex processes and the

Processes which are difficult to be observed can be analysed by

Brainstorming is the most known creativity technique

The Method 6-3-5 is a written Brainstorming variant

The Walt Disney-Method is another Change of Perspective technique

A change of perspective is supported by e.g. the Six Thinking Hats

§ Provides an “escape” in stuck situations § Acceptance by stakeholders very important

An Osborne-Checklist is a special form of a questionnaire

For Reuse a similar system is analysed and parts of its implementation

Workshops can support capturing, analysing etc. of requirements

With Mind Maps ideas and dependencies can be visualized in a

Audio recordings allow a seamless posteriori wrap-up of interviews /

In Scope / Out of Scope Scope

• topics of the course

Attendees • survey technique

Regard this course as a project. What are your requirements as course

a) registration in the moodle PM

A glossary can help to avoid misunderstandings due to different

A specific person is responsible

Is aligned with the stakeholders

Records have a consistent structure

Requirements can be written in different formats and languages

Quality criteria for requirements

The use of a template facilitates capturing and documenting individual

• Blueprint for the syntactical

5. Formulation of logical and temporal conditions

3. Characterisation of the activities of the

5. Formulation of logical and temporal

MUST <process verb>

When? <whom> <object &

Source: Klaus Pohl, Chris Rupp, Basiswissen Requirements Engineering, dpunkt.verlag

§ Scope statement / document

Quality criteria for requirements documents

§ Uniqueness and consistency [IEEE Std 830-1998]

Standardised document structure

Every requirements documentation should have a minimum scope:

In Agile Approaches requirements are usually kept individually, if

Quality criteria for requirements: INVEST

In agile approaches requirements usually reflect the functionality requested by