Software Engineering Tutorial Deutsch #12 - Requirements Engineering
Programmieren Starten
https://www.youtube.com/watch?v=w21HJ9aTaTs

Transkript (automatisch erstellt)

0:00 hallo und herzlich willkommen auf dem youtube-kanal von programmieren - starten punkt.de mein name ist hendrik und heute soll es mit der software
0:10 engineering serie weitergehen in den letzten videos haben wir uns ja bereits zahlreiche vorgehensmodelle angesehen
0:17 wir haben zunächst mit den klassischen vorgehensmodellen begonnen und uns dann weiter zu den heutzutage sehr populären agilen vorgehensmodellen durchgearbeitet
0:25 und da wir diese nun kennen können wir uns nun wieder um die detail arbeit im software engineering kümmern und deshalb sehen wir uns in diesem video jetzt mal
0:34 im detail die anforderungsanalyse bzw im speziellen das requirements engineering an was werden wir also in diesem video
0:44 alles lernen zunächst werden wir uns mal ansehen was man überhaupt unter dem begriff requirements engineering versteht
0:51 danach werden wir sehen dass man die anforderungen kategorisieren kann es gibt also unterschiedliche arten und dann werden wir noch auf ein paar punkte
1:00 eingehen die beim requirements engineering eben häufig zu problemen führen bevor wir jetzt mit dem ersten punkt
1:07 beginnen möchte ich noch einen ganz kurzen einschub machen und zwar nur um dir schnell zu zeigen an welcher stelle sich das requirements engineering im
1:15 software lebenszyklus wieder findet und zwar befinden wir uns direkt am beginn nämlich in der anforderungsanalyse das wie gesagt nutzung überblick damit du
1:25 den gesamtzusammenhang nicht aus den augen verliert beginnen wir nun also mit dem ersten punkt nämlich was versteht man unter requirements engineering
1:34 requirements engineering kurz re ist ein prozess in dem kunden anforderungen für ein zu erstellendes system ermittelt dokumentiert überprüft und verwaltet
1:46 werden das ziel von requirements engineering ist beziehungsweise das hauptziel ist dass alle anforderungen an das zu
1:53 erstellende systemen ermittelt durchdacht und vor allem verstanden würden und das hat dann wiederum den vorteil dass man so sehr gut überprüfen
2:01 kann ob alle stakeholder den anforderungen zustimmen oder ob irgendjemand etwas falsch verstanden hat und es
2:08 eigentlich ganz anders gemeint hat wie sieht der prozess also jetzt mal aus zunächst werden alle anforderungen ermittelt das heißt es werden alle
2:17 anforderungen an das zu erstellende system gesammelt sobald dies geschehen ist werden diese im zweiten schritt dokumentiert das heißt sie werden
2:26 präzise ausformuliert und niedergeschrieben im dritten schritt werden die anforderungen dann geprüft und
2:32 abgestimmt und abschließend müssen sie noch verwaltet werden das heißt es muss stetig nachverfolgt werden ob es beispielsweise zu irgendwelchen
2:40 änderungen der anforderungen gekommen ist und damit weist jetzt schon mal was von unterwegs engineering also hinter diesem begriff versteht
2:49 jetzt haben wir hier gerade sehr viel über anforderungen gesprochen diese anforderungen kann man jetzt noch mal in zwei kategorien aufteilen
2:57 zum einen gibt es die funktionalen anforderungen diese funktionalen anforderungen beschreiben was ein system tun soll
3:05 also jetzt aus der sicht von den funktionalen aspekten stell dir einfach mal vor wir schreiben eine software für den bankensektor eine funktionale
3:15 anforderungen könnte dann sein die software soll basierend auf einer formel die kreditwürdigkeit berechnen oder eine weitere funktionale
3:23 anforderungen könnte sein die software soll ein mechanismus zur identifizierung von benutzern vorsehen also ich hier sieht man dass man hat
3:31 einen ganz klaren fokus bei diesem funktionalen anforderungen darauf was das system letztendlich tun soll neben den funktionalen anforderungen
3:39 gibt es jetzt aber auch noch die nicht funktionalen anforderungen diese beschreiben einschränkende bedingungen wie die funktionalen
3:47 anforderungen zu realisieren sind hier wäre jetzt mal ein beispiel die software soll den anwender innerhalb von einer sekunde antworten also hier geht
3:55 es dann eher im allgemeinen um beschränkungen und nicht um ganz spezifische dinge die die software tun soll
4:02 wie gesagt das beispiel habe ich jetzt gerade schon genannt so jetzt haben wir mal gelernt was requirements engineering ist und wie man anforderungen noch mal
4:11 kategorisieren kann jetzt gibt es aber noch einen weiteren punkt auf den ich in diesem video noch eingehen möchte und zwar möchte ich dir
4:18 häufige probleme auf beziehungsweise ich möchte dir punkte aufzeigen die zu häufigen problemen führen und zwar bei der ermittlung von
4:27 anforderungen man könnte jetzt meinen dass man die anforderungen ratz fatz unterschreiben kann und das ganze überhaupt kein
4:34 problem darstellen sollte dem ist aber leider nicht zu denn stakeholder können anforderungen oft nicht korrekt ausdrücken
4:41 das heißt jeder hat so seine eigenen vorstellungen von etwas und es ist manchmal für einen persönlich vollkommen klar was man gerade meint aber ein
4:50 anderer kann das dann wieder vollkommen anders auffassen und da kommt es dann eben zu kommunikationsproblemen die verwendung von fachsprache kann ein
4:59 zweites problem darstellen denn häufig kommen die stakeholder aus ganz unterschiedlichen bereichen die haben dann quasi eine
5:06 unterschiedliche vorgeschichte also in unterschiedlichem background und dementsprechend verstehen manche eine gewisse ja fachsprache einfach nicht das
5:14 heißt auch hier kann es zu kommunikationsproblemen kommen ein weiteres problem könnten widersprüchliche sichten auf den
5:21 ist-zustand darstellen oder eine unklare zielvorstellung von der zu erstellenden software oder aber auch implizites und unbewusstes wissen da hab ich ja eben
5:31 schon das beispiel gehabt mit dem unterschiedlichem background jetzt stell dir mal vor ein informatiker spricht mit einem
5:37 projektmanager der selbst kein informatik background hat der spricht natürlich ja einer ganz anderen fachsprache oder beziehungsweise setzt
5:45 auch ganz andere dinge voraus die man wissen sollte die ware eben in seiner eigenen blase so lebt mit den ganzen anderen informatikern und genauso ist
5:54 vielleicht bei den projektmanager der ganz viel ahnung von finanzen hat der setzt natürlich auch da gewisse dinge voraus den informatiker wiederum nicht
6:03 versteht da gibt es also kein gut oder schlecht die leute kommen einfach aus unterschiedlichen bereichen und das muss man eben unbedingt beachten
6:11 und das waren jetzt mal so punkte die beim requirements engineering zu problemen führen können und man sollte sich diesen einfach
6:18 bewusst sein deswegen wollte ich hier jetzt auch nochmal erwähnen so und damit hast du jetzt mal im schnelldurchlauf das requirements engineering
6:25 kennengelernt ich hoffe das bemerkt der softwareentwicklung ein sehr kommunikativer prozess ist und vor allem dass es wahnsinnig wichtig für den
6:34 erfolg ist sich im vorfeld detailliert über die anforderungen des zu erstellenden systems auszutauschen und im prinzip sollte man schon darauf
6:43 achten dass man vielleicht zu 10 20 25 prozent von derzeit auf das definieren der anforderungen verwendet wenn es mehr zeit erfordert dann von mir aus auch
6:53 mehr es kann natürlich auch kürzer sein aber man sollte sich eben bewusst sein dass das ein ganz ganz wichtiger prozess ist denn sonst baut man am ende die
7:01 falsche software dann hat sich quasi alles nicht gelohnt das war es jetzt zu diesem video ich hoffe es hat dir gefallen falls ja gibt
7:10 uns gerne einen daumen nach oben wir würden uns sehr freuen 1 kommentar wer auch super da kannst du zum beispiel uns ein feedback geben wie
7:17 die unsere videos generell findest oder wie du diese spezifische video hier findest und falls wir den kanal noch nicht abonniert haben solltest dann holt
7:24 das jetzt nach indem du unter diesem video auf den abonnieren button klicken und dann wirst du in zukunft nichts mehr von uns verpassen
7:31 ich wünsche dir noch einen schönen tag und dann sehen wir uns im nächsten video wieder ciao