RE Primer Eng

The SOPHISTs SOPHIST GmbH
Vordere Cramergasse 13
90478 Nuremberg
Germany
www.sophist.de
@ SOPHIST_GmbH
@SOPHIST.GmbH
/sophistgmbh
blog.sophist.de
1St edition 2021
Translated from German by Joachim Kurrer,

SOPHIST GmbH
Copy Editing & Production: David Nawzad, SOPHIST GmbH
Cover Design and Layout: Heike Baumgärtner, Büro Hochweiss
Copyright: SOPHIST GmbH
This work is protected by copyright laws.

All rights, including translation, reprinting and reproduction of the book, or parts
thereof, are reserved. This work may not be reproduced, edited or copied in whole
or in part, by electronic means or otherwise (photocopy, microfilm or other media)
without the written consent of the SOPHIST GmbH.
It should be noted that all software and hardware names as well as brand and
product names of the respective companies are normally subject to the registered
trademarks andpatent protections.
While reasonable care has been exercised in the preparation of this brochure, the
author and the SOPHIST GmbH assume no responsibility for errors or omissions, or
for damages resulting from the use of the information contained herein.
Requirements-
Engineering
The SOPHISTs
»Short & clever«
The SOPHIST
RE-PRIMER
www.sophist.de
UPD
Trainings ATE
What‘s new about it?

All SOPHIST training courses are designed in accordance with the
latest knowledge. Among other things, our trainers follow the
principles of the “...from the Back of the Room“ method in order to
convey training content in a sustainable way.
An activating learning evironment - more movement, less text,
more interaction with the paricipants and surprising exercise con-
cepts - makes learning fun and efficient.
Y}v.M
You benefit not only from the know- how of the met-
hod leaders, but also from a didactic implementation
that leaves its mark.
Curious now?
C}v`]R}}o]P}vP
+49 (0) 911 40 900 - 0
heureka@sophist.de
6 Table of contents
X Iv}}vvM}}v �� 8
2. What is Requirements Engineering? ��10

X*Co].}v}(R]uv �� 12
X*Qo]˙}(R]uv �� 14
X*S}}(R]uv �� 15
X*M]vA]}(R]uvEvP]v]vP �� 16
X Eo]]vPKv}òP ��19
X*G}oUS}vS˙uC}v˘ �� 19
X*Eo]]}v}(R]uv �� 20
X*Iv(˙]vPL]vP]+E WTRSOPHISTS}(REPo}v �� 22
X D]]vPG}}R]uv ��25
X*A](}Avo˙]vPR]uv �� 25
X*Vo]vPvC}v}o]vPR]uv �� 28
æX D}uvvPvIuvPR]uv ��32
æX*IuvPR]uv`]R}D}uv}v �� 32
æX*IuvPR]uv`]RD}uv}v �� 34
X R]uvMvPuv ��37
X*H}ùRR]uvMvPuvMlSvM �� 38
X*V]}v]vPvBo]v �� 39
X*T]o]˙ �� 40
X*CRvPvRoMvPuv �� 41
7. Establishment of an Improved Requirements Engineering ��43

X*CRvP`]R]vvOPv]}v �� 43
X*TRo]Ruv
E ]P}iJ �� 44
X*AvAP]oD]Pv}(CRvP �� 44
X*W}lPlP}(vo]Ruv
E �� 47
8. Requirements Engineering and Agility��48
9. Systems Engineering ��52

ıX*D.v]}vvP} �� 52
ıX*Eu]vP}(R]uvEvP]v]vP �� 54
10. Requirements Engineering for Smart Ecosystems and as a Driver

}(D]P]oTv(}u}v ��56
7 Table of contents
11. Business Analysis, Requirements Engineering or Both?��60
X V]}`]R]vR]uvEvP]v]vP ��63
X R]uvEvP]v]vP(}P}L]vvFu]o] ��66
X C}vo]}v ��68
8 Iv}}vvM}}v
1. Introduction and Motivation

We SOPHISTs have been working as consultants and trainers in requirements
vP]v]vP ~REZ (} u} Rv ˙X W } }u (}u uv˙ ]+v
]v]U (}u }L` o}uv (} ]vv v vl } R
˘}v }( R`r}]v ˙u vP]v]vP }i ]v R }u}
} v R ovv]vP }( ]o]vP }uo˘X TR (} }( } `}l ] R o]]}v
}( ]uvU ]}v }( P}} ˙u ]uv òo R uvPuv
}( ]uvX FRu} ` } ]v ]uvP ]uvX Dv]vP }v
R }i }v]}v ` XPXU }R R }v R }uv}v
of requirements or storytelling. We also work with other topics, which are closely
related to requirements engineering: requirements engineering within a systems
vP]v]vP }RU vP (}v}v (} ]uv ˙ .v]vP ]v
processes and considering special aspects that come along with requirements that
o˙ } o ]}v }( R }X A]}voo˙U ` ]l }v v }]
~XPXSu U }˙u
E U D]P]o Tv(}u}vZ v v ~XPXV]} U ]v REU
}`
C rREXXXZ ]v } ]o˙ `}lX FRu}U ` (} }v R o]Ruv }(
requirements engineering as well as agile approaches.
O o]( ] }vPo˙ ]vGv ˙ ITr˙u W }uu ] v v }v RuX

They make our existence considerably more pleasant, they structure and co-create
]X TR˙ }] ]v(}u}vU } ]]}v ul]vP v `}l }U òo
}u }X TR˙ o} }v }}v] R ` R v} v
dreamed of a few years ago. We live in smart homes, our cars consist of intelligent
components, our home appliances are able to communicate with us and our smart
R}v }] } R }( R `}oV v˙u v v˙`RX Iv]
manufacture their products in a “smart” way, agriculture, energy supply and the
RoR ˙uU X (}u 'U ˙u u}v]} v }u] R
}v }( oX T} vU oo }( R] `]oo˙ u (} Ruv]˙ v v} v
9 Iv}}vvM}}v
into a nightmare, it is crucial to make sure these systems do what they are supposed
to do, i.e. what we expect them to. This is where requirements engineering comes
into play. The complexity of the tasks systems execute is increasing and needs to be
]vv } ]v.U vo˙ v ]uX TR lv}òP ~R ]uvZ
}Lv v } }uv v uvPX (}
B RU R ]v }
R } ˙ R ˙u v } v}} v L X TR ]l
is to consider the manifold constraints. Requirements engineering in this context
uv}.vR]PR}R(}R]PR}X
Iv } } ul oo R}˙ ] u} ˘]vP v } ul ] ] } }uRv
the topics addressed in this brochure, we added some examples. They are based on
the development of a smart home system (SHS).
A]}voo˙U R ]} v v]u PR] }]vP }u o }]
}v}R}uPXTRo]vl]u]vR(}oo}`]vP]}vP
w ww.sophist.de/...
Mv˙ Rvl } oo SOPHISTU `R} R }v] } R] }R W R v

S]uv vP]v]vP v uvPuv_ }}l uU R Rv]o v o]vP]
reviewers and the discussion partners who have contributed to the contents and the
quality of this brochure.
10 What is Requirements Engineering
2. What is Requirements Engineering?

The term requirements engineering can be loosely interpreted as follows: dealing
with requirements concurrent to engineering principles. Working with requirements
R}o R(} oU }uRv]o v i.X A ]uv
vP]v]vP ] oo˙ }( o}uv }i `]R }v]v o]l u v
u}v˙U }uR]vP o u'P I R}o ˘ }]o˙X O P}o ] }
ensure that requirements engineering creates requirements exactly in the quality
needed for further development.
TRR}PRG]vR(}oo}`]vP.v]}vP
Definition of the discipline requirements engineering according to IREB

[CPRE20]:
TR ˙u v ]]o]v }R } R ].}v v uvPuv }(
requirements with the goal of:
v understanding the stakeholders‘ desires and needs and
v u]v]u]]vP R ]l }( o]]vP ˙u R } v} u R ]
and needs.
Uv]]vPo˙U R u ]uv ] }( ]}o ]u}v ]v R] .v]}vX

W SOPHIST R (}v .v]}v }( R u ]uv R ] òo ]v
U v R }v } ˙ }uRv]oU }uRv] v 8]vo˙
].P
Definition of the term requirement according to SOPHIST:

A ]uv ] uv P]vP R] } (}uv }(
product, a process or the people involved in the process.
Obviously we interpret the term requirement broader than usual. On the one hand,
] ] u} Rv R ˙u } o} uv ~R ]uv[ i }(
}}vZX Ov R }R RvU ` `v } }] ovP
(}u }( v}v (} ]uvX F} U ]uv
can be documented or imparted in various ways during a
}iXH}u˘uoP
v classically, textually, possibly using templates,
v as a User Story or Epic,
v as a story using storytelling,
v model-based.
FRu}U R] .v]}v }( ]uv vP]v]vP ul R }roo l -

R}o R (} }( ]vX Uoo˙U R lR}o ] ]vP .v }o `]R
] } ]v] ]vGv } R ]uvX A ] ]vGv ]v R] }v˘
uvU R lR}o }] ]uvX ~ PR X W SS} (}
Requirements”).
TR o} }}}v `v ]uv vP]v ~o} ( }
]uv } ˙u vo˙Z v R lR}o uv ]v o]
}( R ]uv vP]vX TR o] ˘ R uR}]o v ir
]. ]o] ] ]v R o]}v }( R ˙u } ].X Uoo˙
]uv vP]v]vP ] }vv `]R }uuv]}v `v }v `R}
R ]+v P}oU }vo lP}v v R]X TR ]o]
have proven to be very important.
F]P X ]oo R ]o] ]uv vP]v v }]vP } IREB
CPREX TR v (}v ]v}v `v ] }uv] ~oLZ v
competencies that are highly relevant, especially for determining requirements
(right).
A]}voR](}u]v]vP]uv
}vG]}o]vP]o] self-awareness
context awareness
persuasiveness
u}vPuvv
empathy
leadership personality
vo˙oR]vl]vP G˘]]o]˙
G}v
}uuv]}vl]oo
neutrality
v}vl]oo
intercultural competencies
o(r}v.v ethical conscience
P}vo]}(]uvvP]vo}vP]ir].v
methodical competencies
F]PXPP}vo]}(]uvvP]v
Iv R (}oo}`]vPPRU ` `]oov }u ] lv}òP R ] vo

for the work with requirements.
2.1 Classification of Requirements

Gvoo˙U R ] ]˙ }( }}v }v R}` } o](˙ ]uvX Co].}v
R}o o`˙ R ]v }iX Iv R] RU ` `]oo v R ˙
}( o].}v R Ro ]v } `}l `]R ]uv v R(} u
ooX ˙E ]uv v P}] }]vP } R o].}v
] ]v R] RX TR o].}v oo}` .v]vP l P]vP R
]uv vP]v]vP }RX F} ]vvU }uu R o]]}v v
]+v (} (v}vo ]uv v v}vr(v}vo ]uvV }uu
R u]PR uv (} .v]vP R .«vP ]uv (} r˘]vP
more detailed requirements.
Traditional classification according to types

TR (}oo}`]vP ]oo}v P] v }]` }( R ]+v ˙ }( ]uv
Ru}}uu}vo˙uv}v]vo]X
User interface requirements
Technological constraints Qo]˙]uv
Fv}vo
requirements
LPol}vo Requirements for
requirements other deliverables
R]uv(}]
AA(v}vo]uv
AAv}vr(v}vo]uv
F]PXPT˙}(]uv
The two most frequently needed types are:

v Fv}vo R]uvP `R]R (v}v} R ˙u }] } }
v]PR}]vP˙uv]v}v]}vM
v Qo]˙r}(r] ]uvP R˙ ](˙ R ] o]˙ }( R ˙uU
u}o˙ o } (v}v ~XPXRU (}uv }( (v}v } R ]o]o]˙
}(Rv˙uZX
Classification according to legal obligation

TR oPo }o]P}v ] R ]u}v lR}o ] } R ]v]]o
]uvXTR(}oo}`]vP˙v]vP]RP
To obtain a complete set of requirements, all levels of detail for requirements should
]. ]v `˙ R }] v}PR ]v(}u}v (} ˙}v ]v}oX

However, this does not necessarily mean that every requirement needs to be broken
down to the smallest level of detail.
English
LPo}o]P}v
keyword
Oo]P}v Shall
Wish Should
Ivv}v Will
F]PXPP}vl˙`}(}oPo}o]P}v
Classification according to responsibility

Av]u}v]v}v(}]uv]R}v}v]o(}RuXA``]oo
later on, one of the purposes of Requirements Engineering is to take all the input for a
o}uv}iUR}]uvUv]o]o˙u]uvX
TR]o}vR]`vR`}˙}(]uvX
Source of requirement Requirements-

(e.g. stakeholder) Engineer
Original requirements System requirements

`]RU]v}vU]U product backlog, customer requi-
features, customer requirements Requirements uv].}vU}
].}vUoÙv}u Engineering ]uv].}v
F]PXPIvv}}(]uvvP]v
Classification according to subject matter

TR }o˙ u} ]u}v ]v}v (} R o].}v }( ]uv ]
u }v R i u'X D} R ]uv ( } R }v]
˙u ]v R }iU } }v }( ] }u}vv } } ]v } }
by the system? Is the requirement located outside of the considered system, in its
context? Especially in the area of systems engineering, where several levels of the
˙u ˘]U R ]uv Roo oo} ]vo˙ } i u' ~
PRıWSS˙uvP]v]vP _ZX
TR R] }( ]uv oo˙ u'X TR[ `R˙ ` `} u} }
]]vP P}} ]uv ]v R R } vo˙]vP ]uv ~ -
PRXWSA](}vo˙]vP]uv_ZX
Classification according to the level of detail

A .U R] o ˙ }( o].}v u ov }vo˙ ]v R}˙X Iv ]
v }Lv (}v ]v }uv ovX R]uv v ](˙ }R
]uv ]XXR˙ ]v] ~Rv]oZ }o}v (} ]uvX F} ˘uo
it can be required, that a smart-home-system shall unlock the front door as soon as
lv}`v }v }RX M} ]o } `R]R R] }( R }v
R˙uRooRl`}o}uv]vu}.v]uvX
TR] }] o o].}v }( R ]uv v R(}
comprehensively a certain level of completeness of said requirements.
2.2 Quality of Requirements

A uv}v o]U R]uv EvP]v]vP R}o ˘ }]o˙X
TR] v .v ˙ R o]˙ }( R ]uv R R}o R] (}
the development.
TR ]} ]+v }R (} R o]˙ }( ]uvX Aoo }( Ru
R ]v }uu}vU R R˙ .v o]˙ ˙ ] }( o]˙ ]]X Iv R (}oo}`]vPU
we have listed the criteria SOPHIST use to measure and assess requirements. In doing
}U ` ]+v ]] (]vP } ]vPo ]uv (}u ]] R o˙
for a whole set of requirements.
Requirements for classic approaches

F} o}uv }i ˘ ]v o]o }R R ]uv v
to have a high quality. The reason is that these approaches do not include an
integral process step that aims to improve the requirements once they have been
]v]oo˙ X Iv R˙ o˙ }v R }u] u}v R ]uv
vP]v]vP ] .v]R (} }( ]uvU }}v ] R v ]v]oo˙
created.
F}]uvP F}
]uv].}vP
Necessary Understandable C}uo C}v]v
Unambiguous C}v}o] oC o˙ Adequate
C}uo
F]PXæPQo]˙]](}]uv]vo]}
Requirements for agile approaches

T} u]v R ]] (} ]vPo ]uv ]v v P]o o}uv }i
~v}uoo˙R`]ooUS}]Zò˙RINVEST]v]oWlX
Independent INVEST Testable
NP}o Small
Voo uo
E
F]PXPTRINVESTr]v]o(}US}˙
TR ]] (} }( ]uvU uv]vP lo}PU o˙ v˙ ]+v

(}u R} R } } o˙ (} ]uv ].}v ]v R o]o
context.
2.3 Sources of Requirements

Evoo˙URR]+v}}(]uvP
v SlR}oP P}vU }Pv]}v v ]v}v R ]vGv R ˙u
a directly or indirectly.
v D}uvP LÙ v}uU uvo } }R }uv}v v }
gather requirements.
v S˙uP I ] }Lv Ro(o } vo˙
]vP˙u}}u}X
M} ]vvP ] R P} }( lR}oX
TR˙ }Lv }u (}u ]+v lP}v v
therefore have variable goals for the considered
system with their requirements. In the following,
there is an incomplete list of areas that can provide
requirements or even be the trigger for a develop-
uv}iX
Commissioning organization
Iv o}vR] `v }uu]]}v]vP v }vvP }Pv]}vU R
commissioning company is presumably the most prominent cause for a development
}iX I }] R }vvP }Pv]}v `]R u}v˙ (} R o}uv
~v u˙ o} (} (}oo}`]vPl R }}vZX ˙B }]vP RU ] ]Pv].vo˙
determines the requirements for the future product.
Management of innovation/ portfolio / product

Ov R }R RvU R } }Lv ]vvo (} o} -
uv }iX TR˙ }v]o (} R vuv }( r˘]vP }
} u]v }u ]v R ulX Iv }i ˘ (} }u R˙ u˙U
R}Ùo}uv]}vo]uvX
Problem/ change management

Problem management provides change requests to a system that most commonly
R v ]v. ]v o R }( R o]( ˙o ~]vP }}vU v}U
]voo}vU }}vZX TR v o } ]}vo } RvP ]uvX TR˙
u]PR o} uv v` o}uv }iX C RvP }( ]uv ]vP v
}vP}]vPo}uv}i}˙RvPuvPuvX
2.4 Main Activities of Requirements Engineering

TR ] R]uv EvP]v R } ˙ } v }PRo˙ oo} ]v}
(} u]v ]X TR u]v ] `]oo ] ]v ]o o }vXIv R]
brochure we can only depict the most important tasks and aspects of the individual
u]v]XF}u}]ov}vUo(}RX
Requirements-Engineering
E o]]vP Deriving good IuvP MvP]vP

knowledge requirements requirements requirements
F]PXPTR(}u]v]}(]uvvP]v]vP
vE R}PR ` v R u]v ] ]v R } uv}v }U R

]v]]o ] `]ooo`˙ } R } }( R ˙u o} -
ment. This could either be caused by an incremental view on the tasks or by the fact
R]vPR(}uv}(v]˙Rv]˙(}v}R]˙P}`X
Eliciting knowledge
TR . u]v ]˙ So]]vP lv}òP_ o˙ R (}v}v (} (R
requirements engineering. If they don’t already exist, the course of the system
o}uv ] ˙ .v]vP ]]}v v P}oX N} oo } }( ]uvU ]v
o R lR}oU o`˙ lv}`vU } R˙ u ]v. ]
(}(R]X
Ov R } }( ]uv lv}`vU R o]]}v }( ]uv (} R
˙u } o} v P]vX SovP R }] o]]}v Rv]
(}R].o}uv]v]u}v(}X
Deriving good requirements

Iv } } ] P}} ]uvU . R ]}o˙ ]v. uv Roo
vo˙ ]v } } P R u} }uRv] ] }( R ]uv (} R
system to be developed. Depending on the process model, this idea must now be
X Rv }( ]+v }o ]v R o}uv v ]` R
requirements:
v F}u R }]v }( ]` }( R }o
issuing the requirements, the
requirements are checked with regard to
R (o.oouv }( R ˘}v }( R
system.
v F} R ]uv Rl }
see whether corresponding test cases can
be derived.
v The development (especially the
architecture) will check the feasibility of
the requirements.
Dv]vP }v R o]}v }u]vU (R
Rl u˙ v˙X Iv R }u}
industry, for example, it may be necessary
} Rl }uo]v `]R (v}vo (˙
]uv~ISOZX
Imparting requirements
S} ( R u]v ] } v P}} }]` }( R v ]uv
] X SooUR ]uv Roo } }u}˙ [ `}lU } R˙ v }
communicated to the people involved. Here we assume that one either wants to
document the requirements or share their knowledge about the requirements in
another way (storytelling, videos).
I( }oo}v }( }uv ]uv Roo U R `}
ovP
v The system requirements can be documented by using natural language.
v The requirements can be documented model-based.
Iv } }vovP ] u]˘ }R `v }R ov o`˙ R
RR]PRv.vRvX
Managing requirements
A }}v }v]]vP R }uv}v }( ]uvU v` RoovP ]
`]vPV R uvPuv }( R }uv ]uvX S}u ]]}v R
to be made:
v WR l]v }( ]v(}u}v } R ]uv }oo}v }v] }( v R}`

they structured?
v WR} ] oo}` } (}uU `R]R }v ]v R ]uv ~]Pv ]PR v
roles)?
v WR]R ]}vo ]v(}u}v ] v ]v } } uvP R ]uvM
F} ˘uoP v }( R ]uvU ]v(}u}v } ]v }(
the product.
v How shall the traceability be ensured?
v WR]R]}v]vP}vRooR(}v}v(}R]uvM
v WR]R ]v(}u}v v } }] ]v R ˙u o}uv v `R]R
form shall it have?
W ]Pv R v uv˙ }R ]]}v v ] } R uvPuv }(
]uv ]v } } }] R ] ]v(}u}v ]v }uRv]o `˙
v˙uX*
19 Eo]]vPKv}òP
3. Eliciting Knowledge
N} }vo˙ ] R o]]}v }( lv}òP R .U }v }( R u} ]u}v
] }( ]uv vP]v]vPX I ]vo R ]uv RuoU
o} }R ]v(}u}v R }U }v] v ]v }X I l
o ]v ˙ }]o v]}U ˙ } u}o v (} ˙ .vuv oo
}( ]uv v ] ] o]'o ]+v R uX I( R ]PR lR}o v[
]v.U R }v˘ ] ]v}o˙ }U }v R ]v } R ]PR
knowledge isn’t elicited of, requirements engineering is very likely to fail. This doesn’t
uv R oo }( R ] R } }uo R P]vv]vP r o]]}v ]
rather a process that endures the whole requirements engineering process.
A o} R RvP ]v R .o }( ]uv
vP]v]vP ]v R ˙X D]P]o]}v
v }v o]l u ] } u o
R ]Pv].v ]u }v } }]o
}v˘ v } Ruv ]v}vX A
result, IT is making its way into many areas
R ` o˙ + ˙ ] ]}o˙X O(
course, most people already have a washing
uR]v ]v R] R} R }v]v }L -
ware, but the wishes of the users were
}Lv }vo˙ PX D]P]o]}v v}o˙
intervenes in areas such as our healthcare system, the delivery of goods, the trans-
}}v ˙u v }uuv]}vX TR[ `R˙ ] ] ]u}v } vv
R v }( oo R ]+v lR}oX Iv } }vovPU ` o`˙ RE
methods to the context in which they are applied and to its stakeholders. When
]P]o]}v u} ]v} oo }( o](UR ˙u vo˙ + }o `R}
hardly had contact to IT and who aren’t familiar with their role as stakeholders.
3.1 Goals, Sources and System Context

B . R]vP .P ˙E }i ] ]v] (} }v } }X I v }
}( ]uvU v R}o R .v (u`}l } ]vP]R R v˙
from the unnecessary.
Goals and goal finding

S«vP R P}o (} R ˙u v }i ]u R }( R o} -
uv ovPo˙X ˙E ˙u o}uv R}o `]R .v]}v }( P}o
`]R v ˘v }( } Ro( PX Iv ` u P}} ˘]v ˙ ]vP
P}o o } }l}i vX I( P}o v} }uvU } .v
voo˙U R ] v} (}v}v (} R v } ]X A oU
R ]uv vP]v R v} ].}v }( R P}o R ]uv u
uX C}vvo˙ R o P}o u˙ u]X TR } }( .v]vP P}o
}vPo˙ v }v }v]vX F} ]vvvP v` }U ]]}v˙ R]vl]vP v
20 Eo]]vPKv}òP
v }v u]v } oo }]o }o}v u} ]u}vX I( v }o ˙u Roo

replaced, the focus should primarily be on possible improvements and their impact
}v˘]vP(v}vX
Sources of requirements
F]v]vP R ov } }( ]uv ] ]oX T˙]o } }uvU
systems and stakeholders of course. A requirements engineer, needs to keep his eyes
}v (} oo ]uP]vo } }( ]v(}u}v (} ]uvX I( ] }
v} ]ooU `}l]vP `]R }v G}}`]vı .} v }(
real people, might be helpful.
System scope and context

TR .vo ]˙ (} R o o]]}v }( ]uv v ] } .v
what actually belongs to the considered system (scope) and in contrast, what is out-
side of the system’s boundaries (context) and thus can interact with the system. An
]v } } }v˘ `]ooo } ]v}uo } ]v} v }uu v
to unnecessary requirements.
3.2 Elicitation of Requirements

TR P}o }( R o]]}v ] } u]v ]uv R Ro o}]vP ˙u
R ]vP uR v. }]o } R lR}oX TR˙ R ]uv
v } } R }v]v }( R }i v o]] `]R o]'o
˘v }]oX TR[ `R˙ (} R o]]}v R Roo v 8]v ov
`v R ]l }v v } ˘o}]}vX Iv ]}v }(]}vo o]]}v
uR} .«vP } R } vX TR PR lv}òP ] R
(}v}v }v `R]R P}} ]uv ]U }uvU ]uU v
managed.
Precondition for a good elicitation

It can’t be expected that stakeholders present the perfect requirements on a silver
o'X Eo]]}v }( ]uv ] R `}lX TR R u} ]u}v (}
(}(oo]]}v}(]uvP
v B]}uuv]}vl]oo
v lv}òP}(v}vo˙u}(ovPP
v lv}`]vPRvPRv`lv}(Ro]]}vRv]
v vo˙]}(Rov}v]v(}R}(o]]}vRv]
v ovPv}u]v]vP}]o]]}vRv]
v vP R ]PR u}R (} R }( o]]}v Rv] ~]oo˙
(}]˙Rv]Z
21 Eo]]vPKv}òP
Criteria for the selection of elicitation techniques

R
E o]]}v Rv] R ] vPR v `lvX TR˙ }vo˙ ]o
(} R v ]v }v]}vX Kv}`]vP R }v]}v v ]vP Ru }
o ]o o]]}v Rv] ] ]] (} R }( R o]]}v }(
requirements.
v H}` P ] R lv}òP }( R lR}o P]vP R i }(
}}vM
v H}` R]PR ] R u}}v }( R lR}o } ] `]R]v R
o]]}vM
v I R lR}o v }vM D} R o]l } ol } ] R R
Roo˙u]vM
v H}`]Ro}o]]}v}(RlR}oM
v WRuRlR}o]ooM
v Are there any special group dynamics between the stakeholders to be
considered?
TR uoo o}v }( ]] } u}v R R}}]vP R }]
o]]}vRv]v}vR˘]v}(R]uvvP]vX
Four groups of classical elicitation techniques

In order to elicit knowledge a variety of techniques has been developed, which can
be roughly divided into four groups.
v Survey techniques
~Q}vv] v ]v]`Z R o] u}vP R ]vP}v Rv]
and are based on asking stakeholders about their wishes and needs in a targeted
manner in order to derive requirements from their answers.
v O}vRv]
~F]o O}vU v]vPU }v˘o ]v]˙Z ]( lR}o vv}
express their knowledge in language or many implicit wishes are expected.
v Document-centered techniques
(System archaeology and reuse) have their strengths when there is no knowledge
carrier available anymore. In this case the domain logic can only be determined from
R˙u]o(v]}uv}vX
v Rv]
C *
~B]v}u]vP } ]v}u]vP }˘Z `Rv ]vv} ]
required.
22 Eo]]vPKv}òP
New approaches/ frameworks - co- creation-

models, CrowdRE and living labs
Iv ]}v } R o]]}v Rv] i ˘o]vU R ] `R}o }(
(u`}lR}u]vo]vP}vRv]X
A vU ` `}o o]l } ]vPo } }`RE C X TR 'u ] } u}
an anonymous group of people (crowd) to cooperate by providing an access with the
lowest possible threshold. There are many approaches on how the crowd can be won
and how they contribute. In most cases, electronic means are the standard.
TR P}o }( }`RE
C ] o} } .v }roo v]}v ~R]PRo˙u} lR}o
with a lot of knowledge) in the crowd of respondents. We will try to encourage them
}(R}}}vX
3.3 Identifying Linguistic Ecects –

The SOPHIST Set of REgulations
Iv R `}l `]R ]uvU v]o o]vP] + v } ]oo˙
]vP R o]]}v RV ]v ] }uuv]}v òo ]v `]vP } ]vP
]uvX TR SOPHIST S }( REPo}v Ro } v]o +
v } R ] (} R]PRro]˙ ]uvX Soo ` R v} ˙ ˘o]v
`Ro]vP]+vR}`R˙]X
Linguistic ecects
˙E }v ] R] v]}vuv ]+vo˙X TR }o]˙ }( R] }v
(}u R }v[ lv}òPU `R]R ] (R ]vGv ˙ ]} lv}òPU
social shaping and accumulated experience.
A }}v }o }uuv] R] lv}òPU v(}u}v } l
oX TR } v }v R}` R }uuv]vP R]
]}v v ]vo}}X WR]R ]} lv}òP } R˙ ˘ (}u R
}R }vU v R}` ]v }( v ] R˙ RuoM TR v(}u}v
}vo]vo}}(o].}v}(]v(}u}vX
H}Ù v(}u}vo + v v }o W }vo˙ ]( R
]uv vP]v lv}` R }]o ˙ }( v(}u}vo + v
R] }vvX TR] ] `R R SOPHIST (u`}l }( REPo}v }u
]v} o˙X Evoo˙ ] ] }v R uru}o }( ovPP v v}o]vP]
}Puu]vP ~NLPZ Bvoæ BvoıX Bvo v G]v ]vP]R
`vR˙}(v(}u}vPo}vUPvo]}vv]}}vX
23 Eo]]vPKv}òP
DISTORTION is an indicator for
D
statements that distort or change
DELETION is an indicator for
reality.
imcomplete information.
G D
GENERALIZATION is an indicator for
possibly incorrect generalizations.
F]PXPCo].}v}(o]vP]+
The SOPHIST Set of REgulations

F}vo˙U }o } ]v orP] uvv `Rv (}uovP lv}òP
]v vo ovPPX TR oo ]v `]'v v }lv vo ovPP -
uvU R Ro }Pv]]vP v(}u}v }X TR SOPHIST S }(
REPo}v ] }v R v}v]}o˙ o] o v vo } .v
u]P} v }v]}˙ uv ]v ]uv ].}v ]v .v
v˙u`˙]vP˙uvo˙]X
W??? Adding process details

It need to be checked if the relevant process details are already
8]vo˙ vu ]v R ]uvX Q}v R ~}
property word derived from a verb) that expresses the process using
R ˙]o }v `}P WRvM WR}uM WRM H}` }LvM X
]D `RR R u]]vP ]v(}u}v ] vo (} R ]uouv}vX I( ] ]U
.oo]vRu]]vP}]oX
We have only provided one of a total of 17 rules to give an idea of these rules. It’s
v} v˙ } uu}] oo o R P]vv]vPX Ov v ]l } R `} }
three rules that are most important to him, and listen for the corresponding signal
`}X TRvU ]( v˙U l R ]PR }vU } P R o ]v(}u}v (}
example.
M} ]v(}u}v } R P }( R REPo}v v (}v ]v R (}oo}`]vP
video:
24 Eo]]vPKv}òP
words VPU ]o˙U oU ooU uoXXX

Signal
iA ] (}u P .oU R }uvU }v.P

schedule ...
Adverb derived from a verb: transmit compressively, print system-controlled
In order to describe a process umanbiguously in a requirement, it is necessary
R oo ]v(}u}v R ] ] (} }uo ˘ov}v ] ]ooX
TR] }vv U } i v ] (}u X I( R
]vv` }v } R } R u]]vP ] }( ]v(}u}v u
be found and added to the requirement.
S]. }v v } l R cB˙ `R}u } `R ] R }
˘MSU cH}` }Lv ] R } ˘MSU cH}` } ˙}U U
execute the process technically?“, „When, or under which constraints, is the
process executed?“.
}uovP
C R ]. } ]o v o } ur}vu]vP
D]}v
(}uo}v }( R ]uvX OLvU R}Ù ]}vo ]uv

o (}u R v` }( R} }vU } R ]uv
vP]v o]U R R }]P]vo ]uv u .v v R o
by several more detailed requirements.
TR]vl o} }( R ] ˙ }X TR˙ } ]R
i } X Iv R] U l }v R u]v ].
]v(}u}v}R }˙X
O]P]vo ]uvP cI( R ]v˙ Rl ] v} }U R u R}u
system must display this.“
Soo voP WR ] ]vP ]o˙M T} `R} ] ]vP ]o˙M WRv `]oo
Example
be displayed? How ling will be displayed? Etc.

Iu} ]uvP AL R u R}u ˙u ]. R ]v˙
v ˙ R U v ]( R ]v˙ ].}v ] v} }U R u
home system shall display the error message „Access has been denied“ to
the user for three seconds.
P} ]o uvl]v(}u}v R }vv li
Tips & tricks
X TR˙ v vo˙ ˙ }v]vP RuU }vR v]o˙ v

} LX N} oo } ]o o`˙ v } ]vo ]v ˙
]uvX S}u } ]o o˙ ˙ }v]}v }( R
use case or are known with a previous requirement and then don‘t need to be
LX
25 Deriving Good Requirements
4. Deriving Good Requirements

Once the requirements of the stakeholders (in the following referred to as original
requirements) have been gathered, requirements that are good enough to serve as a
](}o}uvvvPu]X
In our experience, a common problem with original requirements is that they
uv u} Rv `R R o}uv }iU R ˙uU ] o }(X
TR(}U ]vP vo˙]vP R }]P]vo ]uv ]o 'v}v Roo ]
to the content that is derived for the system. In the following, we refer to these
derived requirements as system requirements.
L
A R ˙u ]uv R v
]v.U R u˙ ]+v } R
original requirements. The reason is that the
requirements engineer
v interpreted the original requirements,
v u(Ro}vU
v iR]uvU
v added missing requirements.
These (and many other) reasons lead to the
necessity of having the generated system requirements being reviewed by the stake-
holders and of resolving possible discrepancies.
4.1 Activities for Analyzing Requirements

U]vP R ] v RU }v `]oo Pv uv˙ ˙u ]uv
R u˙ R v u]]vPX W u R R ]uv .v v}R
]uvX Av ˘}v } R] ] R u} oo }( ]uvX TR
]uv v v˘ } R }R v (}u R ] (} R .v ]uvX
TR }}u ] uv˙ ~uRuoo˙ oo (}ZU `R R }}
formed by the most abstract requirements and the leaves are represented by the
u}]o]uvRv}o}vP.vX
In a use case-based approach, the roots of the requirement trees represent either
v use cases of the system or
v P}] }( v}vr(v}vo ]uv R vv} ]Pv } (v}vo
requirements.
An incomplete example is given in the following image.
R]uv`]RR].vuv˙R˘uo}(P
v * UCPPv
v * UCPvo}l}}}uoo˙
B* detect wish for unlocking
•* register movement
B* Rl R}] }v
•* record face
•* compare face N}vr(v}vo]uvP
›* }u æR ] v* security
›* within 2 seconds •* R}]}v]( }Pv]}v
v * UCP o}l}}}uoo˙ ›* }u æR ]
v* performance
•* Rl R}]}v`]R]v }v
F]PXPC}vv}v`v]uv
R
E }( R ] ]G˙ v o}` v` ˙u ]uv (}u
P]v ]uv ~}]P]vo } o˙ ˙u ]uvZU } u}].
the given requirements.
TR . ] } separate requirements. If necessary one original requirement shall
be decomposed into several requirements in order to examine them separately in
the next steps.
The second step, extract necessary requirements, can help to make sure, that
separated requirements are actually pointed at the considered system. If this is
v} R U R R u' (} R ˙u u ]v. (} (R
}v]}vX TR . `} R}o o] } oo }]P]vo ]uv
} P}} vP }]v (} (R vo˙] v } R oo }]P]vo
requirements are considered.
The next task is to abstract the given requirements vo R } oo ]uv
(i.e. the roots of the trees) are found. In the process, new requirements may be
v}vX TR ˘]vP ]uv } o ]v} v }vl
.vuv R]R˙X TR } oo `]oo }uo ]v R add missing
requirementsU]v`R]R(R]uv]voov.vX
TR }v o ]˙ ] } .v]uv v } ] `R]R }( R ˘]vP
v}]vRR}o(R.vX
At the end of the analysis, the found requirements can be improved and checked
regarding to their individual quality, e.g., to formulate them unambiguously.
Source Extract Abstract

Separate
necessary requirements
requirement requirements
requirements
Improve Refine Add

requirements requirements missing
requirements
F]PXPTRvo˙]l]vv}]`
TR (}u R ] v }u R (}v}v }( R
]uv}oo}v}(}RUvoovPPvu}or]uvX
TR ]} Rv] R } R ] v RX D]+v
}v v lU R o } R ˙u ]uvX F} ˘uoU l]vP
SWR[ R ]u_ }( ]uv Ro } .v R u} ]uvX
A ]v}v }( P]v ]v( v Ro .v]vP u]]vP ]uvX
Iv PvoU uv˙ ] } ˙ R Po}v }( R SOPHIST S }(
REPo}v ~ PR X r Iv(˙]vP o]vP] + r TR SOPHIST S }(
REPo}vZX
Iv U `R]o ˘vP R ]v]]o ]U lv}òP R P} ˙}v R
]v(}u}v ]v R }]P]vo ]uv ] vX Iv } } .ooR lv}òP
PU lR}o } }u v } lX A ovo˙ u}v v
uURv}}orRlL`X
Av ˘uo˙ o]}v }( R ] (} vo˙]vP ]uv v (}v ]v
the following video:
Po v} R R ] v } u ]v} R RE }X Au}vP
}R R]vP ] R } u]v `Rv } ˙ } R vo˙] (} R ]+v
}( R }]P]vo ]uvX FRu}U ] ] ]u}v } .v u]v}v
]] (} R ]v]]o ]X OR`] u} } Rv v u˙
used into the analysis of the original requirements.
4.2 Validating and Consolidating Requirements

AL R ]uv ] (}u R }]P]vo ]uvU ] ] u }
v R R˙ R R .v o]˙ ]] ˙ o]vP v }v}o]vP
them and that every stakeholder is happy with the requirements.
Validating requirements
Incorrect requirements impair the develop-
uv ]X TR o u]l ] U
the more changes have to be made - in
R] ]}vU ]v ( }
u˙ v ]v R } }X WRv o]vP
]uvU ] ] ]o } . .v R
P}o }( R o]}vX L }vUR o}v
}( R o]}v Rv] v
}v RuX AL ]vP v (}u]vP R o]}vU R o v
]v}}X Dv]vP }v R ˘v }( R RvPU }]o v` o]}v
may be appropriate.
.v
D o]˙ R}}
C o]}v Prepare and perform Incorporate
goals techniques R o]}v changes
B]oo˙U ] v ]vP]R `v }u o]}vR (}u

o˙vo]}v].u]o}v]vPRo}uvX
Consolidating requirements
Iv R } }( ]uv vP]v]vPU ]oo˙ ]vP R o]}v }(
requirements, discrepancies can occur at many points. These range from technical
u]vv]vP } ]} }vo }vG] R vv} }o `]R} v˙
]}voRoX
TR }vG] R ` u}o˙ R } o `]R ]v R RE } ]
]v}u]o] }( ]uv R }v }vG]vP }v }
}uvPP}o}(RlR}oX
TR ]uv vP]v l ] } ]v(˙ R }vG]U vo˙ RuU v
u]v R}` R }vG] v }oU }PR `]R R lR}o ]v}oX
AL }vG] }o}vU ] ] ]o } }uv R }vG] òo R
} }( .v]vP R }o}vU ]v } } o } `}l } }o}v (} ]u]o
}vG]`]Ro+}X
}uv
D }vG]
Iv(˙}vG] Avo˙}vG] R}o }vG] }o}v
F} R }( R U R }o }( Rv] } R}} (}uU R

}v R }v]v }( R }i ~XPX]o]o]˙
U }( lR}o } }o
R }vG]ZX F} }vG] }o}vU R Rv] vP]vP (}u ]o]vP
}u}u] } R oo vlX E]oo˙ ]v R }( ]v(˙]vP }vG] `v
]uvU v }uRv]o }uv}v }( R ]uv
will help.
SOPHIST
C}uvv˘
par excellence
Method inventor
Speaker
Author of books
PoRoXH]l}uuv]BR}]vJ
Consultant Coach
Trainer
Weoceryou:
We support you competently, energetically and expen-
diently both in adapation of your development processes
and methods and in the implementation of your project.
Our customers include many world-renowned companies.
The large number of positive opinions and project reports
fromoursatisfiedcustomersspeaksforitself.
Takealookat www.sophist.de/referenzen
Ourservices :
v Iv(˙U˘o}]v]v}}vo(}]u}uv
l]vP]v}}vR}v]v]v˙}}Pv]}v
v Eo]]Uvo˙U}v˙v}uv]uvv
architectures appropiately
v OvR`˙]v]uo}Lò]}v}}uo˘
systems
v Work in agile and adapted way
All of this and many other topics from the world of requirements
v ˙u vP]v]vP ` }+ ˙} ]v R (}u }( }vovPU
coaching, training and lectures.
How can we help you?

We would be happy to elaborate a concept with you
to provide you with the best possible support for
˙}}iX
C}v`]R}}o]P}vP
+49 (0) 911 40 900 - 0
heureka@sophist.de
D}uvvPvIuvP
32 R]uv
5. Documenting and Imparting

Requirements
WRR `]R } `]R} ].}vU u}or } vo ovPP r `RR
vU lo}PU } ].}vV ]v } } ]u R ]uv }
}R òoU R ]uvP u ovv v ]} ]vGv]vP (} u
}v] } o R }] Rv]X AL ooU` oo˙ }v o]] v
vo˙ ]uv (} }oU (} }R }o ]v}o ]v R o}uv
process, such as development, test, system architecture, and many more.
Accordingly, an important task for requirements engineers is to impart the
requirements to other people in a way that they understand them and no
u]vv]vP } u]]v}v }X TR ]uv vP]v R}o
R]vl } R}` R `v R ]uvP } l oX F} ˘uoU R v `]
down (document) all the requirements and give them to the recipients to read. Or he
v ol } R ]uv } i}]v o˙(o ˘]v }( R ]uvX
O }i ˘]v R}` R (o ]uvP oo˙ }v] }( òo
R}PRr}}u]v}v}(]+vRv]X
5.1 Imparting Requirements without

Documentation
Requirements and user stories can also be communicated without classic requirements
}uv}vX E]oo˙ ]v R P]o `}oU ` u }] ˘]v `]R
Rv] R ]v}o o }uv}v v u} }uuv]}v ~XPXU
}] } }˙oo]vPZX H}Ù ]uv }uv}v }v u}o }
vo ovPP v R }}v v o}` v} uoo˙ ˘o]X Iv (U
}vv]vo˙}u]vRu}lvP}(RvPR}(}R}}vX
Storytelling
WR} vi}˙ o]v]vP } u}v}}v o ]( R˙ }o vi}˙ R u }vv
wrapped up in a good story? People have always been fascinated by stories. Since the
P]vv]vP }( uU lv}òP R v }v R}PR }]X I v} ]]vP
R }˙oo]vP ] o} ]v ]uv vP]v]vPX W ]+v ˙ }(
stories.
v Background stories tell something about the context and the usage of the
˙urR˙P]]u}vlP}v]v(}u}vX
v Personality stories introduce a persona and make them tangible.
v C}v]}v }] v} R ]v]o ]}v R ˙ P]vv]vP }(
]uvvP]v]vPvu}`R˙R˙u]vX
v E˘ov}v }] clarify individual processes and behaviors of the system.
F}u}˘]vUR˙u}(vo˙]vREX
D}uvvPvIuvP
33 R]uv
User Story and Story Mapping

U }] ] ] (v}vo] X } }( ˙u (}u R
}( R }v `R} v R (v}vo]˙ } }˙X Iv R P]o `}oU
R ]uvP }( ]uv ˙ uv }( }] ] `]X Iv ]}v
} }uvvP R }vv }( R }˙ ~who wants what from the system for
which purposeZU}˙v}uuv]}v}u]X
M]}v`]R}]}PRo˙`}l}]vP}R(}oo}`]vP'vP
v F}uovPR]uv]v}]X
v Discussion with the people receiving the requirements, based on the formulated
user story
v Joint agreement on the contents of the user story
Me
as a
.
User..
C C}v}v C}v.u}v
F]PæXPrCrM}o}]vP}R}vJ+]
U }] Pvoo˙ ] }vo˙ ˙ uoo (v}vo]U } R `]oo oP

vu }( }] } R } }( o}uv }iX Iv } } u]v]v
an overview, they can be related to each other with the help of a story mapping.
Prototypes
Prototypes can be used in many areas of system development; they are suitable
(} o]]vP ]uvU (} o]vP RuU } oo (} ]uvP RuX A
] R] }]o o]}v U } R] R]X W u
good experiences with the following prototypes in system developments:
v W](uPRuv}v}(Rouv}(]v(X
v Fv}vo }}˙P A o]u]v˙ ]uouv}v }( (v}v Po }(
XPXUR(}uv}v}v}(oX
v M}lr }( R ]v(P Av ˘v]}v }( R `](uV R ]Pv }( R
]v(]o˙}Pv]oX
D}uvvPvIuvP
34 R]uv
Pictures
A ] ] `}R R}v `}XXX R}v ] }( ]v(}u}v
ov (} ]uvP }v lv}òPM TR] ] ˘o˙ R ]ouu }v `]oo (
`Rv ]vP ]uP } ]u lv}òPX Mv˙ }o .v ] ] } ]
v `]R ]v ] Rv } i ˘o]v Ru ˙ ]vP ovPPX TR(}U
picture can be of great help in storytelling.
M}}U R R R}`v R ]
v uu uR ' W}o(U
`R]R ] ]o (} ]uvP lv}òPX O(
course, the use of pictures is limited and not
every aspect can be expressed well in a
picture. But especially when it comes to
o vPuvU ]u]}vU ]XXR
parts of a system that can be seen and
represented visually, pictures help
v}u}o˙]v]uvPlv}òPX
Tol]vP } ]uP ]v R] }v˘U ` uv v ]v(}uo ]o v}vU
XPXU`]vP }( R R} }v } ] R }]}v]vP }( R ]oov
uX I v} (}uo } u](}uo v}v o]l v R]o u}o
}v}(vv}]vUML]PuX
Create joint artifacts

Av}R `˙ } ]u ]uv ] } i}]vo˙ ]}vo (X F}u }
˘]vU R i}]v }v }( (} R ]uv ] oo˙
]oX H}Ù ] ] o} ]uP]vo R }R (U o]l R] } ]Pv
}uv } }vP ]v}vU i}]vo˙X E]oo˙ ]( }v }
systems engineering, it might be useful to create architecture documents (see para-
PR ı r S˙u vP]v]vPZX I Ro } ]l ( R R }
v˙`˙ } }] PvvP (R +} v } o } R (
in subsequent process steps.
5.2 Imparting Requirements with

Documentation
L ol } R u} }uu}v ]uvP Rv] v}`P }uv}vX
D}uv}v v (}v ]v o] }uu]]}v]vP o}vR] ]v R (}u
}( ].}v R } ]uv ].}vU o} (} }uuv]}v
`v uv `]R]v v }Pv]}vX FRu}U R] Rv] }u
almost inevitable when one wants to make requirements available for reuse.
TRv}vPNoovPPXu}or]uv
WRv ol]vP } }uv}vU ` vv} }] R u Svo ovPP_
v Su}or_X B}R ˙ }( }uv}v R vP v ]vPX
D}uvvPvIuvP
35 R]uv
No ovPP }uv}v ] ]v ]v R v} ov]vP }( v}}v ]

necessary, since everybody understands language. Natural language is also suitable
(} }uvvP oo ˙ }( ]uvX H}Ù u lvU
voovPP]}Lvu]P}}u]o]vPX
Ov R }R RvU u}or ]uv }uv}v ] òo ]
(} o}}l]vP R ˙u ]v ]}o}v (}u ]+v U XPXUR o˙
o ]` }( R u]v}o}P˙l ]v(}u}vl } }U R (v}vo
]` }( `}lG}`l ˙u }U } R r}]v R]}o
R]oou]v˙u}v}vUu}vP}RR]vPX
D } R }u v}vU `R]R ] vu]P}o˙ vvo (} R
trained reader, misunderstandings can be avoided. However, the disadvantages are
}]} r R }}v]vP v}}v u . ov v v}} ˙ oo
]vX
Use-Cases System processes States

Outside door
Dynamic views on
Gv
requirements
UrC closed
Action 1 }lGv
Gv Unlock
door open
Iv(}u}vu}o Glossary
Term .v]}v
D
Access Door
structures
1 1 In the smart home system, unlock must
unlock uvR}}(vPR
locking mechanism of a door in order to
be able to open the door.
Tu]v(}u}v
grant
Door handle 0...*
r']
access
F]PæXPV]`}v]uv
Ov ˙ }( ]Pu (} ] }`v ] oo˙ v} 8]v (} vvP }uo˘

issues in models. Besides, models are not universally applicable. A common approach
is to combine model-based and natural language requirements to take advantage of
both forms.
D}uvvPvIuvP
36 R]uv
A prime candidate for natural language documentation - the

FunctionalMASTER
F}u R }( R vo ovPP }uv}v ` }+ v }R R
in our opinion is easy to use. The SOPHIST sentence template, also called the
SOPHIST ]uv uoU ] o]v R .v R }( ]vPo
]uv vvX TR }( ]v]]o ]uv ] v]X
S} ] }]o } u]v . PovU `RR ]u}v }u}vv }(
a requirement are missing. Especially when specifying in a foreign language, a
.v]uv(u`}lvRo}}}uv]vX
U]vP R ]uv uo ] ˙ } ov v v`v o]vP]
+ ]v R ˙v˘ (} `]vP ]uv ] o˙ }]X C}u }
arbitrarily formulated prose requirements, the quality of the requirements increases
]Pv].vo˙ L R . o]}vX TR SOPHIST ]uv uo (}
(v}vo ]uv R }u v ]vPo }( u} ]uv
vP]v]vP } ]v }uv] v ] ( } ˙ R Fv}voMASTERX
B }v } o ˘]vU ` R (R o} R }v v
.v }R uo ]v } } } v}vr(v}vo ]uv v
}v]}v `]R } uoX M} ]v(}u}v } } v` uo v
(}v]v}}}lR]uvEvP]v]vPvMvPuvRX
Step 1: Identify subject Step 5: Identify object
matter SHALL -
<Subject PROVID
D
A E `R}uMn`R
MAE
SHOULD ADAE AD}iAE
u'AE WITH THE ABILITY TO
Step 3: Identify
WILL BE ABLE TO functionality
Step 2: Define import-
Step 4: Define type of functionality
ance
F]PæXPFv}voMASTR
O }i ˘]v R R}`v R R . ]v o]vP `]R R uo

v} } ˙ ]v R P]vv]vPX W]vP R . ]uv }]vP } R
uo (o ou˙ v u} +} ] ] .X H}Ù R +} u}o˙
}u (}u R ( R }v R } G }v lv}òP ouv R v
in the sentence due to the template, which therefore improves the requirement
]uu]o˙X M}}U ]v R P]vv]vP }v `]oo R]vl } `R]R uo }
choose: Is the requirement for a system that is supposed to do something on its
}`vM I R } v ]v( ]v}oM I( }v uvP } P R}PR R . (`
R}U R `]oo .v R uo v + `˙ } `] P}} ]uv
quickly and professionally. We would be happy to support with training, workshops
}R}PR}vovPX
37 Requirements Management
6. Requirements Management
R]uv uvPuv ]vo oo R } R } R u]v ]
of RE and the further use of requirements. In the following chapter, we will give an
]v]PR ]v} R `}o }( ]uv uvPuv ~RMZ v o P]vP
R }vU } `R]R ˘v }v R}o (}u `R]R ] }( ]uv
engineering.
Why dealing with managing requirements at all?
XXX]uo].Ru}v]}]vP}(
complex plans during all develop-
ment steps.
Gutes
Require-
Good
XXX]u}}uuv]}v`]R]v requirements
and between the teams. ments- ... saving nerves of people involved.
management ...
Engineering
...
... increases the quality of require-
ments, porducts and processes.
F]PXPG}}]uvuvPuv˙}+
W ]. R }v (}u .P X `]R `} }u]vv vX
Requirements are changing

As requirements change frequently over the course of the system development,
] ] v˙ } v]P òo `]R]v }oo ]uvX CRvP u˙ vP
from small repairs, such as spelling errors, to complex changes that include extensive
]]}v }( v }v }( ].}vX A RE }v R}o }v]v
approach on how to deal with so-called “change requests”.
Requirements are reused

It should always be kept in mind that requirements are never collected for their
own sake, but that stakeholders, such as developers or testers, have to able to read,
understand and work with them. Requirements engineers must therefore ensure
R }uRv] ]v(}u}v ] v oo˙ ]v R ]uv }oo}v
~]uv].}vvl}}lo}PZX
6.1 How much Requirements Management Makes

Sense?
The importance of requirements management within the development process is
]o˙ o } R u }( R }iX TR ] v} (}uo R ]
R}` uR } R}o v (} RMU R (}oo}`]vP(} v Ro }
uRu}v}(RMvP
v vul}}(]uvv(R]v(}u}v
v expected lifespan of the product
v frequency of the rate of change
v number of people involved in the process
v availability of the stakeholders
v quality demand on the system
v degree of reuse
v complexity/ complicatedness of the development process
v heterogeneity of stakeholder opinions
v number of releases to be developed
v ˘]vP}}ov]}vuv(}]uvuvPuv
v }R]vR}i
v ˘vo]uv~v}uU.}v}}}}P]o]vZ
F}u } ˘]vU ` }uuv v} } (oo ]v} oRP˙ }( R]vl]vP R SI
R o`˙ v R] `˙_ `Rv vo˙]vP ˘vo }v]}vX T˙ } .v } R
two things instead:
v WR]R}v]vvRvPov`R]R}vv]vGvM
v H}`X˙`Rv˘vo}v]}vu}].M
Iv U ] R v R}`v R v u]v} RvP } ˘]vP }v]v v
]P oo]}v } ]u}uvX Iv R (}oo}`]vPRU ` `]ool o}
o}}l}u}(Ru}]u}v}(RMX
6.2 Versioning and Baselines
A ]uv RvP } R } }( }iU ]v}]vP R ]}v]vP }(

requirements has proven to be a useful tool in order to understand at a subsequent
UR}`]uvRRvP}uX
WRv vP v` ]}v }( ]uvU R . ] } }˙ R
requirement. The old requirement is kept and linked to the new version. The new
version is given a new version number. The old requirement is entered into the
R]}˙ }( R ]uv ].}vX TR v` ]}v v v}` ]X TR]
} v R v} ]v(}u}v P o}X Mv˙ }}o o} ].oo˙
(} RM } ]}v]vPX TR] ] }v }( R }v (} ]vP }(]}vo RM }}oX
M}}U ]}v]vP o} Ro } ov o v RvP }( ]uvX
Iv }]vP }U ]. }( R ]uv ] u]v }v `R]R }v v
` }v v˙ o P]v }]vX TR] o}v }( ]uv ] ( }
S}v.P}v_X I( }v.P}v ]vo oo R ]uv (} oU `
l }( So]v_ ]v }( S}v.P}v_X R
E }v.P}v v o]v
vP]vv]vu(}]v.}v}X
Iv } } .v } `R]R ]uv }( }v.P}v } o]vU
traceability concept is required.
6.3 Traceability
Definition of traceability according to SOPHIST [RUPP2 0 ]:

T]o]˙ ] R ]o]˙ } l R }vv}v v vv] `v
]v(}u}v R ] v˙ u ]vP R vo˙]U o}uv } R
disposal or replacement of a system.
W]R ]o]˙ }]vP } R .v]}v }U ] (} ˘uo v (}v

}U `Rv ]uv ] RvPU `R]R }R ]uv +U `R]R
]uv v˙ (} R o}uv }( ˙u (v}v } `R]R
cases cover these requirements.
T]o]˙ ] (} + v R]PRo]˙ ]uv uvPuvU
because it supports the following aspects:
v V].]o]˙P H oo R P}oU P ]uvU X v
]uouvMWoo].}vuM
v Iv.}v }( vv]P WR]R + } RvP }( ]uv
R}v}Ro}uv(M
v RP WR]R ( (}u R o}uv } ]v }R }iM
v C}uRv]]o]˙ v }]`P H}` R R ˙u o} v RvPM
WR]R˘vu˘(}}oR}}vPM
A ]o]˙ u}o v .v `R]R ]o]˙ ] vU `R} u]v]v ]
`R u v ]v `R `˙ v R}` R } } }
R } }( }i v ˙}vX O ˘]v R R}`v R ] R}o v}
vuU R}` uR +} ] v l } v u]v]v ]o]˙
P]vPRuvP]v(}u}vX
6.4 Change and Release Management

Fv v }uo˘ RvP } ˙u v v o} } ]v }
} } oo } r ] ˙ }oovP RvP U ovv]vP }( o }
rolling out implemented changes. Suitable methods can be assigned to the discipline
change and release management.
TR(}oo}`]vP.PP]}v˘}]`
Commissioning
organization
Legislative institution
Portfolio/product
management
Change Release
Planning Operation
Innovation management management management
Problem management
Development, testing,
logistics, production,
operation, maintenance,
quality assurance
F]PXPCRvPvouvPuv
Ov R oL ]U R }vo } (} RvP v v r ˘ov}v }

R uv}v } ]v PR r SWR ] R]uv EvP]v]vP _ v
found. On the right side, the process of a change can be seen. The process goes from
RvP uvPuvU } R ]uouv}vU } R v( }( R RvPU ]v}
R}}v}(R˙uX
Change management
CRvP uvPuv }v}o R o]( ˙o }( oo RvP `]R R ]u } ]v}
the changes into the development process in a controlled way. The tasks of change
management include
v performing impact analyses,
v assessing changes,
v ]}]]vPRvPU
v planning changes,
v v }uuv]vP R v }
refusal of changes.
Release management
A }}v ovv]vPU u]v}v v }v}oo]vP }( ]o v òo R
]vP}v ]v} ˘]vP ˙u v]vPU o uvPuv }u ]v} o˙X
The release manger has a special role here, controlling that all deadlines are met.
Ov R ]uouv}v ] }uoU R v` ˙u u o] } R
customer. The content of the release can vary a lot - for example, a new product
]}v u˙ `Rv uv˙ ]vv}}v R v ]uouvU } oo
u˙ `Rv ]o P ` .˘X I [ ]u}v } }] ] R} -
o]vU]v]vP +U uvo R} v oo }R + }o `]R R v˙
]v(}u}v ]v uU XPXU ]v R (}u }( o v}U } Ru (} R
changes.
Establishment of an Improved
43 Requirements Engineering
7. Establishment of an Improved
Requirements Engineering
R]uv vP]v]vP ] }( ˙ o}uv }iU v} o`˙ ]v
v +U 8]v v (˙]vP `˙ (} ˙}˙ ]v}oX I( R ]uv
vP]v]vP }( }uv˙ Roo ]u}U R] ] R ]PR o } X CRvP
may concern the process, the methods and also the tooling or all at once. Regardless
of whether one wants to go from a waterfall-like to an agile requirements engineering
} o] R o }u]}v } R] ]uv vP]v]vPU R RvP
R}oo`˙˙uoo˙X
7.1 Changes within an Organization

TR B]R }]o R]o}}R H Sv R ˘]}v S]o }(
R .'_X TR] ] }v[ }vo˙ o˙ } RuvU o} } }uv]X Ml
RvPU i R uv }( }u v v }X TR} `R} (]o } l
`]R Rv}o}P]o }P `]oo }}v oP R]v R }u}vX E]oo˙
}] o]l ]P]o]}v v ]vGv ul uoo˙X TR[ `R˙ ˙u v
o}uv } v } ˙ }v]]vPv` ]v]PR v }}vXTR]
}vo}]vGvR]uvvP]v]vPX
H}Ù }v o} uv
}v]vP R ˘]vP v RvP
o`˙ uv o«vP P} }( }uR]vP
familiar and of the sense of security
}+ ˙ R lv}`vX C}vvo˙U
change is always accompanied by fear,
concern or doubt.
The need for safety is rooted deeply
in human beings. New things that are
P}]vP } o R (u]o] }Lv
perceived as a threat. Our experience
shows that especially the fear of failure,
R R]}v } ov }uR]vP v`
and to make mistakes in the process is
}uv]vX F} (o o]RuvU ]v R P]vv]vP v `v }( R
}ou ] v˙U v (} }v v u}}v } RvPX I( oo }( R] ˘]U
] ] u } o}}l]vP (} v ]u}uv ] vU }v ] R v U }
establish it.
7.2 The Establishment is a Project!

SR ]u}uv u o]R (oo˙ ]v} v }Pv]}vX I R}o
uR +} ]v} R o]Ruv ]v} o}uv }iX I }v[
u' ]( v` }U uR} } v` }}o ] } o]R v} v ](
R˙R}]vvv.X
W R v ] } v } P]vV ]vP R vo˙]vPU }o ] }(
R P]o]v R o]u] R }o}v X N} }vo˙ vlv}`v P]o]v
]v.Ui}LvP]o]v}v]Roo˙}v[˘]X
Ro]l
reac gy
h ate
able Str
S}o}v
Finding and
RE methods What introduction process
How
}E v
}u
ce
en
]8
ri
xpe
]v
E
˙
With How
RE tool what RE process
R]lu]v]u]}v
L`
F]PXPG]o]v}(RE]uouv}v
7.3 An Agile Design of Changes

TR ]+v }R (} ]u}]vP ]uv vP]v]vPX O
}RU `R]R ` }Lv ]v } }i v `R]R ] ]o (} uv˙
]}vU]}vP]o]X
We made the experience that our customers' wishes are constantly changing. We
can successfully meet this dynamic with agility.
Some of these changes are not content-related, but concern guidelines or new
Rv}o}P]vo}]+v`˙}(`}l]vPX
H}Ù ` v o} o `]R R] ˙vu] ˙ vP } P]oo˙ o}
approach.
...
Online/Remote Trainings
Your SOPHIST training - almost anywhere in the world
Online/Remote trainings are specifically designed to deliver knowledge

and skills via the internet. The unique and carefully thought-out elabora-
tion - in terms of content and didactics - as well as a maximum number of
participants of 12 persons ensures a perfect online knowledge transfer.
F} Individuals and smaller teams, our „open trainings“ are perfect. And
due to the modular structure, the combination of different focal points
and the possibility of individual adaption, online/remote trainings are also
perfectly suited for internal company trainings of complete teams.
O( } } òo rlv}`v C PRE ](] ]}v ]v]vP } o}
available in this format.
XXXv}u'`R
T} ul R] }R `}lU ` `]R (` ] u}v R u o]

within the guidelines that have been set.
v The team itself must have authority over its working methods, i.e. it must be
allowed to make independent decisions within the set limits.
v ˙}˙
E v } lv}Ù ]u }( ˙]vP } v` } u}]. uR} ] }
]vPRuv}ov}uR]vPrvRou˙]X
Our experience taught us, that in order to carry out such an approach, there are two
R ]v R }]o]˙ }( v}u}o˙X F]U }vo˙ u Roo
}v] (} u o}v R } oo R v (} }v v v} }vo˙
signal willingness for change. Second, there should be at least one "Elvis" in the
team, because no one has more imitators; everyone wants to be like him. The success
}( ]u]}vo ov]vPU v v ]v v (]o] R o
v ]v}}v }( R v` }X Iv R (}oo}`]vPU ` `]oo˘o]v R ]v]]o
}(R}v~.PXZX
F]TR]vPF] Present results

R.vuv
Planning Share learning
experience
Improvement- R}
Backlog
Avo˙ Apply method
current Develop working
status hypothesis
Improvement-
Sprint-Backlog
G«vP]v
with the method
Moo]UG]oUU
B T]vT]lUD}RvD}vRU.v]}v
D }(}vXXX
C}uv˙
F]PXPO]`}vP]o}(}RvP
Iv R P]vv]vPU R v ] vo˙ v `}l]vP R˙}R] ] o}X

The focus lies on the current working method of the team. The teams examine the
]uv vP]v]vP uR} v }}o vU } ooUR (]}v o} R
˘] `]R]v R u v } ˘vo vU XPXR U lR}oX TR ovP
] (} ]u}uv } ]v v ]u}uv lo}PX AL v(]vP
them to the improvement sprint backlog, the training for the method starts. The
u ] `RR R v u } }vo˙ R} ]vP ]v R ˘] -
ment are trained. While the method is being applied, the team gains experience
]v o˙]vP R uR} v o `}l]vP }v]}vX A R] }]v R u v
v ]U `RR R˙ `v } ˙ } R ]vv}}v ]v }v ] ~`}lR}
RZ } }vv}o˙X D]vPR]uU R ]v ] v˙ uR}]o
help they request. This can be a further training, a review of the results, coaching,
]vP v X TR u } Rl `]R R u `RR R ] v
(} Ro v R}` R ]v }( R ˘]uv }P]vP ] } l Ru
]v R ]o˙ uvPX T} o R ˘]v P]vU R o v }

the stakeholders and their feedback is requested. The team sees how easy or how
hard it was to apply the method and it hears from the experimenters when they
R R] ov]vP ˘]vX TR] oo}` R u } G ]v R }
}v R } v oX TR u ] (}u R } .oo R
improvement backlog again.
The team that has found an improvement can talk about it and their experiences to
}RuX˙B }]vP]UR˙lR}oo}oo˙]v}R]}`vRvX
If there is not only one team or topic to be improved, this agile approach can be
o`]Ro(u`}lRSAFSAFX
7.4 Work Packages of an Establishment

T} v R }( ]uouv}vU ] ] `}R`R]o } ov v `}l } R
most important steps using the following concepts.
v MlvP}vPPov}v`R}Roo˘]}R]X
v C}v (} ]uvP lv}òPP S R ˙u ]or }(
knowledge.
v P]o}vP }vP F]v R ]] (} `Rv v `R `]oo ˙ `R]R
]o}}iX
v M]P}v }vP TR]vl R}PR R}` } o `]R R ˘]vP ~XPX˘]vP
U
].}vZX
WR u' oo R }v ] R R ˘}v }( R u ] u}v]}
v u] } u R] X F} ˘uo ]v }( ulvP
}vU ] ] `}R .v]vP R P}o }( R}` uv˙ }o Roo R `]R R
]v(}u}vU ]v vX Iv Po ]vo ] Roo Rl R}` uv˙ }( R
targeted people have already been convinced of the new ideas. This is the only way
to know whether the executed measures have been successful.
48 Requirements Engineering and Agility
8. Requirements Engineering and Agility

The word “agility” is on everyone's lips these days and currently it is impossible to
imagine the area of system development without it. Therefore, we must ask ourselves
R}vPWR}]uvvP]v]vP]vP]o˙uo}uvM
F] }( ooU` v oo˙ ˙ (}u } ˘]vU R ]uv vP]v]vP ]
o} ] } ]v P]o }RX Mv˙ R]vP oo ]+vo˙ vU } ooU
}v ]+v uX H}Ù ]v v P]o }v˘U R }Lv ]}vo
tasks for requirements engineers that are usually handled by other roles in classic
system developments.
There are various agile approaches or frameworks. The best-known framework is
scrum. Typical for all agile approaches is that the product is developed step by step.
Iv uv˙ ]}vU uoo ]vuv }( R } o}U `R]R o ]v
]P ]X AL R ]}v R ] } } v }}uU `R]R v
shown to the stakeholders so they can give feedback. Obviously the feedback given
u]vP]v}R]uv}((]}vX
A R P]vv]vP ] ] ' v} } R]vl }} uR } ˙ ]o ]uv
that will be implemented at a later date. There will be several changes due to
(lX TR[ `R˙ ]v P]o }v˘ ` P} `]R R }R }( ir]vru
requirements engineering. This means we work with the requirements that are
}}o]X
TR] v` RoovPX F} ˘uoU R u} vv] `v
requirements to think about. It shall be avoided to demand something in one
]}v R }vG] `]R ]uv (}u ]} ]}vX T} o `]R R]
RoovPU ` ˙ 'v}v } o o]«vP }( R ]uv ]v } } R
v} vv] ]( }]o~l˙`} S]vvv_ (}u R INVEST ]v]oU
PR X r Qo]˙ }( ]uvZX W o} Rv] (}u R o]o
`}o}(]uv~XPXUu}oZ]v}}ulR}vv}v]]oX
Roles of a requirements engineer in an agile context

Iv v P]o v]}vuvU R u ]uv vP]v }Lv }v[ ˘]X
H}Ù R i} oo R } }vX vE P]o o}uv vv} P} `]R}
o]]vPR `]R }(R lR}oXTR] lv}òP v } } v
]u (} R o}uv uX Iv P]o]˙U ] [ oo˙ R i} }( R }
owner. However, the product owner can also be supported by other specialists, who
oo }˘˙ } }`vU ]v vo˙ } }uu v ]uv
engineers. Obviously product owners have more tasks than the typical requirements
vP]v]vP ]X TR˙ o} Rvo ] o]l o ovv]vPU ]}]}vU
and decisions about the scope of the product to be built. These are typically not
o] ]uv vP]v]vP lX S} }]}o˙U R ] }u ]}vo `}l
for requirements engineers in agile contexts.
Brochures
www.sophist.de/wissen-for-free
Requirements engineering activities in agile contexts

Iv R] }RU ` R o˙ ] R u]v ] }( ]uv
vP]v]vPX TR o]]vP lv}òPU ]]vP P}} ]uvU ]uvP
requirements, and managing requirements. We will take a closer look to requirements
uvPuvov`]oo`]RR.Ru]v]X
Eo]]vP lv}òP PTR ]ov ]v R P]o `}o v (}v ]o˙X F}
]uvvP]v}} }`vR`}l ]v[v˙]+v}R}v]v
the classic world. Product owners also think about goals, stakeholders, or system
context boundaries.
However, agility brings new, great
techniques (such as vision box, news from
the future), which can also be used in
o]o o}uv }iX P}
}`vU R}` }Lv ( }v ]o
RoovPX TR˙ v .v ˙u v
context boundary, but the boundaries
will be very "unstable" over a long period
}( uU R o}uv u
deals with the requirements only step by
step.
Deriving Good RequirementsPIv P]o }i P}} ]uv v }
] (}u lR}o uvU }}X H}Ù R ]uv }Lv o}}l
]+v }( ]+v `}l]vP uR}X Uoo˙ R ]uv v}
`]'v}`v]v˙]oX
Instead, we describe the requirements in a more rudimentary way in order to
talk about them. Rough user stories are more likely to be created. We use quality
]] } oo R}` P}} ]uv X Iv P]o }v˘ ` ]+v ]]
Rv ]v o]o }vX W }Lv l R INVEST ]v]o R o]˙ P}o }( }
]uv~PRXrQo]˙}(R]uvZX
E]oo˙ ]v R] ]˙U «vP }( }] ] v ]u}v }]X S }Lv
v o} }v } «vPX TR o «vP Rv] v ]]
that have worked well for us.
IuvP R]uv PIv R] u]v ]˙ R uv˙ ]+v `v
agile and non-agile development. In the agile world, requirements are imparted
]u]o˙ R}PR }v}v ]v .vuv uvPX S} R v} o}vP
the typical documents in which one can read the requirements. Instead there is a
}oo}v }( ]uv ]v } lo}PX TR ]uv v ]
]v ]+v `˙ v }uuv] ]vP ]o Rv]X TR ' `˙
} }uuv] Ru Rv ]}Pv] ]]}vX W }Lv Rv] R
}˙oo]vPUvP]vP}U}]}}]uR]uvX
The requirements collection in agile contexts

Iv o] }R oo˙ ]uv ].}v ] ~XPXU ].}v
sheet). At the end of the requirements analysis, this contains all requirements in the
] o]˙ v ]v R ] oo }( .vuvX Iv P]o }v˘U `
a product backlog for the collected requirements. All the requirements known at
]v u v (}v RX B r v} oo ]uv (} } v
(}v RX Av o} v} oo ]uv (o.oo R ]Pv o]˙ ]] v
R ] oo }( .vuvX TR }vo˙ o] } R ]uv ~} '
} lo}P ]uZU `R]R o] ]v }}v ]}vX Iv ]}v } R
R]UR]}vu}ui}]+v}]uv].}vX
WR]o R ]uv ]v ]uv ].}v }Pv] v } ˙
Rv]o }o}vU ]v } lo}P R˙ } ˙ ]}]˙X TR] uv
that the requirements at the top of the product backlog currently have the highest
]}]˙XI]]}]oRR}v}Rv˙Rv]o}o}vX
Detailed High
Product Backlog item

Priority
Lo}(.vuv
L]o L}`
F]PXPTR}lo}P
TR] ul R `}l }v R }vv }( R } lo}P ]u u} ]8oX

However, the problem can be handled by using various techniques. We successfully
]+v ˙ }( }˙ u } `}l `]R }R (}u }( }uv}v ]v
]}v } R } lo}PX TR uv˙ }}v (} ul]vP ]uv
vP]v]vP}.o]vRP]o`}oX
52 Systems Engineering
9. Systems Engineering
Within a systems engineering approach an
}Pv] ]uv vP]v]vP }u
decisively more important. Not only because
the system analysis at system level lays the
(}v}v (} R }oo o}uvU
also because working with requirements is
G oo oo }( R }v] ˙uX
Before we present these statements in more detail, there are some key terms that
o}˙uvP]v]vP}.vX
9.1 Definition and Purpose

TR..v]}vRu˙uvP]v]vPX
Definition systems engineering according to INCOSE

[INCOSE2 0 ]:
S˙v vP]v]vP ] v ]v]]o]v˙ }R v uv } o]
(o ˙uX I (} }v R .v]}v }( }u v v ]
(v}vo]˙ o˙ ]v R o}uv ˙oX A òo }v R }uv}v }(
]uvU v ]Pv ˙vR] v ˙u ].}v }v]]vP
the complete problem.
Llo}o}}l(ù]vR].v]}vX
TR }uo }ou ( } R }v]}v }( R v o]( ˙o }( R
system. Therefore, we don’t only consider requirements that address the use of the
˙uX F}u R ˙ P]vv]vP }( o}uv R v }( }}vU v -
}}vU }PU v ]voo}v oo R `˙ } R ]}o }( R ˙u u
included.
O]}o˙v}Rvou]vR.v]}v]R˙uX
Definition system according to SOPHIST [RUPP2 0 ]:

A ˙u }v] }( o X TR ]]o R]} v } o (}u
R]v}v}(RX
Av}R ]u}v ]˙ }( ˙u vP]v]vP ] o} ] (}u R]P TR

}u}]}v }( R ˙u ]v} ] }u}vvX Iv R (}oo}`]vPU` `]oo( }
this as "system architecture", in which requirements will play a role again.
Mv˙}(R˙u`v}v]v}}iR`}}RR]P
v B }( R] }uo˘]˙ R] }u}]}v ] }v] } o
levels. A part of the system is considered as a subsystem and again decomposed
into its parts by another architectural step.
v TR }u}vv }( R ˙u }u (}u ]+v }vU R }L -
ware, electronics, mechanics, etc.
As a result the development of the system (or a part of it) is embedded into a larger
˙uX TRU R ]uv (} ˙u v˙ oo }( }u}]}v }u
from the system architecture of the system level above.
TR ] }v o u } o}}l (}u R .v]}v }X S˙u vP]v]vP
] } } o] S(o_ ˙uX F} U ˙u ] (o ]( R
following goals have been reached:
v TR }i ] ]v u PU `R]R uv R R u}v (} o} -
uv˘vvo}uvuùX
v TR u }}v } R v u òo R o]˙ ]v R
}}v}(R˙uvPvX
v TR ˙u } R ] }X TR u˙ ]+ (}u R ]v]o
stakeholder requirements because, among other things, the system above may
change.
TR . }]v ] ]v R .P o}`X TRU R o}uv u v R
development expense are shown with and without the use of systems engineering
methods.
Risk
Traditional System Development

System System V].}vv Time
Ro]}v}(C}u}vv Vo]}v Mv(]vP
Analysis Architecture
Risk
Systems Engineering-based Development

Time
F]PıXXPC}v]l(}vL]v}]vP˙uvP]v]vP
˙B «vP u} +} ]v} R ˙u vo˙]U ] ] }o } }oo u v

R u}v˙ `R]o u]v]v]vP R u o]˙X TR ]l ] u]v]u] o˙ v v}
}vo˙]vPRo]}vRX
9.2 Embedding of Requirements Engineering

F]P ıX R}` R ]v v }Pv] ˙u o}uvU R]PRo]˙ ˙u
analysis should be performed. As indicated in the previous chapter, a system may
consist of several subsystems for which we suggest a similar procedure.
TR]]]v]vv]oo}vX
• }u
C
requirements System analysis System
].}v
requirements
• C}vo
documents
High-level subsystem System architecture
• Wishes requirements
Subsystem analysis Subsystem

requirements
High-level component Subsystem

requirements architecture
C}u}vv
C}u}vvvo˙] requirements
...
F]PıXPI}v}(vo˙]vR]}vooo
F}u R ]v ( R ˙u vo˙] Pv R ˙u ]uv }

be developed. The system requirements are the input for a system architecture step
including two important sub steps for this context:
v TR˙u}(R˙u]v.X
v Requirements for the subsystems are derived from the system requirements.
The requirements for a subsystem show how the subsystem is involved in the
o]}v }( R ˙u ]uvX S} R R]PRroo ]uv v
}v]]uv}(].}vR(}R˙uX
WRv o]]vP R ˙uU R . R]vP } }U ] } vo˙ R ]uv
addressed to the subsystem in order to obtain resilient subsystem requirements.
Iv ˙u R] R˙ v Rv ]] } R
components.
TR }u ]o R ul v ˘}v ]v Pvo R] v }(
vo˙]vR]}vv}`v`vo
v a component has been found that is developed outside of the responsible
˙u}Pv]}vv]~XPXU˙o]Zvl}
v a component has been found that can be assigned completely to a domain
~uRv]U}L`XXXZX
TR] } v }uo }v]}v }( oo ]uv R ]+v
system levels.
Mv˙ }( R }RU uR} v Rv] ` v } (U v
at any system level. However, there are some other techniques for the development
of complex, technical systems, which for example follow from laws and standards.
TR ] R FMEA ~F]o M} v +
E Avo˙] W]RZ } .v
`lv ]v R o]}vX R]uv ] (}u R (}v ]l v
will be incorporated into the development at the considered system level.
A FS ~Fv}vo S(˙U ISO Z v P] v` ]v } R vo˙] } }v
v˙ ˙u vo˙] `]R HRA ~H v R]l vo˙]
A Z v (v}vo v
technical safety concept.
E]oo˙ ]v (˙r]o U R ] u} R v vo˙] }X TR] +U
(} ˘uoU R ]o]˙ }( R ]uv } R ]vU R o]}v v
the tests and checks that must be performed for the requirements.
F} .v]vP ]uv vP]v]vP } (} ˙u o]l R]U R (}oo}`]vP
]oXI(}]oUoo}(RuR}o(o.ooV
v Procedural standards and norms that partly complement and contradict each
other
v Qo]˙ }( ]uv (} (R o}uv } ]Pvuv } R
needs of a supplier
v T]uv+}UP]v˙R}i
TR ]U }PR `]R R } RvP R ] u} ]v PR
U }v[ ul ] ˙ } .v R }] u (} v }u]vP ˙u
vP]v]vP }iX W[ u R ˘]v R R }]v }( ]` (}u v
external expert can help with the methods and gives assurance for the next steps.
56 for Smart Ecosystems
10. Requirements Engineering for Smart

Ecosystems and as a Driver of Digital
Transformation
P}(XXD K˙ P}'R] (}u R CR] }( B]v Iv(}u v D]P]o]}v R
Uv]]˙}(P}u.v]P]ov(}u}v(}oo}`P
Definition digital transformation according to Pousttchi

[Pousttchi17]:
TR u ]P]o v(}u}v ] ]Pv].v RvP ]v ˙˙ o](UR
economy and society due to use of digital technologies and techniques as well as
R]+X
TR + ( R]vPX TR˙ + ou} oo }( } ]o˙ o]X B]v

u}o v o R]v RvP]vP oo˙X C}uuv]}v u] v R }
`˙}( }uuv]}v RvP]vPX Uouo˙UR] RvPR`}lv]}vuv
òo } o](˙oX TR v` ˙uU o} R vò˙ + lR}oU
R]Pv].v]u}vR`}l]vPv]}vuv}(]uvvP]vX
The example of the smart home system that is used in this brochure is a smart
}˙uX Mv˙ ]v]]o ˙u ~]} ]oovU RvPU o]v }v}oU
access control, etc.) communicate and interact with each other. The smart home
˙u ]o( }] R }uuv]}v o}u (} ] }v]v]vP ˙uX TR
ecosystems can be randomly scaled. The smart home system can also be seen as a
component of a higher-level ecosystem, a so-called “Smart Rural Area”. Systems like
that are usually not developed by one company, but are created due to the inter-
}v }( ]+v ˙u ]v R u }v˘ } }v]vPX TR ]+vvP
(} `v Sv}uo_ v u }˙u ] R ]v u ˙uU ]}vo
˙uv}}u}(}uR}˙uv˙uX
Impact of smart ecosystems on requirements engineering

A ]o RoovPU `R]R ` R } o `]R ]v o} }( } }iU ] «vP
the system and context boundaries for a system within a smart ecosystem. The
]8o R R u} }vo ]v}v v v R ]v(X
A R u }( o}uv v ]uouv}v R ]vvP ˙u vv} ˙
be determined unambiguously and completely.
TR] }ou ] v} vo˙ v`X TR RoovP o} ˘] ]v ]r}]v ˙uX
The keyword is: interface contracts or quality-of-service agreements or service-level
PuvX TR˙ v R R ]]vP ˙u R .v ~Z o]˙
and thus the right to use the service.
Av}R + ] R R ˙u `]R]v u }˙u }uouv R }R
v o }( }]]vP (v}v }u}v R R ]v]]o ˙u

vv} o] o˙X Ov }]o }R ] v} } o]u] }vo( } R
}`v i }( }}vU } o}}l R ]PP ]X TR] v }v ˙
vo˙]vP R }v oo R } R }v i u'X
When developing a control unit within a vehicle for example, it may be helpful to also
l o}}l R v R]o ]v } } .v vv] v ]v}v }( R
individual parts (see also paragraph 9 - "systems engineering"). We recommend that
the business process level is included in the analysis. In the process other possible
o}˙uv v]} } o]}v }]]o] (} R }v] ˙u v
]v.X
Possible approaches for the analysis of smart ecosystems

One possible approach to improved requirements engineering in a smart ecosystem
is to embed the work with requirements into an agile development. The reasons
R u }˙u R]PRo˙}uo˘ ˙u `]R uv˙ v]v
R u }( o}uvX Ao} oP vu }( RvP ]v ]uv v
}v]v v } `]R]v ˙ R} uX H}Ù ] ] }]o } o]RU
} o] v } }u] v P]o }R ]v P }v˘X TR] ] v ˘]vP
challenge for the requirements engineer that requires a lot of experience.
Av}R }R ] u}or ˙u vP]v]vPX M}or ˙u
engineering is suitable for smart ecosystems, because it divides the amount
}( ]v(}u}v v ˙ }u}]vP R `R}o ˙u v o}}l]vP R
]+v ]` }( R }v] ˙uX ˙B }]vP R R `R}o ˙u }u
understandable and developable.
S}o] lv}òP }( ]uv vP]v]vP v u}o]vP ] voU òo
experience in dealing with complex systems.
TR }( .]o ]voo]Pv ~AIZ `]oo ]vGv ]uv vP]v]vPU }}X
TR ].}v }( v AI ˙u ]+ o]PRo˙ (}u }vv}vo ˙uX TR
]Pv].v ]+v ] R i }( }}vX Iv o] ˙u R (}
o] }v R (v}vo]˙U R ˙u R]} v R Rv]o o]}vX Iv v AI
˙u R (} ] }v R ].}v }( R ]v]vP } v ] o]˙ }( R
X TR] }R u} R }uo˘]˙ } }( R ].}v ]v} R AI ˙uX
Ovo˙ R P}o v R ]] (} } ]. `]R} ]PP]vP }
]v}R(v}vo]˙X
Digital transformation in requirements engineering

F} R o]]}v of knowledge, a challenge
is that due to new technologies, knowledge is
]oo ]v uv˙ ]+v oX TR R
} }( ovP } (} ]uv
is increasingly gaining priority. We can highly
recommend two tools for the work with
lR}o `R} ]8o } ]u}]o }
access: personas and empathy maps. Besides,
new technologies increase the working
uR} }( ]uv vP]vX F}
o]]vP ]uv ` }uuv R
}( }`RE
C uR}U o]]vP oU ]Pv R]vl]vP
} }R }r}v }RX TR(}U
it’s pleasant to have at least some short term
help from experts with experience in these
techniques.
The business world is changing; mobile work is
]vP v }u]vP R v}uX TR o
}v ul ] ]8o } o]]}v
Rv] R ] R R˙]o v }( R ]vX S]o }}o (}
]o uvP v RoU òo ]vP o]]}v Rv] R v} +
˙ R] }ouX D } ]P]o]}vU uv˙ uvoo˙ ˘ } ]vP
}uX TR(} v}PR u v +} R}o ]v ]v} R ]v
} vo˙] } o } o˙ ]P]o] v}uv uvo }X
TR ]P]o v(}u}v + R u]v ]˙ vPP}}]uv in a
`˙ R ]v ˙u v } ]v vP P}} ]uvX F} ˘uoU
R ˘ }Pv]}v ˙u } o o]˙ .]v] } ]uP }Pv]}v
}L`R}v]PulR]v}˙voo˙}]PuX
TR ]v]vP ]P]o }uuv]}v + R ]uvP of requirements. In
o ] `]oo RvP R }oo}}v `v R ]uv vP]v v
R] lR}oX Iv R U }l]v lo}PU }u } Kvv }
RvP }v òo `]R l˙ v}X N}`˙U R ( ]P]o] v}
˙}v ]v}o ] }v ]X MvP R }v `}l]vP `]R R }i
}u u} ]8o } ˙ }X TR }( ]o } Puv o]˙ v RoX
I( R lR}o } v ] }oo}}v (} ]u}]vP
]uv ] v} }]oU U }}or `˙ }( `}l]vP `]oo R ˙X
Heavy weighted, extensive documents probably won’t stay this way much longer.
TR RvP +} `}o Ro˙ uvPo } Po v }vv}
delivery and rapid technological progress - unless the models are managed by means
}( }(]}vo ˙u vP]v]vP v P}} }}oX ˙B v}` ` }Lv } }
]} (} }uv}v v ]uvPX TR] v` ˘]vP REv}v
]v]uvvP]v]vP`]Ro}}(}voX
In the management of requirements, change management is gaining relevance. The

`R}o }]˙ ] }v(}v `]R u} Rv}o}P] v Ru o˙X S} R
requirements engineer should keep close contact to his stakeholders and expect a
whole lot of change requests.
60 Business Analysis
11. Business Analysis, Requirements

Engineering or Both?
Iv uv˙ }uv] R ] v} R }o } i} oo ]uv vP]vX
Instead there are requirements manager, business consultant, business analyst,
X Dv]vP }v R }uv˙ R ]+v `v R i} ]}v
u} } o ].X Iv o]U o `} u oo˙ ]vP]RP
requirements engineering and business analysis.
We have already explained the term requirements engineering in chapter 2. Business
vo˙] ] P]vP } R Ivv}vo Iv }( B]v Avo˙] ~IIBAZ .v
in the following way:
Definition business analysis according to the International

Institute of Business Analysis [IIBA]:
]vB vo˙] ] v ]˙ }( vo]vP RvP ]v v }Pv]}v ˙ .v]vP
]v v v }uuv]vP }o}v R P] o } lR}oX
OK
BA
This statement show an obvious similarity between business analysis and

]uv vP]v]vPP .v]vP ]v v XXX R P] o } R l -
holders". That sounds a lot like requirements, doesn't it? I.e.
in short: requirements engineering is embedded in business
analysis. But what exactly does it mean?
Business analysis is a very broad discipline that may include
uv˙ ]v]]o ]X Iv ]v]oU ]v vo˙
need to understand a company's strategies, goals, business
processes, etc. and combine them with market requirements
to develop products/improvements that meet the company's
business goals. It can be divided into the following four
]+vX
Planning and controlling work steps

Ov }( R u} (v ] ` (}u ]v ]v vo˙] ] ovv]vP v
}v}oo]vP oo ]v vo˙] ]X Iv } ˘]v }Lv ]uo PDCA
cycle is implemented. Planning (P) includes familiar things such as stakeholder ana-
o˙]U «vP ]uv uvPuv v ovv]vP R ]v]]o `}l X
AL R R `}l } }v ~DZ v R o ] }uvX N}` ]
v Rl ~CZ `RR R R }PR R ] o v `RR
] ` +X F]voo˙U ]( v˙U }v `]oo ~AZ v ] iuv } R
`}l]v}}}uv(}v˙}]o.]X
SOPHISTSo(r}}v
]+v
A l]v}(lv}òP]J
Freebie!
Posters
The SOPHIST UML-poster
The SOPHIST RE-poster...

Requirements-Engineering
Anforderungsarten Qualitätskriterien Rechtliche Verbindlichkeit Perspektiven auf Anforderungen Detaillierungsebenen

Deutsches Englisches Ebenen Zugeordnete Begrifflichkeiten
Funktionale Anforderungen Für jede einzelne Anforderung Für das Anforderungsdokument
Anforderungen an Verbindlichkeit Schlüsselwort Schlüsselwort
Strukturperspektive Funktionsperspektive Verhaltensperspektive aus herkömmlichen Vorgehen, wie z. B. aus agilen Vorgehen
RUP oder V-Modell Scrum Adaptive Software Development Lean Software Development Crystal
Vollständig Atomar
durchzuführende
Vollständig
Nicht-funktionale Anforderungen Tätigkeiten Pflicht muss shall Inhalt Inhalt Inhalt Spezifikations-
Grobe Systembeschreibung, Systemziele, Systemüberblick, Vision, Introduction, Mission Statement
Sprint Goal, Project Vision, Release Plan Mission
Z. B. Verhalten eines technischen level 0 Product Vision Project Data Sheet Statement
Klassifiziert eine rechtlich verbindliche, zwingend zu Z. B. (Daten–)Strukturen eines Z. B. Funktionalitäten eines techni-
Technologische Anforderungen an die Anforderungen an durch- Technisch lösungsneutral Konsistent erfüllende Anforderung. technischen Systems oder Subsys- schen Systems, die dem Nutzer zur Systems aufgrund Spezifikations- Anwendungsfall (Use-Case), User Story, (Anwendungs-) Szenario, Fachkonzept, Funktionsbeschreibung, Funktionsgliederung, Epic, Product User Story, Backlog Item, Actor Goal List, User Role
teme. Verfügung stehen. eingehender Ereignisse. level 1 fachliche Anforderung, Organisational Requirement, Featureliste, Kontextabgrenzung Theme Specification Outline Use-Case Model, Use-Case
Anforderungen Benutzungsoberfläche zuführende Tätigkeiten Rechtlich- Wunsch sollte should
Konsistent Prüfbar Erschwinglich Wird für Anforderungen verwendet, von deren Umsetzung Spezifikations-
Anwenderforderung, Nutzeranforderung, Operational Concept Description, Operational Requirements Description, Interface Requi- User Story, Technical User Story,
Product
User Story, Backlog Item,
Common Domain Model, Test
vertragliche unter bestimmten Umständen abgesehen werden kann. Dokumentation Dokumentation Dokumentation level 2
rements Specification, Lastenheft, Sollkonzept, Grobspezifikation, Operational Requirement, betriebliche Anforderung, Testfälle, Backlog Item, Acceptance Crite-
Specification Outline
Use-Case, Iteration Plan,
Qualifier, Test Case Case, Iteration Plan
Qualitäts- Anforderungen an sonstige Rechtlich-vertragliche Notwendig Verfolgbar Abgegrenzt Featureliste ria, Definition of Done
anforderungen Lieferbestandteile Anforderungen
Anforderungen Absicht wird will Z. B. mit UML-Klassendiagramm Z. B. mit UML-Aktivitätsdiagramm Z. B. mit UML-Zustandsdiagramm
Technical User Story, Backlog Technical User Story, Backlog
Ermöglicht es, zukünftige Rahmenbedingungen und oder mittels natürlichsprachlicher oder mittels natürlichsprachlicher oder mittels natürlichsprachlicher Spezifikations- Detaillierte Anwenderforderungen, Technische Anforderung, Schnittstellenübersicht, Schnittstellenbeschreibung, System Segment
Item, Acceptance Criteria, Item, Acceptance Criteria, Qualifier, Test Case
Architecture Description,
Realisierbar Eindeutig Anforderungen bereits anzukündigen. Anforderung. Anforderung. Anforderung. level 3 Specification, Interface Requirements Specification, Systemanforderung, Feinspezifikation, Testfälle, Featureliste Definition of Done Definition of Done Test Case
Spezifikations- Komponentenanforderungen, Technische Anforderung, Schnittstellenübersicht, Schnittstellenbeschreibung, Software Requirement Technical User Story, Backlog Technical User Story, Backlog Architecture Description,
Test Case
Anforderungen lassen sich nach ihrer Art einteilen. Die Art beschreibt eine Unterscheidung von level 4 Specification, Interface Design Description, Pflichtenheft, Feinspezifikation, Modulanforderung, Testfälle Item, Acceptance Criteria Item, Acceptance Criteria Test Case
Anforderungen nach einer inhaltlichen Kategorie/Gruppe. Der oft verwendete Begriff Qualitätskriterien helfen zu verstehen, welche Kriterien für die einzelne Anforderung bzw. für das ge- Die rechtliche Verbindlichkeit beschreibt den Grad der Bedeutung, den der Stakeholder den Angaben in Anforderungen an einen Betrachtungsgegenstand können aus drei verschiedenen Perspektiven betrach-
nicht-funktionale Anforderung spiegelt sich in obiger Aufstellung auch wider: Jede Anforderung, samte Anforderungsdokument besonders wichtig und zu beachten sind. Anhand dieser Kriterien kann der Anforderungsspezifikation beimisst. Üblicherweise wird die rechtliche Verbindlichkeit durch Verwen- tet werden. Unterschiedliche Dokumentationstechniken bieten die Möglichkeit die Anforderungen einer Anforderungen können in einer Verfeinerungshierarchie zueinander stehen und so einer von fünf verschiedenen Detaillierungsebenen/Spezifikationslevel zugeordnet werden. Die Anforderungen auf jeder Ebene
die keine funktionale Anforderung ist, ist nicht-funktional. beurteilt werden, wie qualitativ hochwertig eine Anforderung/ein Anforderungsdokument ist. dung bestimmter Modalverben (Schlüsselwörter) ausgedrückt. bestimmten Perspektive zu explizieren. beschreiben dabei den Betrachtungsgegenstand vollständig, je nach Ebene sehr abstrakt oder verfeinert.
Ermitteln Dokumentieren
System- und Kontextgrenze Kano-Modell Stakeholder-Tabelle Entscheidungstabelle UML-Use-Case-Diagramm Use-Case-Beschreibung
Zufriedenheit: Leihobjekt.Musterexemplar == ja j j n n Use-Case Eindeutige Benennung des Use–Cases. Der Name muss
sehr zufrieden Funktion Name Kontakt Verfügbarkeit Bibliothekssystem
Mit der Zeit werden Begeisterungsfaktoren Name des Use–Case mit dem Namen des Use-Cases im Use–Case–Diagramm
Systemgrenze Begeisterungsfaktoren Leihobjekt.Status == reserviert j n j n Systemname
übereinstimmen.
zu Leistungsfaktoren Von 9-19 Uhr telefonisch Leihobjekt
Bibliothekar Tel.
und schließlich zu Herr Bauer erreichbar, Mitarbeit zu entleihbar - - - x verleihen Beschreibung Kurze Beschreibung des Use–Cases.
Basisfaktoren Leiter der Bibliothek 409000 Leihobjekt
30% möglich, Nürnberg
nicht entleihbar x x x - Assoziation reservieren
Leistungsfaktoren Administrator Per Mail, immer er-
Akteure Aufzählung aller am Use–Case beteiligten Rollen.
(Wartungs- und Herr Heiner Heiner@gmx.net reichbar, Verfügbarkeit
Kontextgrenze Leihobjekt zu- Auslöser Ereignis, welches dazu führt, dass ein Use–Case abläuft.
Schulungspersonal) 50%, Nürnberg Zusammenfassung von Bedingungskombinationen zu einem fachlichen Zustand z. B.
Das System rücknehmen Aufzählung aller Inputs, sowie aller logischen und zeitli-
Per Mail und tel. tagsüber, Falls [Leihobjekt entleihbar], ....
Systemkontext Erfüllungsgrad Product-Owner Paul Ottmer po@ottmer.de vgl. auch DMN (decision model and notation) - bei der OMG (Object Management Group) ist der Leihobjekt Vorbedingungen chen Bedingungen, die zu Beginn des Use–Cases erfüllt
vollständig Verfügbarkeit 100%, Nürnberg
Standard unter http://www.omg.org verfügbar. verlängern sein müssen.
Erfüllungsgrad: Basisfaktoren Wissen Interesse & Ziele Relevanz Aufzählung der Schritte des Use–Cases, um das Ergeb-
Kunde Normalablauf
völlig unzureichend
Kennt das Altsystem aus UML-Aktivitätsdiagramm Bibliothekar nis von fachlichem Wert zu erzeugen.
Vereinfachung
der Anwendersicht, soll Fachlicher Entscheider Abweichende Schritte des Use–Cases, um das Ergebnis
der Ausleihprozesse Entleihberechti- Kunde Alternativer Ablauf
Irrelevante Umgebung mit dem System arbeiten gung des Kunden Akteur von fachlichem Wert zu erzeugen.
prüfen Bedingung verwalten
Vertraut mit vergleichbarer Stabiles System, geringer Informationslieferant bzgl. Abweichende Schritte des Use–Cases, bei denen das
Ablauf mit Fehlern
Zeit* Verwaltungssoftware Wartungsaufwand Wartungsanforderungen [entleihberechtigt]
<<actor>> Ergebnis von fachlichem Wert nicht erzeugt wird.
Leihobjekt Entleihbarkeit
Die Abgrenzung des Systems – also des Betrachtungsgegenstandes – zu seiner Umgebung (der Koordinator für die ROI des Systems Entscheider - als Koordinator Startknoten des Leihobjekts Systemgrenze Bestand Kundendatenbank Beschreibt, welches Ergebnis von fachlichem Wert
identifizieren
prüfen Ergebnis
Kontext) wird genutzt, um klar zu definieren, an welchen Betrachtungsgegenstand Anforderungen Inputs der Stakeholder sicherstellen der Stakeholderanforderungen verwalten erzeugt wird.
Zufriedenheit:
gestellt werden müssen und dürfen und an welche Gegenstände in der Umgebung nicht. Durch die völlig unzufrieden
dadurch entstehende Systemgrenze werden hier bereits Schnittstellen zwischen dem System und Aktion Vorlage für Use-Cases. Wird meist auf die individuellen Bedürfnisse des Projekts, des Unterneh-
Ist eine Sammlung aller Beteiligten am Vorhaben/Projekt mit deren wichtigsten Kontaktdaten, Entscheidungsknoten Zusammen-
den externen Partnern sichtbar. Begeisterungsfaktoren = unbewusstes Wissen etc. Sie fungiert als (Projekt-)Adressbuch und ist für alle Beteiligten öffentlich zugänglich. Man High-Level-Darstellung der Funktionalität des Betrachtungsgegenstands (z. B. System). mens oder des Vorgehens angepasst. Z. B. Qualitätsaspekte (Qualitätsanforderungen), Ergebnis,
>> Müssen als neue Ideen/Innovationen erst neu erarbeitet/erfunden werden. führung Parallelisierungs- [nicht entleihbar]
Alternativen, Ausnahmen, Fehler, ...
findet darin jede/jeden, die/den man irgendwann im Projekt benötigt. Deshalb muss sie auch [entleihbar] Wird auch als Kontextdiagramm verwendet.
knoten
SOPHIST-Stakeholderlandkarte Leistungsfaktoren = bewusstes Wissen stetig aktuell gehalten werden. Die SOPHIST-Stakeholderlandkarte gibt Aufschluss über mög- [nicht
entleihberechtigt]
>> Werden explizit gefordert und genannt. liche Rollen.
Basisfaktoren = unterbewusstes Wissen
UML-Klassendiagramm User-Story-Schablone
Ausleihe
>> Werden als selbstverständlich erachtet und oft nicht (mehr) explizit gefordert. bestätigen Leserichtung Assoziationsname Als <Benutzerrolle>
Transformationsprozesse/-effekte Kante Empfehlungen
anzeigen Kunde Reservierung Leihobjekt
SOPHIST- Die eingeschränkte persönliche Wahrnehmung Der sprachliche Ausdruck des persönlichen
Ausleihposition
möchte ich <Funktionalität/Systemverhalten>,
führt zur Wahrnehmungstransformation. Wissens führt zur Darstellungstransformation. Name Reservierungsdatum Bezeichnung
speichern Vorname erstellt Status liegt vor für Freigabealter
Synchronisations- Familienstand 1 0..* 0..* 1 Genre so dass <fachlicher Wert für den Benutzer/Kunden bzw. wirtschaftlicher Nutzen>.
Persönliche Wahrnehmung Persönliches Wissen knoten Geburtsdatum ISBN
Geschlecht
Als Nutzer der Bibliothek
Kurzübersicht Multiplizität Assoziation
möchte ich den Bestand nach Büchern eines bestimmten Autors
Endknoten [Ausleihvorgang
fortsetzen] Attribut
Regel zur Anforderungsformulierung Defekthafte Signalwörter
durchsuchen können,
[Ausleihvorgang Generalisierung
beenden] so dass ich alle Bücher meines Lieblingsautors finde.
Zeitschrift Buch DVD
1 Formulieren Sie jede Anforderung im Aktiv und weiteres Vorge-
werden; wurden; sind; ... hen wählen Klasse
identifizieren Sie den Akteur der Anforderung Eine User-Story beschreibt eine Funktionalität, die für den Kunden oder Benutzer eines Produkts
Wahrnehmung Wissensdarstellung
Ausgabe Autor Erscheinungsjahr oder Systems von Wert ist. Sie besteht aus der schriftlichen Beschreibung der Funktionalität,
Das Aktivitätsdiagramm visualisiert die Ablaufreihenfolge von Schritten (Funktionen) vollständig, Gesprächen über die Funktionalität und Akzeptanzkriterien, die Details vermitteln und festlegen,
2 Drücken Sie Prozesse durch eindeutige/definierte
Vollverben aus.
angeben; bereitstellen;
verhindern; ... Defekte? Defekte?
d.h. inklusive Alternativen, Fehler, Ausnahmen, ...
Das Einsatzspektrum reicht von Geschäftsprozessen, über die Verfeinerung von Use Cases oder
wann eine User-Story vollständig umgesetzt ist.
Aktionen in anderen Aktivitätsdiagrammen, bis zur Darstellung von Abläufen in Source Code. Grafische Definition von Begriffen, deren Eigenschaften und Beziehungen zu anderen Begriffen.
Auch wenn Klassendiagramme in der Implementierung eine große Rolle spielen - hier nur als BPMN-Prozessdiagramm
Prozesse prüfen
Lösen Sie Nominalisierungen auf, die nicht exakt Realität Sprachlicher Ausdruck
3
Begriffsmodell/Informationsmodell auf fachlicher/logischer Ebene.
definiert sind, und schreiben Sie pro Nominalisie-
rung eine oder mehrere neue Anforderungen mit
Rückgabe; Eingabe; Spei-
cherung; Archivierung; ... des Wissens SysML-Diagramme Business Process
gutem Vollverb. „Leihobjekt verleihen“ Aufgeklappter Pool
 Blockdefinitionsdiagramm SOPHIST-Anforderungsschablone - der FunktionsMASTER
Die Transformationseffekte lassen sich in drei Kategorien einteilen - egal ob sie bei der Wahr-
nehmung oder bei der Wissensdarstellung auftreten:
 Anforderungsdiagramm <<Pool>> Kunde <<Pool>> Bibliothekar
4
Lösen Sie Funktionsverbgefüge auf und bestimmen zur Verfügung stellen; zu
Sie den konkret geforderten Prozess, der das Sys- Ende bringen; eine Verän-  und weitere Schritt 5: Schritt 1:
Tilgung ist ein Indikator für unvollständige Sätze. Wichtigkeit festlegen Leihobjekt übergeben
temverhalten mit einem „guten“ Vollverb darstellt. derung erfahren; ...
Generalisierung ist ein Indikator für fehlerhafte Verallgemeinerungen. Sprache für die Modellierung von Systemen, nicht nur Software. Die SysML (Systems Modeling Logische und zeitliche
Zugeklappter Pool
Verzerrung ist ein Indikator für realitätsverfälschende Aussagen. Language) als Erweiterung zur UML 2 ergänzt diese um weitere Diagramme bzw. passt einige Bedingungen
Das SOPHIST-REgelwerk geht auf die konkreten Effekte dieser drei Kategorien mit seinen Regeln formulieren Schritt 4:
5 Identifizieren Sie die Vollverben und schreiben Sie
anzeigen und anschließend vorhandene Diagramme an die speziellen Bedürfnisse der Systemmodellierung an.
ausdrucken; ...angeben näher ein. Mit diesen werden die konkreten Effekte untersucht.
für jedes Vollverb genau einen Anforderungssatz.
und speichern; ...
Der Standard ist bei der OMG (Object Management Group) verfügbar unter www.omg.org Objekt identifizieren
Kunde
MUSS - Kundenkarte identifizieren
Analysieren Sie fehlende Informationen zum Voll-
6
<wer>, <was>, <wann> Kunde nicht
verb und ergänzen Sie diese falls notwendig.
anzeigen; <wer>, <was>, <Akteur> identifiziert
Stellen Sie W-Fragen:
<wohin> übermitteln; ... <Bedingung> SOLLTE <System> DIE MÖGLICHKEIT <Objekt> <Prozesswort> Kunde
Was? Wem? Wie? Wann? Wie oft?
BIETEN verwalten
Kunde identifiziert
7
Analysieren Sie fehlende Informationen zum
Eigenschaften prüfen
erzeugte; versandte; WIRD FÄHIG SEIN

Eigenschaftswort, welches sich aus einem Vollverb
abgezeichnete; ... Schritt 2: Kunde
ableitet, und ergänzen Sie sie notwendigenfalls.
Funktionalität identifizieren Daten
Schritt 3:
8
Formulieren Sie Eigenschaftswörter mess- und schnell; effektiv; perfor- Art der Funktionalität festlegen
testbar. Achten Sie dabei auf Adjektive, Adverbien mant; besser; intuitiv; Entleihberechti-
gung prüfen Gateways
und insbesondere Vergleiche und Steigerungen. leichter; ...
Wird genutzt, um beteiligte Rollen zu ermitteln und soll als Gedankenanstoß dienen. Da es sich Schritt 6: SOPHIST-REgelwerk anwenden
Leihobjekt
um eine Sammlung aus vielen Jahren der Stakeholderanalyse handelt, sollten viele Rollen bereits Formulieren Sie eigene Anforderungen für <Ausdruck> bedeutet einen Platzhalter: Für Ausdruck müssen Sie etwas einsetzen.
nicht entleihberechtigt
9
Qualitätsaspekte,
auf dieser Landkarte verzeichnet sein. Da es jedoch schwer ist, die ganze Welt zu überblicken, sind nicht-funktionale Aspekte, wenn diese eigenstän-
wie z. B. Zeitverhalten,
dig behandelt werden sollen oder als übergreifend
Erweiterungen erlaubt und jederzeit willkommen. gelten.
Verfügbarkeit, ... Schablone für eine Anforderung / einen Anforderungssatz.
Hier der FunktionsMASTER mit Bedingung für eine funktionale Anforderung. entleihberechtigt
SOPHIST-Ermittlungstechnikenmatrix Hinterfragen Sie verwendete Zahl- und Mengen-

Weitere Schablonen finden Sie in der Broschüre „MASTER - Schablonen für alle Fälle“. Ausleihe Ablehnungsgrund
dokumentieren mitteilen
10 wörter und prüfen Sie, ob mit Ihnen die zu alle; jeder/jeden; immer;
Legende:
* bezeichnende Menge der Objekte auch genau kein; 7; ...
Planguage
Nachrichtenfluss
Mengen prüfen
erfasst wurde. Ausleihe

Wechsel der Perspektive
- nicht empfohlen Klären Sie fehlende Zahl- und Mengenwörter.
11 Konzept/Parameter Erklärung
soll <welchen> Benutzern Ausleihvorgang beendet
Systemarchäologie
Prüfen Sie, ob Zahl- oder Mengenwörter hinzu-

Feldbeobachtung
ermöglichen; <welche>
Methode 6-3-5
gefügt werden können. Ist dies der Fall, bestim-

Brainstorming
0 kein Einfluss=> ist anwendbar

Apprenticing
Daten genau; ...

Fragebogen
men Sie die genau gültige Menge an Objekten. Name Name der Anforderung End-Nachrichtenereignis Ausleihe abgelehnt
Interview
Reuse
hilft Ihnen weiter

+ empfohlen Unspezifisches Endereignis
Hinterfragen Sie schwammig formulierte Gist Grobe, informelle Umschreibung der Anforderung
++ sehr empfohlen
12 Substantive und stellen Sie fest, welche Objekte
oder Akteure genau gemeint sind.
der Anwender; die
Meldung; die Funktion; ... Scale Definition der Metrik der Anforderung Diagramm zur Darstellung von Abläufen mit deren Verantwortlichen. Meist für Geschäfts-
prozesse verwendet. Weitere Diagrammarten neben dem Prozess-/Kollaborationsdiagramm:
Operationalisierung der Metrik durch ein handhabbares Konversationsdiagramm und Choreographiediagramm.
Meter
Klären Sie Mögliches und Unmögliches und ersetzen Messverfahren
Fachwissen hautnah und zertifiziert Fachwissen mittendrin Der Standard ist bei der OMG (Object Management Group) verfügbar unter www.omg.org
Redundante Infos prüfen
13
Sie deren beschreibende Formulierungen. Hinter-
Menschliche Einflussfaktoren fragen Sie, was das geforderte Verhalten oder die
muss möglich sein; darf Vergangener oder aktueller Ausgangszustand für die An-
nicht möglich sein; ... Past
Geringe Motivation der Stakeholder (aktiv mitzuwirken) - - - + - 0 + ++ ++ Eigenschaft möglich oder unmöglich macht, und forderung
bestimmen Sie die identifizierte Logik. UML-Zustandsdiagramm
Schlechte kommunikative Fähigkeiten - - - ++ ++ - + ++ ++ Minimalziel für die Anforderung im Sinn von „soeben hin- Zustand
Must
Extrahieren Sie Nebensätze, die für die reichend“
14
Geringes Abstraktionsvermögen - - - ++ ++ 0 + ++ ++ weil; damit; um; so dass; repariert [nicht reserviert] entsorgt
Anforderung nicht notwendige Informationen
... Optimalziel für die Anforderung, im Sinne von „erfolgreich
Viele verschiedene Meinungen + ++ + ++ ++ + 0 0 0 enthalten. Plan Beschädigt
und zufriedenstellend“ Startzustand
Beschädigung festgestellt
repariert
Machtgefälle zwischen beteiligten Personen - + - 0 0 0 0 0 0 Kürzen oder entfernen Sie floskelhafte Wörter Trigger
für den Fall; gelb in der Beispiel: zurückgegeben [reserviert]
15
oder Redewendungen, die für Ihre Anforderungen [mit Beschädigung]
Problematische Gruppendynamik - + + 0 0 0 0 0 0 irrelevant sind und präzisieren sie. Vereinfachen Farbe; klein in der Größe;
zurückgegeben [nicht reserviert
Organisatorische Einflussfaktoren Sie komplizierte Redewendungen und unnötig ... Name Reaktion auf Tastendruck UND ohne Beschädigung]
verschachtelte Sätze.
Ausgeliehen Guard
Entwicklung für den komplexen Markt ++ + + - - ++ 0 + 0 Gist Das System muss schnell auf Tastendruck reagieren Ausleihbar Ausleihe erfolgt
Fixiertes, knappes Projektbudget ++ ++ + + - - + - ++ Klären Sie Ausnahmen vom Normalverhalten des Durchschnittliche Zeit bis zur sichtbaren Reaktion auf den
16 Systems und erweitern Sie die Anforderung bzw.
sollen; sollte; müssen; es Scale zurückgegeben [reserviert
Gesamtbild prüfen
Hohe örtliche Verteilung der Stakeholder - 0 - 0 0 ++ 0 0 0 ist notwendig; ... Tastendruck entsorgt UND ohne Beschädigung] abgeholt
formulieren Sie ggf. eine neue.
Schlechte zeitliche Verfügbarkeit der Stakeholder + + - + - + ++ ++ ++
Use–Case „Leihobjekt ausleihen“ wird 25 mal durchgeführt. reserviert
Anforderungen mit unvollständigen Bedingungs- Es werden alle Reaktionszeiten des Systems mit Stoppuhr
Meter
... and its „cores“

Hohe Anzahl der Stakeholder + - + 0 - ++ 0 0 0 [Reservierung storniert ODER Zurückgelegt
Die SOPHISTen sind für ihre Trainings bekannt - egal ob es sich um ein Offenes Training oder um ein Inhouse Die SOPHISTen sind bei vielen Kunden als Berater oder Coaches im Einsatz - und das branchenübergrei- gemessen. Aus den Messergebnissen wird der Durchschnitt Transition
17
strukturen sollten überprüft und ausformuliert wenn .. dann; falls .. dann; Reservierungszeitraum abgelaufen]
oder durch eine weitere Anforderung beschrieben
Fachliche/Inhaltliche Einflussfaktoren werden. Bestimmen Sie das Systemverhalten für für den Fall dass; sollte; ... Training handelt, die Vermittlung von Fachwissen und Erfahrungen aus der Praxis stehen im Mittelpunkt. fend. Als Methodenführer im Bereich des Requirements-Engineerings sehen wir unsere Aufgabe dar- gebildet.
jede noch nicht beschriebene Bedingung. Profitieren Sie von den Erfahrungen des erfolgreichsten Anbieters von CPRE-Zertifizierungstrainings. in, außerordentliche und perfekt passende Lösungen für und mit unseren Kunden zu erschaffen. Wir
Hohe Kritikalität des Sachverhalts 0 0 + ++ - + + ++ + Past 1,3 s
Die überdurchschnittliche Bestehensquote unserer Trainingsteilnehmer bei Prüfungen spricht für sich. begleiten unsere Auftraggeber methodisch und operativ von der Phase der Anforderungsanalyse, über Endzustand
Großer Systemumfang 0 0 0 + - - + ++ + Für jede nicht beschriebene implizite Annahme Bei unseren Inhouse Trainings können Sie Ihren Trainingsinhalt maßgeschneidert anpassen und Ihr Trai- die Modellierungs-, Architektur- und Designphase, bis hin zu Test und Abnahme. Must 1,0 s
Keine Erfahrung im Fachgebiet 0 0 0 - + - + ++ + 18 müssen eine oder mehrere zusätzliche
Anforderungen geschrieben werden.
falls; nachdem; angezeig-
te View; Kundendaten; ... ning aus mehr als 100 Bausteinen zusammensetzen. Unsere Kundenreferenzen sprechen für sich.
Plan 0,2 s Zeigt das Verhalten eines Systems oder den Lebenszyklus / Workflow eines Objekts.
Grobe Anforderungen gesucht ++ ++ + + 0 + ++ - 0
Detaillierte Anforderungen gesucht + + + + ++ - + ++ +
Fachwissen LIVE Fachwissen in Buchform Freitext
Von Tom Gilb entwickelte Möglichkeit, Qualitätsanforderungen zu quantifizieren. Beliebt in der
Priorität: = hoch = mittel = niedrig Anwendung, da die Schablone leicht anzuwenden und das Ergebnis leicht zu verstehen ist.
chris RUPP & die SOPHISTen
Nicht funktionale Anforderungen gesucht 0 0 0 0 + - + + + Chris Rupp & die SOPHISTen
Requirements–Engineering
und –Management
Beispiele, Hinweise, Begründungen, Anmerkung, Annahmen, ...
6. Auflage
Hohe Komplexität des Sachverhalts 0 0 0 + - - + + + Viele Dinge rund um die Anforderungen sind für das Verständnis hilfreich und wichtig.
REQUIREMENTS- Wireframe
ENGINEERING und
Sie wird eingesetzt, um anhand bewerteter Einflussfaktoren und Randbedingungen die am besten ge- Vor allem bei der Ermittlung von Anforderungen genutzt, ist das SOPHIST-REgelwerk jedoch fast -MANAGEMENT
Bleiben Sie auf dem Laufenden!
Unser Computerbuch-Newsletter informiert
UML-Komponentendiagramm
eigneten Ermittlungstechniken der jeweiligen Situation zu identifizieren. ein Alleskönner. Es kann auch als Prüftechnik für bereits bestehende Anforderungen eingesetzt Leihobjekte identifizieren
Sie monatlich über neue Bücher und Termine.
Aus der Praxis

Profitieren Sie auch von Gewinnspielen und
exklusiven Leseproben. Gleich anmelden unter
von klassisch bis agil

www.hanser-fachbuch.de/newsletter
Hanser Update ist der IT-Blog des Hanser Verlags
Tipp: Zwei bis drei verschiedene Ermittlungstechniken aus unterschiedlichen Bereichen verwenden, um werden. Oder es hilft bei der Dokumentation von Anforderungen.
mit Beiträgen und Praxistipps von unseren Autoren
Bitte Leihobjekte einlesen

rund um die Themen Online Marketing, Webent-
wicklung, Programmierung, Softwareentwicklung
EXTRA: Wissenstest auf der ILIAS®-Lern-
sowie IT- und Projektmanagement. Lesen Sie mit
plattform unter www.sophist.de/re/checkliste
Komponente
und abonnieren Sie unsere News unter
das beste Ergebnis zu erzielen. Ebenso darauf achten, dass unbewusstes, bewusstes und unterbewusstes
Mehr Spaß und Effektivität
Eigentlich immer einsetzbar, sobald es um Texte oder Sprache geht – egal ob geschrieben oder
durch ge-
www.hanser-fachbuch.de/update
hirngerechte Aufbereitung des Wissens
Intranet
Komplett in Farbe, mit Illustra-
Internet
tionen und frischem Layout
Wissen abgedeckt sind. gesprochen. Ein tolles Mittel also für die natürlichsprachliche Anforderungsanalyse. Nachname: [Nachname]
Vorname: [Vorname] Foto Beziehung
Geburtsdatum: [Geburtsdatum] Kunde
Kontostand: € [Kontostand]
Bibliotheks– Kundendaten–
App
system bank
Liste der identifizierten Leihobjekte
Die SOPHISTen haben ihre eigene Fachkonferenz - die SOPHIST DAYS. Die SOPHISTen sind als Buchautoren aktiv und haben ihr gesammeltes Fachwissen in mehreren Fach-
Diese 2-tägige Veranstaltung findet jährlich statt und überzeugt vor allem durch den guten Mix büchern publiziert, die durch ihren Bestseller-Status bereits in diversen Auflagen erschienen sind. Das ID Bezeichnung Entleihbarkeit Zeigt Systeme und deren Abhängigkeiten bzw. zerlegt ein System in kleinere Teile.
aus Fachvorträgen von Top-Speakern, Koryphäen und RE-Experten, Erfahrungsberichten aus der RE-Pra- Grundlagenwerk „REQUIREMENTS-ENGINEERING UND -MANAGEMENT“, welches von manchen Lesern Item 1 Item 1 Item 1
xis, neuen Einblicken, Möglichkeiten zum Erfahrungsaustausch und vielem mehr. als die RE-Bibel bezeichnet wird, ist bereits in der 6. Auflage auf dem Buchmarkt erhältlich. Es ist sowohl
www.sophistdays.de in digitaler Form als auch als klassisch gebundenes Buch verfügbar. Item 2 Item 2 Item 2 Und-Oder-Bäume
Item 3 Item 3 Item 3 Hierarchische Zerlegung eines Betrachtungsgegenstands, z. B. als Feature Tree oder als Zielbaum.
MASTER - Die SOPHIST-Templates für Requirements

Fach-“WISSEN-for-free“ Fachwissen - innovativ vermittelt Item 4 Item 4 Item 4
Item 5 Item 5 Item 5 UML-Sequenzdiagramm
Item 6 Item 6 Item 6 Exemplarische Darstellung (Szenario) der Interaktion mehrere Beteiligter.
Sichtenbildung Anforderungskonfigurationen und -basislinien
Leihobjekt manuell identifizieren Ausleihe abschliessen abbrechen Datenflussdiagramm
Selektive Sichten Verdichtende Sichten Die rechtliche Verbindlichkeit Die Art der Funktionalität
Ist-Stand der
für Release 1
Req-07 Req-24 Req-57

Änderungen
30% Zerlegt ein System aus Prozesssicht Top Down. Je Prozess (-teil) wird dargestellt, welche Daten
Kann einen großen Teil der Anforderungen an die Oberfläche ersetzen. Falls mit Anforderungen der Prozess benötigt bzw. erzeugt. Auf oberster Ebene als Kontextdiagramm verwendbar.
Objekt-ID Zustand Anforderungssatz Version 25%
gleichgesetzt (z. B. Vertragsgegenstand), muss definiert werden, welcher Teil der Darstellung
Das
20% V1 V1 V1 verbindlich ist (z. B. RGB-Werte der Farbe der Buttons). Akzeptanzkriterien-Schablone Der Ausdruck MUSS wird verwendet, um verpflichtende Anforderun- Selbsttätige Systemaktivität:
gen zu definieren. Ein System startet eine Funktion automatisch und führt sie anschließend automatisch aus.
PFLICHT
LH-Bib 152 Angelegt Bibliothekssystem 1 15%

...
Schablone zur natürlichsprachlichen Beschreibung von Testfällen bestehend aus: • Die definierte Anforderung ist verpflichtend. Diese Anforderungen formulieren Sie mit der entsprechenden rechtlichen Verbindlichkeit (Modal-
10% Req-07 Req-24 Req-57 Tabellen
Soll-Stand der
Req-38
für Release 1
Ausgangssituation, Ereignis und erwartetes Ergebnis.

Änderungen
Das
LH-Bib 186 Angelegt Bibliothekssystem 2
5% Ticket T1
• Die Erfüllung der Anforderung im Produkt ist verpflichtend. verben MUSS, SOLLTE oder Hilfsverb WIRD) und einem Prozesswort im Infinitiv. Das Prozesswort bildet
... Stakeholdertabellen, Systemlisten, Dokumentlisten, ...
erstellt • Die Abnahme des Produkts kann verweigert werden, falls einer die Funktion des Systems ab, die es selbsttätig durchführt. Ein Benutzer tritt dabei nicht in Erschei-
Das 0% Oft bei der Verwaltung schwierig. Einerseits werden Tabellen von Requirements-Management-Tools Entity-Relationship-Diagramm
LH-Bib 241 Angelegt Bibliothekssystem 3 V1 V1 V1 V1
nicht immer optimal unterstützt, andererseits leidet oft die Identifizierbarkeit (eine ID pro Anfor- MUSS-Anforderung nicht entsprochen wurde. nung.
...
Die SOPHISTen stellen kostenfrei Wissen zur Verfügung. Unter dem Motto „WISSEN-for-free“ veröffent- Die SOPHISTen haben für ausgewählte Trainings ein innovatives Trainingsformat entwickelt, dessen neue derung) bei einer Tabelle, da diese oft mehrere Anforderungen enthält. Alternative zum UML-Klassendiagramm. Wie dieses wird das Entity-Relationship-Diagramm zur
üft
men
legt
orfen
zt
stet
Ticket T1 Ticket T1
ysier
eset
gepr
Das lichen wir hilfreiche Broschüren und Plakate (teilweise auch in englisch) als kompakte Wissensquellen Art der Wissensvermittlung mehr Praxisbezug und größeren Lernerfolg verspricht. Die Kombination aus visuellen Definition der Begriffe eingesetzt.
Ange
Gete
nom
Entw
Anal
Umg
LH-Bib 639 Angelegt Bibliothekssystem 4 geändert gelöscht

ität
und übersichtliche Hilfsmittel im RE-Alltag. Bestellen oder downloaden Sie unser „WISSEN-for-free“ online-basiertem Selbststudium und Präsenzveranstaltung bietet die Möglichkeit, das Tempo für das Der Ausdruck SOLLTE wird benutzt, um wünschenswerte Anforderun-
Abge
...
X Prototypen Benutzerinteraktion:
Qual
V2
Anforderung nur ganz einfach auf unserer SOPHIST-Website. Erlernen der theoretischen Grundlagen selbst zu wählen und den Lernfortschritt selbst zu testen. Ereignisgesteuerte Prozesskette gen zu definieren. Wünsche:
mitTicket löschen Das System stellt einem Benutzer eine Funktionalität zur Verfügung oder es tritt mit ihm in Interak-
Ob Skizzen, Wirefames, Muster aus 3D-Drucker, ... Prototypen aller Art machen Anforderungen • sind nicht verpflichtend.
Im Arbeitsalltag zwingend erforderlich und oft genutzt sind Sichten auf die komplette Anforde- Basislinie Konfiguration Basislinie Konfiguration plastischer und ergänzen diese. Diagramm zur Ablaufdarstellung von Geschäftsprozessen. tion (das kann z. B. in Form einer Auswahlmaske geschehen). Für diese Interaktion zwischen System
• müssen nicht erfüllt werden.
rungsbasis. Unterschieden werden selektive Sichten und verdichtende Sichten:
Selektive Sicht: beinhaltet einen Teil der verfügbaren Anforderungsinformationen (z. B. alle
Anforderungen im Zustand x mit einer bestimmten Person als aktueller Bearbeiter).
Alle Anforderungen
für Release1
Alle Anforderungen,
nach der Bearbeitung
von Ticket T1
Alle Anforderungen
für Release 2
Stichprobenmenge für
Qualitätsmessung Q021
Informationen zu diesem Plakat • dienen der besseren Zusammenarbeit von Stakeholdern
und Entwicklern.
und Benutzer wählen Sie die Formulierung <Akteur> DIE MÖGLICHKEIT BIETEN und ein Prozesswort
im Infinitiv mit ZU. Hinter der Rolle / dem Akteur verbirgt sich ein mit dem System interagierender
Benutzer.
Verdichtende Sicht: enthält generierte oder verdichtete Daten, die nicht unmittelbar in der Req-07 V1 Req-24 V2 Req-07 V1 Req-24 V2 Dieses Plakat soll Ihnen bei den Herausforderungen des Requirements-Engineerings behilflich sein. • erhöhen die Zufriedenheit der Stakeholder.
Anforderungsbasis enthalten sind (z. B. eine Fortschrittsauswertung). Es ist in sechs Bereiche aufgeteilt.
Req-24 V1 Req-38 V1 Req-24 V2 Req-38 V1
Ganz oben finden Sie allgemeine Informationen zum Requirements-Engineering (hellblau), die sich nicht
in eine der vier Hauptaktivitäten des Requirements-Engineerings einsortieren lassen. Der Ausdruck WIRD wird benutzt, um Anforderungen zu definieren, Schnittstellenanforderung:
Strukturieren Req-57 V1 Req-57 V1
Spezifikation und Dokumentation in agilen Projekten

Darunter finden Sie die vier Hauptaktivitäten des Requirements-Engineerings Ermitteln (rot), Dokumen-
tieren (lila), Prüfen und Abstimmen (grün) und Verwalten (braun) mit wichtigen Techniken der jeweiligen
die in der Zukunft integriert werden. Mit Anforderungen an Schnittstellen wird der Fall abgedeckt, dass ein System eine Funktion nur in
Sind eine Menge definierter Anforderungen in jeweils genau einer Anforderungsversion. Genutzt • Zukünftige Anforderungen sind verpflichtend. Abhängigkeit der Informationsübergabe durch einen Dri
Stakeholder- Ziele
1. Ziele
Hauptaktivität. Diese sind um einen zentralen Kern (dunkelblau) angeordnet.
werden Anforderungskonfigurationen und -basislinien vor allem, um sinnvoll zusammenhängende Der zentrale Kern des Plakats ist variabel. Fachlich wertvolle Kerne zu verschiedenen Verwendungen der • Sie helfen in der aktuellen Lösung, Vorbereitungen zu treffen,
2. Stakeholder Anforderungen, die bereits analysiert sind, in die Realisierung bzw. in Folgedisziplinen des Ent- in den Hauptaktivitäten dargestellten Techniken können in der Mitte platziert und ausgetauscht werden.
wicklungsprozesses zu übergeben.
um Zukünftiges später optimal zu integrieren.
Durch das A3-Format der Kerne können Sie das Gesamtplakat mit dem für Sie gerade passenden Kern
tabelle
Prüfen Abstimmen Agil ≠ Agil - welche Teile Ihres Projekts wollen Sie agil abwickeln?
leicht modifizieren.
 3. Systemkontext Informationsarten
System-
System
Verhalten im Konfliktfall
kontext
3.1 Versandsystem
 3.2 Partnerbibliothek Informationsart www.sophist.de Prinzip 1 Beteiligung der richtigen Stakeholder (Relevanz der Beziehung) Der FunktionsMASTER mit Bedingungen
4. Funktionsspezifische Anforderungen Objekt–ID: Objekt–IDTyp System- System- System- System- und
Version: Ganzzahl
Prinzip 2 Trennung von Fehlersuche und Fehlerkorrektur System- System- Inbetrieb-
4.1 Allgemeingültige Anforderungen
übergreifende festlegung spezifische Design Umsetzung Integrations- Abnahme Wartung
Bedürfnisse im Vordergrund)

(Relevanz des Themas)
Historie: HistorieTyp hoher architektur dokumentation nahme

Use-Case-
Diagramm
Durchsetzungswille
«ist Version von» Durchsetzungs- Spezifikation Spezifikation test

(Befriedigung eigener
Zwang Zusammenarbeit (Enterprise-Architektur)

Prinzip 3 Prüfung aus unterschiedlichen Sichten wille Schritt 5: Schritt 0: Schritt 2:
0..1
Prinzip 4 Geeigneter Wechsel der Dokumentationsform Kompromiss- Logische und zeitliche System benennen Funktionalität identifizieren
Anforderung Testfall Ziel ...
4.2 Leihobjekt verleihen
Release: ReleaseTyp Zustand: ZustandTestfallTyp
bereitschaft Bedingungen formulieren (Das System) (Das Prozesswort)
4.2.1 Use-Case-Beschreibung
Prinzip 5 Konstruktion von Entwicklungsartefakten (Die Bedingung)
Beschreibung
Variante: VarianteTyp
Leihobjekt verleihen 0..1
Use-Case-
Vermeidung Entgegenkommen
NFA NFA 1..* 1..* «wird getestet durch» 0..* 0..* niedriger
Traceability und Nachvollziehbarkeit Rollen- und Rechte-Matrix der natürlichsprachlichen Anforderung Prinzip 6 Wiederholende Prüfung Durchsetzungs-
«trägt bei zu» wille
Zustand
4.2.2 Feinanforderung unkooperativ kooperativ

Als Benutzer möchte ich verliehene Bücher, Zeitschriften und DVDs reser- Rechte - Angelegt Analysiert Qualität geprüft ...
Leihobjekt verleihen Kooperationswille
vieren können, so dass mein reservierter Leihgegenstand nach Rückgabe
Wollen Sie (vorab) spezifizieren oder (nachher) dokumentieren?
Aktivitätsdiagramm
Use–Case Natürlichsprachliche Anforderung User–Story

Zustandsdiagramm
4.2.2.1 Bibliothekskunden identifizieren Prüfzeit- (Befriedigung der Bedürfnisse des anderen im Vordergrund)
Zustand Qualität geprüft
Name: Zeichenkette Anforderungssatz: AnforderungssatzTyp User–Story: Zeichenkette nicht entliehen wird. Vorbereitung/ Qualitätsziele Prüfer
Zustandsübergang in
Zustand Umgesetzt
4.2.2.2 Entleihberechtigung prüfen

Zustand Analysiert
punkte
Zustand Angelegt
Zustand: ZustandAnforderungTyp Zustand: ZustandAnforderungTyp Zustand: ZustandUserStoryTyp

Zustand Gelöscht
Objekt-ID: US-Bib-56
Qualität prüfen
4.2.2.3 Leihobjekt identifizieren Beschreibung: Zeichenkette Priorität: Ganzzahl Rahmen festlegen ernennen Konsolidierungsmatrix Außerhalb des Development- Außerhalb des Development- Innerhalb des Development- Innerhalb
Außerhalbdes
desDevelopment-
Development Außerhalb des Development- Außerhalb
Innerhalb des Development-
Development
Analysieren
definieren
Variantenbildung
Ober sticht Unter
4.2.2.4 Leihvorgang abschließen

Tätigkeit
Entwerfen
Akteur: Zeichenkette 0..* 0..* 0..* 0..* Planned

Anlegen
Zustand:
Abstimmung
Kompromiss
Lesen
Lesen
Lesen
Auslöser: Zeichenkette Teams - Vorstudie Teams - zeitnah Teams Teams -Teams

nachgelagert Teams - zeitnah Teams -Teams
nachgelagert
Einigung
«verfeinert» 0..*
...
...
...
Vorbedingung: Zeichenkette 0..* Version: 1

Normalablauf: Zeichenkette
Variante: REdorf Prinzip 6 Prinzip 1
4.2.2.1.1 Bibliothekskunden suchen «verfeinert» «verfeinert»
4.2.2.1.2 Kundenkarte einlesen Release: Release_1 Prinzip 3
4.2.2.1.3 Kundenkarte prüfen Rollen
«Datentyp» «Aufzählungstyp» «Aufzählungstyp» «Aufzählungstyp» Release_2 Schritt 1:
Hohe Anzahl von Stakeholdern - - + + +
Objekt–IDTyp ZustandAnforderungTyp ZustandTestfallTyp ZustandUserStoryTyp Release_3 Projektleiter - x - - x - - - x - - -
Artefakt: Zeichenkette Angelegt Angelegt Planned Prinzip 6 Hohe Kritikalität des Sachverhalts + - - - - Wichtigkeit festlegen
4.2.2.1.3.1 Kundenkarte in
3 sec prüfen
System: Zeichenkette Analysiert Analysiert In Progress Historie: Aktion Datum Uhrzeit Person Anfordernder x x - - x - - - x - - -
Weiträumige Verteilung der Stakeholder - - + + + (Die rechtliche Verbindlichkeit) Schritt 3:
Nummer: Ganzzahl Qualität geprüft Qualität geprüft Done
Naürlichsprachliche
Entworfen Getestet
Anlegen 30.02.2017 10:28 Georg Büchle Requirements-
x x x x x - - - x - - x Plan Do Hoher Zeitdruck für Konfliktauflösung - - - + + Art der Funktionalität
NFA Engineer
(Die Art der Funktionalität)
Anforderungen
Wollen Sie Ihre Wünsche systemübergreifend oder systemspezifisch umsetzen?

«Aufzählungstyp» Umgesetzt Potenziell ungültig «Datentyp» • Prüfbarkeit feststellen • Stichprobenanforderungen
Getestet Archiviert Prüfer - - - - x x x x x - - - Eindeutigkeit des Ergebnisses wichtig + + - + +
ReleaseTyp Abgenommen Gelöscht HistorieTyp Das Bibliothekssystem muss dem Benutzer die Möglichkeit bieten, ein • Prüfgegenstand definieren bewerten und beurteilen
4.3 Wiederverwendete Anforderung
• Prüfgegenstand extrahieren • Prüfbericht verfassen Geringe Sozialkompetenz der Stakeholder - - + + +
NFA Release_1 Archiviert Aktion: AktionTyp
P D
4.3.1 Fehlermeldung
Gelöscht
Leihobjekt über die Webseite der Bibliothek zu reservieren. Architekt - - - - x - - - x x x -
Release_2 Datum: DatumTyp und dokumentieren Komplizierter Sachverhalt - + - - -
5. Funktionsübergreifende NFA
Release_3 Uhrzeit: UhrzeitTyp
Objekt-ID: LH-Bib-152 Tester - - - - - - - - x - - - Systemübergreifende Umsetzung je Team Systemspezifische Umsetzung je Team
Person: PersonTyp Lange Lebensdauer der Ergebnisse + - + - - Eine Anforderungsschablone ist ein Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt.
NFA NFA
«Datentyp» Zustand: Angelegt ... Geringe Motivation der Stakeholder (aktiv mitzuwirken) - - + + + Der hier gezeigte FunktionsMASTER mit Bedingung findet für die Art der funktionalen Anforderung Anwendung. Eine Bedingung ist dem Hauptsatz vorangestellt. Funktionale Anforderungen lassen sich jedoch auch ohne q q q q q q
«Aufzählungstyp» AnforderungssatzTyp «Aufzählungstyp» Version: 5
VarianteTyp System: Zeichenkette Juristische Machtgefälle zwischen beteiligten Personen - - 0 + + Bedingungen formulieren. Dann entfällt der erste Bestandteil <Bedingung> und der Satzbau ändert sich.
Variante: REdorf Mit Hilfe von Rollen- und Rechtematrizen wird definiert, welche Rolle im Entwicklungsprozess in
Begriffsmodell
6. Begriffsmodell/Glossar JuristischeVerbindlichkeit: Juristische VerbindlichkeitTyp VerbindlichkeitTyp Problematische Gruppendynamik - - + + + System-/

A C q q q q q q
REdorf
Systemaktivität: SystemaktivitätTyp
Release: Release_1 einem definierten Zustand einer Anforderung bestimmte Tätigkeiten ausführen muss oder darf. So Product-
Analyseburg
Objekt: Zeichenkette
muss
Act Check Viele verschiedene Meinungen - - + + + Es existieren weitere detaillierte Satzschablonen für Bedingungssätze oder Nicht-funktionale Anforderungen. Diese Schablonen (auch in englischer Sprache) und viele weitere Informationen zum Thema finden Sie in der Backlog Product-
Glossar
Anforderungsweiler
Prozesswort: Zeichenkette
sollte
Release_2 wird geregelt, dass jede Person exakt weiß, wann sie ihre Tätigkeit bezüglich einer Anforderung
• Ergebnisse beurteilen Wunsch A Wunsch A Backlog
wird
durchzuführen hat. Ebenso werden Fehler in der Abarbeitung des Prozesses minimiert.
• Maßnahmen zur Qualitäts- Geringe kommunikative Fähigkeiten der Stakeholder - - + + + MASTER-Broschüre unter der Rubrik „WISSEN-for-free“ auf unserer SOPHIST-Website.
Release_3 sicherung durchführen Schlechte zeitliche Verfügbarkeit der Stakeholder - - 0 + +
Essenziell wichtig ist eine gute und zweckmäßige Struktur für die hohe Menge an Anforderungen. Ein strukturelles Metamodell (z. B. in Form eines UML-Klassendiagramms) hilft zu verstehen, welche Historie: Aktion Datum Uhrzeit Person Konflikt betrifft Sachebene + + + + -
Leicht vorstellbar als Kapitelstruktur in einem Dokument und zumeist als Baumstruktur aufge-
baut. Gliederungen aus Standards, Normen oder Vorgehensmodellen helfen, sich in der Menge der
Informationsarten mit welchen Attributen (näher definiert im Attributierungsschema) zu verwalten
sind. Ebenso zeigt es die Abhängigkeiten zwischen den Informationsarten, welche sich teilweise als
Anlegen
Inhalt geändert
01.03.2017 16:02
02.03.2017 12:40
Georg Büchle
Georg Büchle
Versionierung von Anforderungen
Das Bibliothekssystem muss Reservierungen annehmen können.
Prinzip 2
Konflikt betrifft Beziehungsebene
Konflikt betrifft Werteebene
-
-
-
- +
- -
-
-
-
Anforderungen formulieren Wortschatz / Glossar ableiten System X - Entwicklung und Dokumentation System X - Entwicklung und Dokumentation
Anforderungen zurecht zu finden. An die eigenen Bedürfnisse angepasst werden sie in der Praxis Traces im Alltag wiederfinden. Es dient auch als Basis für Werkzeugauswahl und –konfiguration und Zustand geändert 02.03.2017 13:57 Georg Büchle
einsetzbar. stellt somit ein zentrales Mittel bei der Definition des RE-Prozesses dar. Objekt-ID: LH-Bib-152
Prinzip 5 Konflikt betrifft Strukturebene - 0 0 + + System Y - Entwicklung und Dokumentation System- System- System Y - Entwicklung und Dokumentation
Zustand geändert 03.03.2017 10:52 Ralph Essenz Prinzip 3 Prinzip 4 Konflikt betrifft Interessenebene - - + 0 + übergreifende festlegung
Zustand: Analysiert Bedeutung Synonyme
Spezifikation (Enterprise-Architektur)
Aufgaben des Requirements-Managements Lebenszyklus von Informationsarten Version: 3
Bestimmender Stil in der Konfliktauflösung „Vermeidung“ - - + + +
Bestimmender Stil in der Konfliktauflösung „Zwang“ - - + - +
Traceability dient unter anderem der Nachvollziehbarkeit oder der Auswirkungsanalyse bei einge- Historie: Aktion Datum Uhrzeit Person
q q q q q q
Prototypen
Die Rolle des Bibliothekar beschreibt eine Bibliotheksmitarbeiter,

Metriken
henden Änderungen. Neben der Versionierung ist die Verfeinerung (Anforderungen über Detail- Bestimmender Stil in der Konfliktauflösung „Zusammenarbeit“ + + - - -
Testfälle
Analyse-
Anlegen 01.03.2017 16:02 Georg Büchle

Reviews
Qualitätskriterium Bibliothekar
modell
Anforderung gelöscht Analyse beendet lierungsebenen verfeinern) ein oft eingesetzter Trace zwischen Anforderungen. Dabei entsteht zu- Inhalt geändert 02.03.2017 12:40 Georg Büchle Bestimmender Stil in der Konfliktauflösung „Entgegenkommen“ + + - + - natürliche Person, die... Bibliotheksleiter
RM RM RM Gelöscht Angelegt Analysiert nächst eine Baumstruktur zwischen den Anforderungen der unterschiedlichen Detaillierungsebenen, System-/
q q q
0
q q
Bestimmender Stil in der Konfliktauflösung „Kompromissbereitschaft“
q
+ + 0 0
Qualitätssicherung
die sich in der Praxis schnell zu einem Graphen wandelt – z. B. durch Mehrfachverwendung/Wieder-
Zustand geändert 02.03.2017 13:57 Georg Büchle
Ein Leihobjekt ist ein abstrakter und verall- Leihgegenstand, Product-
durchgeführt
C C C C C C C C CCCC C C C C C C C C CCCCCCC Anforderungen Product-
Anforde [Prüfung nicht OK] verwendung von Anforderungen. Konfliktlösungen Leihobjekt gemeinerter Begriff für alle in der Bibliothek Ausleihgegenstand, Wunsch B Backlog Wunsch B Backlog
ng Vollständig X
rung Das Bibliothekssystem muss dem Benutzer die Möglichkeit bieten, ein
Verwaltung innerer Austausch von Auswertung und gelösch ssicheru
führt Konsistent X ausleihbaren Objekte, wie z. B. Bücher, ... Ausleihobjekt
Zusammenhänge Informationen Projektsteuerung OK]
Attribuierungsschema Leihobjekt zu reservieren.
Anforderung t
Qualität durchge g
Qualität
Prüfbar X A B Einigung
RE-Leitfaden
gelöscht
geprüft
[Prüfun
Objekt-ID: LH-Bib-152
Eindeutig Suchen bedeutet, dass ein Benutzer des Biblio- Vorteile: Nachteile: Vorteile: Nachteile:
Name Syntaktische Definition Semantische Definition Zustand: Angelegt X X suchen - Ganzheitliche Betrachtung eines Auftrags/Projekts. Jedes Team muss in der Lage sein, jedes anzu- Leichte Koordination der Änderungen am System. Wünsche müssen auf Systeme herunter-
Design erstellt
Realisierbar X thekssystems im Bestand der Bibliothek nach ...
Anforderung archiviert
ID ... ... Version: 4
Notwendig X X A ab B Kompromiss Einfache Umsetzung von Schnittstellenthemen. passende System zu ändern. Einfachere Bildung von Development-Teams. gebrochen werden.
RM Archiviert Entworfen Zustand angelegt, analysiert, Für eine Anforderung muss Historie: Aktion Datum Uhrzeit Person Mehrere Teams passen fortlaufend/gleichzeitig Leichtere strategische Enterprise-Architektur- Schnittstellenthemen müssen teamübergreifend
Verfolgbar X X
Code geprüft, entworfen, ... Zustand den momentanen Anlegen 01.03.2017 16:02 Georg Büchle ausleihen Ausleihen ist der Prozess, ein Leihobjekt ... verleihen ein System an. Entwicklung möglich. koordiniert werden.
RE- implementiert Bearbeitungsstand der
Inhalt geändert 02.03.2017 12:40 Georg Büchle
Techn. Lösungsneutral X
A B Variantenbildung
Mögliches Gesamtbild für die Systementwicklung
Anforderung Test durchlaufen [Test nicht OK] Anforderung bedeuten. Atomar
Leitfaden archiviert Umgesetzt
Historie ... ... Zustand geändert 02.03.2017 13:57 Georg Büchle
X X
Steuerung von Test durchlaufen
Spezifikation
Abläufen Umsetzung
abgenommen
[Test OK] Version ... ... Zustand geändert 03.03.2017 10:52 Ralph Essenz Vollständig X X A B Ober sticht Unter
[Abnahme OK] Umsetzung abgenommen[Abnahme nicht OK] Inhalt geändert 03.03.2017 10:52 Ralph Essenz Systemübergreifende Konzeption Systemspezifische Umsetzung Systemübergreifende Systemspezifische Umsetzung Systemübergreifende
Abgenommen Getestet Autor ... ... Konsistent X
Erschwinglich
Integration Integration
X Abstimmung
Der Requirments-Engineering-Leitfaden ist das zentrale Im RE-Leitfaden werden die vier grund- Darunter versteht man die Definition, welche einzelnen Zustände eine Informationsart von ihrer ersten Ein Attribuierungsschema legt pro Informationsart fest, welche Attribute für die Informationsart ge- Ändert sich der Inhalt einer Anforderung, z. B. aufgrund einer eingehenden Änderung, so wird die Abgegrenzt X
A B Inbetriebnahme Inbetriebnahme
Artefakt, in dem alle Prozesse, Methoden, Artefakte, Tools, legenden Aufgaben des RM behandelt. Erstellung bis zu ihrem Endpunkt durchläuft und welche Lebenswege (Zustandsübergang) sie dabei pflegt werden müssen. Diese sind mindestens beschrieben mit Bezeichner, mögliche Werte und Bedeu- Anforderung versioniert. Es entsteht eine lineare Kette von Anforderungsversionen auf gleicher De-
Rollen und Vorgehensweisen dokumentiert sind, die für die Darin ist beschrieben wie sie konkret im nehmen kann. Ebenso können hiermit Rollen, Tätigkeiten, Ereignisse und Bedingungen verknüpft tung der einzelnen Werte. Attribute müssen gepflegt werden, denn sie dienen weiteren Techniken wie taillierungsebene. Vorgänger- und Nachfolgerversion sind bidirektional miteinander verlinkt. Alte Vorgehen und Methoden zur Prüfung, ob die Anforderungen in der Qualität vorliegen, die vorab Umgang mit unterschiedlichen oder sich widersprechenden Anforderungen. q q q q q q q q
Durchführung der Anforderungsanalyse gebraucht werden. Projekt durchgeführt werden. werden. Gut darstellbar z. B. mit einem UML-Zustandsdiagramm. Sichtenbildung oder Traceability. Versionen dienen der Nachvollziehbarkeit und gelten nicht mehr als aktive Anforderung. vereinbart wurde.
Anforderungen formulieren System-/
Product- System X System X
Wunsch A
q q q q V1
q q q q V2
Verwalten Prüfen und Abstimmen

Backlog
Projekt C
q q q q q q q q
System- System- System-/
übergreifende festlegung System Y System Y
Spezifikation Product-
q q q q q q q q
(Enterprise-Architektur) R3.a R3.b
Backlog
www.sophist.de
CCB
© SOPHIST GmbH 2017

Change Control Board
Vorstudie B System- System-

System-/ System-
spezifische Design Umsetzung dokumen- System Z
Product- architektur 2019
Backlog Spezifikation tation
© SOPHIST GmbH www.sophist.de

Auf dem Weg zu agilen Skalierungsansätzen wie SAFe, LeSS, Nexus, Scrum@Scale, DAD, ...
An welchen Stellen einer agilen Entwicklung Was muss spezifiziert / dokumentiert werden?
werden Methoden des RE angewendet? Disziplinen benötigen Inhalte in
Qualitätsstufen
Knowledge Areas in Anlehnung an SWEBOK
1: exemplarisch, nicht abgestimmt bis System System System System System
Ermitteln, 3: vollständig und eindeutig Requirements Design Construction Testing Maintenance
Abstimmen, Retro Allgemein
Dokumentieren Ziele des Systems 3 3 - 3 3
Systemkontext 1 3 - 3 3
Ermitteln, Review q Daily Stakeholderliste 1 - - - 3
Dokumentieren, Basis für Annahmen 1 2 - - -
Prüfen DoR Fachbegriffsdefinition 1 1 1 1 1
Geschäftsprozesse inkl. Geschäftsregeln 3 - - - -
Product- Refine-
ment
Sprint
Planning Sprint- q Product
(Definition of
Ready)
und
System
Informationsmodell -
-
3 3 3 3
Backlog Meeting Backlog DoD
Funktionalität 2 3 3 3
Nicht-funktionale Anforderungen 1 2 3 3 3
(Definition of Done) Abnahmekriterien - - - 3 -
Backlog- Ermitteln, Dokumentieren Definition Schnittstellen 2 2 3 3 3
Verwalten Item Verwalten Dokumentieren, (Nicht-funktionale of Done Human Machine Interface - 2 3 3 3
Prüfen Anforderungen) Umgang mit Fehlerfällen - - - - 3
© SOPHIST GmbH www.sophist.de

62 Business Analysis
Creating a business case

Iv } } R] ]u}uv } o} v` }U R . ] } .v
} `R ] ]X TR(}U ` ]v(˙ }vo `]R } }uU ]
]v ]uvU }oo ov }o}v v o RuX I v
}v R ]}vo `˙ ˙ uv }( (]]o]˙ ]U }v}u] (]]o]˙ ]U
X H}Ù } }i ˘]v R}` R R }( P]o Rv] ] ]]vP
]v R] P } v `]R u]v]uu ]o } ~MVPZU]]}v uvU
product box, etc., which are presented in the course of an elevator pitch.
Requirements engineering
Is it done? Has the management been convinced of the product idea/business case?
Then requirements engineering begins. Never mind if it’s a classical or agile process
u}oX ]o D ]v(}u}v } R o }o}v ov v }
u]vU ]uv ]U }uvU ]}] v ]u } R
development team.
The best way to do this can be found in our brochures, books, on our website or in
}vo}v}vX
Establishing developed solution

F]voo˙UR u} ]u}v P } }uv˙ R o]Ruv }( R }o}v
]v} R P v]}vuvX E]oo˙ ]( v` }L` R v o} }
}u] R ]v }U } v ]( R }o}v o +U }]vP
`]R ]o }v ] }uuvX I `}o ˙ } i u R Rv]o
]uv (} ]vPvP }L` ]v} R }}v v]}vuv R[
v} v}PRX TR P R o] ]v R ]l R R lR}o `]ooi R
}o}v } ˘]vo ( } R ( }( RvPX TR l˙ o] ]v òorovvU
}Pv]}vo RvP } ~ o} PR r o]Ruv
E }( v ]u}
]uvvP]v]vPZRvPPoo}o+l]v}oX
So, business analysis and requirements engineering are closely intertwined. If help is
vU`˙vR˙}}voJ
63 Videos within Requirements Engineering
12. Videos within Requirements Engineering

In the context of requirements
vP]v]vP ] uv˙
requirements will be created
that should be documented
} ]u ]v ]+v `˙X
TR }oo}v }( ]uv
can get very complex. As a
o R }vv}v `v
the requirements can be lost
notwithstanding model-based
}uv}v Rv] }
story maps are used.
V]} v RoX Au}vP }R R]vP R˙ v R}` uv˙ uoo ]uv v
R] }vv}v ]v }uRv]o `˙X V]} v o} Ro ]v R o]]}v
phase; the original problem or the context of the new system can be shown.
Thanks to modern technology it’s no problem to create and send such videos. There
are apps for smart devices to create and edit videos, which are cheap or free and
˙ } X O( }U R ovv]vPU R }v v R ]vP }( R ]}
v} }uoo˙ (X H}Ù R u v R(} } v }uv
˙ (` } (} ]uvP R ]uvX E]oo˙U ]( R o} }( l -
holders and consumers. To keep the cost of the videos as low as possible, we have
]G˙ uu] R u} ]u}v R}PR v ]v]o (} R] }v
and use.
The PILZ of the video

(}
B vP } .ou ]}U ] v } ] (oo˙ `R]R }vv v
} R ]} Roo RX W R .v `˙ R ` oo PILZ
~Guv (} uR}}uZX Iv PILZU(} ]+v ]uv]}v U `R]R
u]v]Pv].vo˙R}vvvR(}u}(R]}~R]ZX
v Phase (“Phase”): In which phase of the requirements engineering process
R}o R ]} X F} ˘uoU R}o ] } R o]]}v } R
]uvP}(R]uvM
v C}vv ~SIvRo _ZPSRoo R ]} ]u R } ˙vu] }vvM
EXPXR U v}v }( R vv }( R R} ]v `R]R }( R
v` u R}u ˙u Roo u ~Z } R vo˙ ˙]o
sequence when entering the house without the new system (dynamic).
v S}o}v (v ~SLvPP _ZP H}` uR }( }]o ~ir].
}Rv]oZ }o}v Roo P]vMI] }]o }R}`Rv]vP}( PIN
} l˙ ~Rv]o }o}vZ } R] }v v R]v R]v v
]v`]RRooARv}v~}o}vrvoZX
v T]u (v ~SZ]P _ZP D} R ]} v P } R

current state? In other words: Does the video show a goal in an abstract way, or
does it show the currently given state?
F} R ]+v R] ]v R (} ]uv]}vU ` }uuv }v
} } R }v }( R ] v R v R o]˙ }( R ]}X F}
˘uoU } R}` }vvU ] R}o `]R `v v }]` v
]o R}U R}`]vP R ]o (} ]v u}v }( u `]R} RvP]vP R
u }]}vX Iv R ` R P]v R }uo o] }( R] }( R
]uv]}v]vo]vPR}uuv}vX
Embedding into a collection of requirements

Av}R }( } }R ] } ] R}` ]} v o]vl } }oo}v
}( ]uvX V]} ]v ]uv vP]v]vP oo˙ R [
U } R˙ v R}u}Pv}o˙ ]vP ]v} }uv
that use use cases as the top hierarchical level.
1. Higher-level scenario
1.1 Use case 1 (Open door)

XXM]vv]}
XXXR}Pv]}v
Scenario video XXXV](˙}v
1.1.1.3 Open door leaf
1.1.1.4 ...
XXovA v]}r}}
D ]o}l
1.1.2.1 Stop door opening
Use case video
1.1.2.2 Issue warning signal
1.1.2.3 ...
XU~Co}}}Z
XXM]vv]}
XXXA]˙
XXXA]˙
F]PXPLo}(]o(}]}
With this approach, it can be decided which content shall be presented at which
}v oo ]v ]+v ]}X F]P X R}` ]+v ]} R
ooU R ]o] ]+v }( R }]o vX TR
]} v v}` o} }PR } ]o] R]PRroo vU } R
]uv}oo}vv˘v]o˙]+v}vooX
Shooting videos in a workshop

TR }( vP ]} ] v ]vv] vo˙] `]R R }vv
R Roo vX Iv } ˘]vU R }v }( ]} v }v ˙
òo ]v `}lR}X D]vP R ovv]vP v o R}}vP }( R ]}U vP
]v ] } v (}vX ]oD u .v oo˙U v
˘]vP ]uv u }o Rl } ]( R˙ XPXU }v[ o˙
}v]v ~v]vvZ }( }o}vX WRv vP R ]U R `˙ }(
`}l]vP `]R R ]uv ] ]oX I RoU ]( o }o }oo}vPX
TRo R}}vP] o`˙P} vR`]oo uu(}o}vP u
˙ooo]vPv}vP}X
Iv ]}v } PILZU` R }u }R }}o ˙ } }v ]} `}lR}U
XPXU }˙} v u}} }X M} ]o v (}v }v } `]
www.sophist.de/re7/kapitel27.
66 RE for Product Lines and Families
13. Requirements Engineering for Product

Lines and Families
W }u ol˙J W v o`˙ v ˙`R R}} (}u uv˙ o -
v r} v ' r } }`v ]v]]o }X T} ul R] }]oU
` }U (} ˘uo ˙ }v.P}X Iv uv˙ U R ]o ]PR u}
]v]]o}UR'X
H}Ù P}`]vP ]˙ v ]v]]o]˙ o } }uo]}v ]v R }
o}uvX Iv } R o}uv +} uR }]oV R v -
o˙] }( }}v v } ]u]o] ] ]u}vX TR P}o ] } (o.oo
uv˙ ]+v }u ]uv }]o `]R R o }]o o} -
uv +}X N}`˙ u} } v[ vÙ o} (R ]v
v }o}v˙ uvvX Aou} v}}˙ ovR ]vPo }U oo˙
} (u]o˙ } } o]vU]v `R]R R } ]+ u} } oX Iv R ]]
}( R]L oLP TR o] R] ( ] lv ]v} }v ]v R o}uv }U
R R]PR R ]vP }vo ]v R v o}uv } W U ]( o˙
}v]]v}}o]}uvPuv`Rv.v]vPR}P˙X
The feature model

W u R R o } R ]u]o ]v u }( R] }
v (v}vU o} ]+ ]v }u `˙X TR } } (v}v oo
R] } (X L R˙ v } o } ]vP]R `v
]vX F} }uv}v }U R ( u}o R }v } (o
v}}vX
Smoke alarm }vG] ov or
white requires }}vo uv}˙

C}o} «custom»
cream u}l o
}v
D uR} G
temperature
SHSvv}.}v
C}vv]˙
uPv˙
E }uuv]}v
'˙B
Internal power supply
Rechargeable
'˙
Power supply
PoE
External power supply
VDC
F]PXPFu}o}(u}lou
67 RE for Product Lines and Families
If the product is supposed to be described "as always", to each requirement the

matching feature from the feature model can be assigned. The features can be linked
} ]uv } ]uo˙ v v '] }( R ]uv (} R
mapping.
Smoke alarm
UCV]uv S}lD]}v (}u F
Detect danger Always
ru}l
D o Su}lo
- Detect gas G
- Detect temperature Temperature
S]Pvo]v Always
- Signal danger Always
- Signal event SHSvv}.}v
U}]}vv}v EuPv˙C}uuv]}v
CRP'˙ CRPo'˙
o]R
E }vv}v } }v}o v SHS]v]v]Pvo]]vP
Turn on system Always
Tv}+˙u Always
F]PXPM]vP]uv(
B }v R ( u}o v ] oU ] ] ˙ } u]v ]+v ]v

vU }( }U R u]v]uu ]o } ~MVPZ } o}u ~`R]R ] }uu}v
to all products).
Obviously the goal is not only to reuse the requirements, but also other development
(RR]U}voU](}]oX
Feature peak
Requirements peak
F
Architecture peak
F F
F F
F F F F
XXX XXX
Test peak XXX XXX
F]PXPPlM}o
68 Conclusion
14. Conclusion
Requirements and user stories are the heart of successful system development.
TR˙ v ] } v (]oU R˙ R }v]}v (} }vU
} ]uouv}v v o}uvU òo v v ]]X
TR]o]}P]oo}uviuR}o]oo}uvX
R]uv vP]v]vP ] uv]vP .o }( ] R }v uv˙
}]]o]X F} ]vvU }(]}vo ]uv vP]v]vP ]v R
Rv (} R }( }i ]v IT v]}vuv v }RX Av }]
analysis can ensure that
• the system to be developed is described appropriately to the procedure.
{ R (o.oouv }( P}o ] v ˙ R }] ]uv } }]X
• only agreed and tested requirements that meet the goal, are implemented.
Even if the expenses for a requirements engineering that is adapted to the approach
u R]PRr o} }(u}v˙ ] ](R o}uv P} ]v}R ]PR ]}v
and match the customer's wishes right from the beginning. Requirements engineering
]`}R]}J
This brochure is supposed to give an impression of what belongs to the basic work of
a requirements engineer. Of course, we could only present a small part of a complex
i}X TR u} ]v(}u}v ]v } o]}vU }v } `] v }( } ]v
}vovP}v}vv]v]vPX
S} ]( ˙} `v } ov (}u R ]}vU }(]}vo v o }vU
SOPHIST is the right place for you. Equipped with years of experience in a variety of
}v˘U ` R˙ } l }( ˙}U ˙} }i v ˙} }r`}lX W
are always in line with your needs, because our customers are the centre of all of
} ]X W R v} v }RX W }U Rv] v
methods individually to your needs. Together we can work out the approach that
`}l (} ˙}X A R v]v Gl S}R] ] W T} R Ruv ]vP ] R
measure of all things.
Wo}}l]vP(}`}P«vP]v}R`]R˙}X
Yours, the SOPHISTs
69 Bibliography
Bibliography
[Babok Ivv}vo Iv }( B]v vo˙]P ABOK P L] -
(v u B]v Avo˙] B}˙ }( Kv}òPU ]}v
E U
W'vP
Bvoæ BvoU RXVG]vU JXP
TR S }( MP] IIXS]v v
BR]}B}}lUPo}Ao}lCAUıæX
Bvoı BvoU RXU
G]vU JXP
MR v P˙R}R]U D]
Sl MP] IX ]}v
E X Jv(uvvU P}vU ııX
CPRE P}RoKUXV RU CXPB]`]v R]uv E vP]v]vP X Ar
v W]]ovP u .C P}(]}vo (} R]uv
E vP]v]vP W F}v}v Lo vR IREBrSvU ]}v
E U
Heidelberg, 2020.
G}}`]vıP G}}`]vU KXP D]Pv]vP F} TR D]P]o APX ]}v
E U Iv] -
napolis, 2009.
INCOSE INCOSEP G] } R S˙u EvP]v]vP B}˙ }(
Kv}òPX Iv}}v } S˙u EvP]v]vP ~ıZU
https://www.sebokwiki.org/wiki/Introduction_to_Systems_
Engineering (as of 01/09/2020)
ISO ISOrN}u P R} R]oX Fv}vo (˙U ]}v
E U
2018.
[P}'R] P}'R]U KXV GITOP D]P]o Tv(}u}v ~ZU
R P l l```X v ˙lo} ] r r`] R ( ]v(} u ]l X l
o ˘]l}v l Rv}o}P] v ru R} v lIv(} u ]l r rG v o P v l
]P]o]]vP l]P]orv(}u}v (as of 04/01/2020)
R RU CR]P R]uvrEvP]v]vP v WMvPuvU A
P˘] }v lo]R ] P]oX ]}v
E X HvU M”vRvU
2020.
SAF So AP]o Fu`}lP So AP]o Fu`}l ~}XJXZU
R'Pll```XoP]o(u`}lX}ul (as of 04/01/2020)
Wl WlU BXPINVEST ]v G}} S}]U v SMART Tl ~ZU
R' Pl l˘ X}u l o l]v r]v rP}} r}] rv ru r
tasks (as of 07/25/2019)
W]R Mv W]RP FMEA W E]v(”RvP v M}}vX
]}v
E XV]`PTvU
W}o( W}o(U PX]vB P M' TvovP RR ]v} Co}}u
PX]}v
E XAo˘v]UX
70 Notes
71 Notes
The basics of Requirements Engineering
WRv o}]vP ˙u r ] }L` } ]o]vP r R u} ]u}v ]] -
te for success is that all those who are involved know exactly what is to be developed. And
R] o˙ P]vv `]R R }PR P v v `]R R]PRo˙]o ]v}v (}
R
]uouv}vX
TR`}l}(]uvvP]vo]o˙`]RR]}]XTR]i}]v}oP
{ o]]}vU
{ }uv}vU
{ o]}vv}v}o]}vUòo
• management
of system requirements.
W]RR]}RU ` `v } P] ˙}v }]` }(R ] o}vP]vP } R }o
vURvU`RÙRSOPHISTRUR]o]]v(}v}`}˙X

RE Primer Eng

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

RE Primer Eng

Uploaded by

Copyright:

Available Formats

The SOPHISTs SOPHIST GmbH

1St edition 2021

Translated from German by Joachim Kurrer,

Copyright: SOPHIST GmbH

This work is protected by copyright laws.

»Short & clever«

What‘s new about it?

2. What is Requirements Engineering? ������������������������������������������10

7. Establishment of an Improved Requirements Engineering ������43

8. Requirements Engineering and Agility����������������������������������������48

9. Systems Engineering ��������������������������������������������������������������������52

10. Requirements Engineering for Smart Ecosystems and as a Driver

11. Business Analysis, Requirements Engineering or Both?������������60

1. Introduction and Motivation

O o]( ] }vPo˙ ]vGv ˙ ITr˙u W }uu ] v v }v RuX

Mv˙ Rvl } oo SOPHISTU `R} R }v] } R] }R W R v

2. What is Requirements Engineering?

Definition of the discipline requirements engineering according to IREB

Uv]]vPo˙U R u ]uv ] }( ]}o ]u}v ]v R] .v]}vX

Definition of the term requirement according to SOPHIST:

FRu}U R] .v]}v }( ]uv vP]v]vP ul R }roo l -

o(r}v.v ethical conscience

Iv R (}oo}`]vPPRU ` `]oov }u ] lv}`oP R ] vo

2.1 Classification of Requirements

Traditional classification according to types

User interface requirements

Technological constraints Qo]˙]uv

The two most frequently needed types are:

Classification according to legal obligation

]. ]v `˙ R }] v}PR ]v(}u}v (} ˙}v ]v}oX

Classification according to responsibility

Source of requirement Requirements-

Original requirements System requirements

Classification according to subject matter

Classification according to the level of detail

2.2 Quality of Requirements

Requirements for classic approaches

Requirements for agile approaches

Independent INVEST Testable

TR ]] (} }( ]uvU uv]vP lo}PU o˙ v˙ ]+v

2.3 Sources of Requirements

Management of innovation/ portfolio / product

Problem/ change management

2.4 Main Activities of Requirements Engineering

E o]]vP Deriving good IuvP MvP]vP

vE R}PR ` v R u]v ] ]v R } uv}v }U R

Deriving good requirements

v WR l]v }( ]v(}u}v } R ]uv }oo}v }v] }( v R}`

3.1 Goals, Sources and System Context

Goals and goal finding

v }v u]v } oo }]o }o}v u} ]u}vX I( v }o ˙u Roo

System scope and context

3.2 Elicitation of Requirements

Precondition for a good elicitation

Criteria for the selection of elicitation techniques

Four groups of classical elicitation techniques

New approaches/ frameworks - co- creation-

3.3 Identifying Linguistic Ecects –

DISTORTION is an indicator for

The SOPHIST Set of REgulations

W??? Adding process details

words VPU ]o˙U oU ooU uoXXX

iA ] (}u P .oU R }uvU }v.P

2. What is Requirements Engineering? ��10

7. Establishment of an Improved Requirements Engineering ��43

8. Requirements Engineering and Agility��48

9. Systems Engineering ��52

11. Business Analysis, Requirements Engineering or Both?��60