[0:00] Hi, hier ist Stefan. In dieser Podcast-Episode geht es um die Projektdokumentation. Wenn du

[0:05] dazu noch mehr Informationen von mir haben willst, dann schau doch mal auf meiner Website vorbei unter

[0:09] dieperfekteprojektdokumentation.de. Und jetzt viel Spaß mit der Podcast-Episode.

[0:19] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den IT-Berufen.

[0:25] In dieser Episode geht es um die Anforderungsermittlung, unter anderem für dein Abschlussprojekt. Viel Spaß.

[0:36] Hallo und herzlich willkommen zur 159. Episode des IT-Berufe-Podcasts. Mein Name ist Stefan

[0:44] Macke und heute geht es mal wieder um ein allgemeines Thema, was für alle IT-Berufe da

[0:48] draußen interessant sein sollte. Gut, dass der IT-Berufe-Podcast jetzt so heißt und nicht mehr

[0:53] Anwendungsentwickler-Podcast. Beim letzten Mal haben wir uns ja ein bisschen über funktionale

[0:56] Programmierung unterhalten. Das ging mehr so in Richtung der Anwendungsentwickler. Aber heute

[0:59] geht es um das Thema Anforderungsermittlung oder Anforderungsanalyse oder Aufnahme oder wie auch

[1:05] immer. Und jetzt kann man sich fragen, wer braucht das? Naja, jeder Prüfling braucht das, denn alle

[1:10] IT-Berufe enden ja mit einem Abschlussprojekt, was Teil der Note ist. Und zu diesem Abschlussprojekt

[1:15] gibt es auch eine ganze Reihe an Anforderungen sicherlich. Und da ist es der Job des Prüflings,

[1:23] genau dein Job tatsächlich, diese Anforderungen aufzunehmen für dein eigenes Projekt. Und wie

[1:28] man das am besten macht, was überhaupt Anforderungen sind, wofür wir die brauchen,

[1:31] wie wir die erheben, wen wir fragen müssen und was es vielleicht auch sogar für Anforderungen

[1:35] an diese Anforderungen gibt, nämlich wie man die am besten aufschreibt, das wollen wir uns

[1:39] alles heute mal ein bisschen auf der Zunge zergehen lassen. Ich habe da ein bisschen

[1:42] was mitgebracht. Ich glaube, das könnte heute ein bisschen länger dauern. Wir schauen mal,

[1:45] wie schnell ich durchkomme. Und ja, noch mal zur Erklärung. Also was haben wir vor? Du willst

[1:50] dein Abschlussprojekt starten, hast auch grob eine Idee, worum es geht. Ich hoffe,

[1:54] du hast dir schon ein vernünftiges Projektthema ausgesucht. Dazu habe ich auch schon eine Podcast

[1:58] Episode aufgenommen, wie man das am besten macht und wie du auf Ideen kommst. Und darum sollte es

[2:02] heute nicht gehen, sondern du hast jetzt schon dein Thema vor Augen. Du weißt, was du machen

[2:05] willst, grob. Und jetzt geht es darum, das zu verfeinern. Was sind genau die Anforderungen,

[2:11] die du eigentlich umsetzen sollst? Und da kann man jetzt natürlich überlegen, ist es überhaupt

[2:14] dein Job, diese Anforderungen aufzunehmen? Und ich sage einfach mal, ja, das ist in den meisten

[2:19] Fällen so. Wenn du in einem ganz tollen Unternehmen bist, wo du die Anforderungen auf

[2:22] einem Silbertablett vom Fachbereich oder von deinem Kunden oder von deinem Vorgesetzten,

[2:25] wie auch immer, serviert bekommst, ist das alles ganz toll. Ich glaube, in der Praxis sieht das

[2:30] eher nicht so aus. Wahrscheinlich hast du irgendwie so eine grobe Idee oder eine Richtung bekommen,

[2:34] wohin es gehen soll, was du erreichen sollst. Aber wie das jetzt genau ausgestaltet werden

[2:38] soll, also die Details quasi, das ist eigentlich dein Job, das aufzunehmen. Zumindest würde ich

[2:43] das so sehen, wenn ein Prüfling ein Projekt umsetzt. Du sollst ja den gesamten Projektablauf

[2:48] begleiten und dokumentieren, vor allem auch in der Projektdokumentation. Und dazu gehört

[2:51] unbedingt auch die Anforderungsanalyse oder eben Aufnahme. Und wenn man jetzt überlegt,

[2:57] in was für einem Artefakt das Ganze enden könnte, dann wäre das für mich in so einer

[3:01] Projektdokumentation so etwas wie ein Lastenheft. Oder, wenn man noch einen Schritt weiter geht,

[3:05] das Pflichtenheft. Eigentlich ist es ja so, dass der Auftraggeber das Lastenheft erstellt,

[3:12] also der Kunde. Der sagt, was er haben will, fachlich grob vorgegeben, was die Anwendung

[3:18] zum Beispiel, die du erstellst oder das System, das du installierst oder was auch immer du machst

[3:22] in deinem Abschlussprojekt, was das bieten soll quasi. Und dann bist du in der Pflicht,

[3:26] das Pflichtenheft zu erstellen. Wow, zweimal Pflicht. Das heißt, der Auftragnehmer,

[3:31] der das Projekt umsetzt, der erstellt das Pflichtenheft. Und das ist mit technischen

[3:34] Details, was genau umgesetzt wird, wenn ich es mal wieder an einer Anwendung zum Beispiel

[3:39] mache, die entwickelt werden soll. Welche Programmiersprache? Welche Architektur? Wenn

[3:43] ich ein FISI zum Beispiel habe, welches konkrete Betriebssystem wird denn eingesetzt? Wie groß

[3:48] soll die Festplatte werden? Ist es eine Cloud oder On-Premise? Und ich weiß nicht was. Also

[3:52] ganz genau die technischen Details, die erstellt der Auftragnehmer. Ich bring's auch mal durcheinander,

[3:58] Auftragnehmer. Also der, der es umsetzt. Also du. Und das Lastenheft, wo die Anforderungen

[4:03] eigentlich drinstehen, das kommt vom Kunden. Ich weiß aber, dass es in der Praxis häufig so läuft,

[4:08] dass auch der Prüfling das Lastenheft erstellt. Ich kann es nur jetzt zum Beispiel auf unser

[4:11] Unternehmen übertragen. Da haben wir jetzt nicht die perfekt ausgebildeten Menschen im Fachbereich,

[4:16] die dir da so ein Lastenheft drunter schreiben, wo alles drinsteht, was gemacht werden soll. So

[4:20] nach dem Motto, du kriegst da so ein Stapel Papier und dann musst du nie wieder mit den

[4:22] Leuten reden und setz das einfach um. Das funktioniert in der Praxis eher weniger. Es

[4:26] gibt ganz häufig irgendwelche Rückfragen und spätestens dann musst du ja so ein paar Tools

[4:31] an der Hand haben, wie du genau rausbekommst, was du eigentlich machen sollst. Und darum soll es

[4:34] heute gehen. Ich möchte jetzt heute mit dir nicht Lasten- und Pflichtenheft im Detail durchgehen,

[4:40] wie man das aufstellt. Da habe ich schon mal, glaube ich, einen sehr langen Blogartikel zu

[4:43] geschrieben. Ich weiß es gar nicht mehr. Du kannst mal suchen bei mir im Blog. Darum soll es heute

[4:46] nicht gehen, sondern es geht wirklich um die Anforderungen. Und du kannst das konkret beziehen

[4:50] auf dein Abschlussprojekt, aber auch auf alles andere, was du auf der Arbeit machen musst. Also,

[4:54] wie kommst du zu den Anforderungen? Und bevor wir jetzt mal damit anfangen, kleiner Überblick,

[4:59] was ich heute so vorhabe oder in dieser Episode. Wir fangen erst mal an, was sind überhaupt

[5:02] Anforderungen? Wie lassen die sich gliedern? Wofür braucht man die? Und dann kommen wir zum Begriff

[5:07] der Stakeholder. Wer definiert überhaupt unsere Anforderungen? Wen müssen wir fragen, um solche

[5:12] Anforderungen herauszubekommen? Und dann haben wir noch konkrete Methoden der Anforderungsermittlung.

[5:16] Das heißt, wenn du jetzt vor der Aufgabe stehst, du weißt, wen du fragen musst und was Anforderungen

[5:20] sind, aber wie kriegst du die jetzt raus aus diesen Leuten? Das sind dann konkrete Methoden

[5:24] zum Abschluss. Und dann gibt es noch ein paar konkrete Anforderungen an die Anforderungen selbst,

[5:29] wie du die am besten aufschreibst, damit die auch vernünftig umsetzbar sind. Und als Letztes

[5:34] habe ich da noch ein paar Beispiele, wie man konkret Anforderungen dann formulieren kann.

[5:37] Also, ich habe heute eine randvolle Agenda, deswegen würde ich sagen, wir starten einfach

[5:41] mal direkt durch. Aber bevor wir mit den Anforderungen loslegen, fange ich nochmal mit

[5:45] einem anderen Begriff an, und zwar der Qualität. Hast du bestimmt schon mal gehört, benutzt du

[5:50] wahrscheinlich auch öfter mal, hörst du immer mal wieder Qualität, hohe Qualität, niedrige Qualität.

[5:54] Aber was heißt das eigentlich? Und es gibt eine schöne DIN-Norm, beziehungsweise sogar eine ISO-Norm,

[6:00] die man auch wunderbar, zumindest als Softwareentwickler, für die Abschlussprüfung

[6:03] lernen kann. Und darin sind verschiedene Punkte der Softwarequalität aufgeführt.

[6:09] Zu dem Thema werde ich ganz sicher nochmal eine Podcast-Episode aufnehmen, das habe ich mir schon

[6:13] auf meine Liste geschrieben. Das ist ein super wichtiges Thema, kommt ganz oft auch in der

[6:17] mündlichen Prüfung ran, zumindest bei uns im Bereich der Anwendungsentwicklung. Und die ISO-Norm,

[6:21] von der ich spreche, ist die 9126. Und darin sind in einem etwas abstrakteren Modell verschiedene

[6:29] Punkte der Softwarequalität dargelegt. Die kann man alle wunderbar auswendig lernen und erklären,

[6:34] muss man jetzt auch nicht alle. Das sind, glaube ich, über 20 Punkte, gegliedert in sechs Oberpunkte.

[6:39] Dazu gehört sowas wie Änderbarkeit, Benutzbarkeit, Funktionalität, Zuverlässigkeit, Übertragbarkeit,

[6:45] Effizienz. Das waren auch schon die sechs Oberpunkte der ISO. Nur, dass du schon mal

[6:49] weißt, in welche Richtung es geht, da werde ich sicherlich nochmal was zu aufnehmen, habe ich

[6:52] gesagt. Aber was ist überhaupt Qualität? Und wenn man da jetzt mal eine Definition schaut,

[6:57] dann stellt man fest, dass Qualität die Übereinstimmung mit den Anforderungen ist,

[7:01] beziehungsweise der Grad der Erreichung oder der Umsetzung dieser Anforderungen. Und ich mache das

[7:07] immer gerne fest an einem Beispiel, einem Flugzeug. Wenn du jemanden fragst, ob ein Flugzeug von hoher

[7:12] Qualität ist, dann musst du immer schauen, wen fragst du denn und was sind die Anforderungen

[7:17] dieser Person. Überleg mal bei einem Flugzeug, wahrscheinlich, wenn du die meisten Menschen

[7:20] fragst, werden die in Form des Fluggastes dieses Flugzeug bewerten. Also, haben die genug

[7:25] Beinfreiheit? Ist der Sitz direkt am Notausgang? Ist es vernünftiges Essen? Schmeckt der Tomatensaft?

[7:31] Was auch immer. Das ist dann ein qualitativ hochwertiges Flugzeug, wenn das alles gilt.

[7:35] Das alles interessiert aber zum Beispiel den Flugkapitän, also den Piloten, überhaupt nicht.

[7:40] Die Beinfreiheit hinten irgendwo in der Holzklasse interessiert den Piloten nicht,

[7:44] der braucht ganz andere Sachen. Der erwartet von einem qualitativ hochwertigen Flugzeug,

[7:48] dass es einen vernünftigen Autopilot hat, dass es nicht abstürzt vielleicht. Gut,

[7:52] das haben die Kunden hinten auch. Aber vielleicht ganz andere Sachen, sowas wie modernster Stand

[7:57] der Technik oder vernünftige Checklisten, keine Ahnung, Blitzschutz. Ich weiß nicht,

[8:02] was der Pilot sonst noch so haben will. Aber der hat vermutlich ganz, ganz andere Anforderungen

[8:06] an dieses Flugzeug als ein Gast. Von daher werden die beiden vielleicht zu einer sehr

[8:10] unterschiedlichen Aussage über die Qualität des Flugzeugs kommen, weil sie mit ganz anderen

[8:14] Augen drauf gucken und ganz andere Anforderungen haben an dieses Flugzeug. Und genau darum geht es

[8:19] auch bei uns in der IT, wenn wir Projekte umsetzen, dass wir diese verschiedenen Blickwinkel

[8:23] berücksichtigen müssen. Und natürlich sind die alle unterschiedlich priorisiert. Also,

[8:27] was der Pilot sagt, ist vielleicht im Zweifel ein bisschen wichtiger, als was der Malle-Urlauber

[8:31] hinten sagt. Von daher, das muss man natürlich auch immer gewichten und in eine Reihenfolge

[8:35] bringen. Und das ist auch dann dein Job als der, der das Projekt umsetzt. Du sollst deine

[8:40] Ausbildung auch lernen, Projektleitungen zu machen, Projektplanungen zu machen, gerade

[8:43] auch für dein eigenes Projekt. Und da musst du schon entscheiden. Angenommen, du hast

[8:46] zwei konkurrierende Anforderungen. Welche gewinnt denn jetzt? Und da musst du bewerten,

[8:51] vielleicht von welchem Menschen die zum Beispiel gestellt wurde und wer da vielleicht etwas

[8:55] wichtiger ist als der andere. Und da kommen wir jetzt nämlich direkt schon zum Punkt,

[9:00] wer hat denn diese Anforderungen überhaupt aufgestellt? Und ich nehme das mal schon kurz

[9:05] vorweg. Die Leute, die Anforderungen an unser Projekt stellen können, und das kann jede

[9:09] beliebige Person oder eine Personengruppe auch sein, eine Institution. Irgendwer, der

[9:15] an diesem Produkt oder an diesem Prozess des Erstellens dieses Produktes beteiligt ist,

[9:21] das sind Stakeholder. Und da habe ich auch eine schöne Geschichte aus einer Prüfung.

[9:25] Da hat tatsächlich jemand, der kannte das Wort Stakeholder, hat aber Steak vorne nicht

[9:30] S-T-A-K-E geschrieben, wie es eigentlich geschrieben wird, sondern S-T-E-A-K, also wie das Steak,

[9:38] das man auf den Grill legt. Und das war sehr schön in der mündlichen Prüfung. Der war

[9:41] felsenfest davon überzeugt, dass das irgendwas mit einem Steak zu tun hatte, was überhaupt

[9:45] nicht stimmt. Sondern es geht hier um Stakeholder mit A-K-E. Und wenn du Steak direkt auf Deutsch

[9:51] übersetzt aus dem Englischen, dann heißt das sowas wie ein Pfosten oder ein Holzpflock,

[9:55] eine Stange, eine Stütze oder ein Zaunpfahl. Was soll das heißen? Naja, der hat irgendwie

[10:01] einen Pflock in unser Projekt gerammt. Das heißt so nach dem Motto, der hat einen Fuß

[10:06] in der Tür, der will irgendwas von diesem Projekt. Das kommt noch so ein bisschen aus

[10:11] der Goldgräberzeit. Oder die Leute, die früher in den USA unterwegs waren und da nach Gold

[10:16] gestürft haben, die haben da ihren Steak abgesteckt. Das heißt, die haben überall

[10:21] kleine Holzpflöcke reingemacht in die Erde und gesagt, so, das ist mein Gebiet, hier

[10:24] suche ich nach Gold. Und wenn da jemand anders reinkam, dann, naja, weiß ich nicht, was

[10:27] dann passierte. Okay, zurück zum Thema. Also diese Stakeholder, um die soll es gehen und

[10:32] nicht um die Stakeholder im Sinne von Grillmeister. Das ist hier nicht gemeint. Und diese Stakeholder

[10:36] können unterschiedliche Anforderungen an uns stellen. Und wir werden auch gleich nochmal

[10:39] darauf eingehen, wer genau diese Stakeholder sein können. Ich möchte aber vorab nochmal

[10:42] einmal grundsätzlich Anforderungen so ein bisschen unterteilen. Es gibt nämlich zwei

[10:46] verschiedene Arten von Anforderungen. Und zwar die funktionalen Anforderungen und die

[10:51] nicht funktionalen Anforderungen. Und das ist ganz wichtig, denn die sind beide ultra

[10:56] wichtig für unser Projekt. Da müssen wir beide berücksichtigen. Aber vom Umfang her

[10:59] sind die deutlich unterschiedlich. Und zwar, vielleicht eine kurze Erklärung, was das überhaupt

[11:03] ist. Die funktionalen Anforderungen, die beziehen sich direkt auf die zu erbringende

[11:07] Leistung des Produkts. Nehmen wir mal ein Textverarbeitungsprogramm wie Microsoft Word.

[11:11] Wenn der Kunde sagt, ich muss die Möglichkeit haben, hier Text fett zu machen oder kursiv

[11:16] zu setzen, dann ist das direkt eine funktionale Anforderung. Entweder kann es das Programm

[11:20] oder nicht. Die nicht funktionalen Anforderungen beziehen sich auf alles andere, außer diese

[11:26] konkrete Funktionalität. Nehmen wir mal das Beispiel wieder zurück zu Word. Wenn ich

[11:29] den Text fett mache und er wird fett, dann ist das funktional umgesetzt. Wenn das allerdings

[11:34] drei Sekunden dauert, bis der Text fett wird, weil das Programm so langsam ist, dann ist

[11:38] eine nicht funktionale Anforderung vielleicht nicht erfüllt. Nämlich, dass das Programm

[11:41] vernünftig bedienbar sein soll und zwar einer gewissen Geschwindigkeit. Oder wenn

[11:45] ich Word starte und mein PC ratzt ab, weil der 16 GB RAM schluckt für ein fettes Wort,

[11:50] dann habe ich auch eine andere nicht funktionale Anforderung, nämlich zum Beispiel die Speichereffizienz,

[11:54] nicht eingehalten. Und jetzt ist das Interessante, wenn man sich auch diese Qualitätsnormen anguckt

[11:58] bei der Softwarequalität. Es gibt einen Punkt funktionale Anforderungen und dann gibt

[12:03] es gefühlte 27 Punkte nicht funktionale Anforderungen. Also ich übertreibe jetzt vielleicht ein bisschen,

[12:09] das sind aber wirklich über 20. Ich habe die genaue Zahl jetzt gerade nicht im Kopf. Ich

[12:12] meine, als ich das damals mal auswendig lernen durfte, waren es 24 Punkte und eine davon

[12:17] war funktional und 23 waren nicht funktional. Das heißt, alles drumherum, wie schnell ist

[12:22] das Programm, stürzt das ab, ist das fehlertolerant, also sind zum Beispiel Fehlermeldungen sprechend,

[12:27] kann ich das auf beliebigen Betriebssystemen installieren oder nur auf einem. Das sind

[12:31] alles so Beispiele für nicht funktionale Anforderungen und das gibt es nicht nur in

[12:34] der Softwareentwicklung. Ich zitiere ja immer die ganze Zeit diese ISO-Norm, aber das gilt

[12:38] auch für alle anderen Projekte. Also wenn wir ein FISI-Projekt nehmen, kann ich das

[12:43] System, was ich da aufsetze, von heute auf morgen zum Beispiel auf eine neuere Version

[12:46] heben. Ich habe eine Windows 10-Installation, kann ich die einfach hochziehen zum Beispiel.

[12:50] Das ist zum Beispiel etwas, was natürlich interessant ist, auch wenn es für den eigentlichen

[12:53] Betrieb vielleicht irrelevant ist. So, das heißt, für alle unsere Projekte haben wir

[12:58] einen ganzen Haufen nicht funktionale Anforderungen und die müssen wir genauso berücksichtigen

[13:02] wie die funktionalen Anforderungen. Nur leider sind die nicht funktionalen Anforderungen

[13:07] oftmals nicht so einfach zu definieren. Denn wenn ich jetzt einen Fachbereich frage, sag

[13:11] mal, ich will hier eine neue Anwendung programmieren, Textverarbeitung, was soll die denn können?

[13:15] Dann wird der mir sicherlich nicht als erstes sagen, ja, die muss aber besonders schnell

[13:18] sein, also innerhalb von 100 Millisekunden will ich den Text aber sehen, sondern der

[13:21] wird mir genau sowas sagen wie FET, Kursiv, Überschrift, Inhaltsverzeichnis etc., also

[13:26] die funktionalen Sachen. Aber die nicht funktionalen, allein vom Umfang her, sind sie halt viel,

[13:30] viel, viel mehr und im Zweifel tragen sie auch dazu bei, dass der Kunde das Produkt

[13:35] nicht akzeptiert. Wie gesagt, ich kann die beste Textverarbeitung haben, wenn die einfach

[13:38] mega langsam ist, wird kein Kunde die benutzen wollen. Also von daher, beides müssen wir

[13:44] berücksichtigen und manchmal sind die nicht funktionalen oder meistens sind die nicht

[13:48] funktionalen Anforderungen sehr, sehr schwer zu ermitteln, weil das einfach so erwartet

[13:52] wird. Ich erwarte, wenn ich ein Programm starte, dass es nicht abstürzt zum Beispiel, das

[13:56] schreibe ich nicht extra auf. Also von daher, zieht ihr gerne mal diese ISO-Norm rein und

[14:01] guckt ihr diese ganzen nicht funktionalen Bereiche da an, aber wie gesagt, ich mache

[14:04] noch mal eine Episode separat nur dafür. Also funktionale Anforderungen, nicht funktionale,

[14:09] das kennen wir schon, wunderbar. Und jetzt geht es weiter. Jetzt haben wir unsere Stakeholder

[14:13] und die können jetzt fragen, sag mal, was sind denn eure Anforderungen an das neue Produkt,

[14:17] was ich hier schaffen will? Und bitte Produkt, wie gesagt, kann eine Software sein, kann

[14:19] ein Netzwerk sein, was ich installiere, kann ein, ich weiß es nicht, irgendwas sein, was

[14:23] ich löten soll für die Systemelektroniker. Also es ist ganz egal, was wir hier machen

[14:27] als Produkt. Ich gehe mit meinen Beispielen immer auf die Software, weil ich das halt jeden

[14:31] Tag mache, aber es gilt auch für alle anderen Projekte, alle anderen IT-Berufe. Und jetzt

[14:36] ist die Frage, wer sind denn eigentlich alles unsere Stakeholder? Denn ich kann mir vielleicht

[14:41] verschiedene Anforderungen an mein Produkt ausdenken oder ich frage den Kunden, aber

[14:47] reicht das denn? Wen muss ich denn noch fragen? Und ich habe einfach mal nur zum Beispiel eine

[14:52] Liste mitgebracht an möglichen Stakeholdern an unser Projekt. Du kannst ja mal, wenn du ein

[14:57] bisschen mitmachen willst, das habe ich noch nie gemacht im Podcast, aber du kannst es ja mal

[15:01] machen, drück doch mal auf Pause und überleg mal kurz, wer könnte denn ein Interesse an deinem

[15:06] Projekt haben? Und ich gebe mal eine Zahl vor, ich habe zehn Personen oder Personengruppen

[15:11] mitgebracht, die ein Interesse an deinem Projekt haben könnten, die du theoretisch einbeziehen

[15:16] musst bei der Anforderungsermittlung. Natürlich, die Liste ist sehr lang und nicht für alle

[15:22] Projekte sind alle immer wichtig, das ist völlig klar, aber ich will dir mal einen Denkanstoß

[15:26] geben, woran du denken könntest, wenn du jetzt wirklich mal ein größeres Projekt umsetzt. Und

[15:31] vielleicht hast du auch wirklich eine Anregung für dein konkretes Projekt und hast vielleicht

[15:34] eine Gruppe tatsächlich vergessen und dir fällt es jetzt ein, dass du die nochmal befragen musst.

[15:39] Also überleg doch mal kurz, ich habe zehn Gruppen mitgebracht und wenn du jetzt Pause drücken willst,

[15:44] dann mach das mal. Und jetzt geht's los mit den zehn Gruppen. Okay, also ich fange mal ganz vorne

[15:52] an. Eine Gruppe habe ich eben schon selber genannt und zwar der Kunde. Also der Kunde,

[15:56] der das Geld bezahlt am Ende für das Projekt, ich glaube, der hat viel zu melden. Wenn der eine

[16:01] Anforderung hat, dann sollten wir die umsetzen, denn sonst gibt es kein Geld. Also das ist,

[16:04] glaube ich, relativ selbsterklärend. Dann machen wir weiter. Nächste Gruppe, Anwender. Und das

[16:09] muss nicht das Gleiche sein. Ein Kunde kann zum Beispiel ein Unternehmen sein, kaufe eine neue

[16:13] Software bei mir ein. Die Leute, die mit dem Ding dann jeden Tag arbeiten müssen, sind aber vielleicht

[16:18] gar nicht der Kunde, also das Unternehmen, sondern die Mitarbeiter dieses Unternehmens. Und die haben

[16:22] vielleicht ganz andere Anforderungen als der Kunde. Der Kunde will vielleicht, dass es billig

[16:25] ist. Der Anwender will vielleicht, dass es benutzbar ist. Also die Usability ist vielleicht

[16:30] ganz wichtig. Oder die Selbsterklärbarkeit. Oder, dass es eben nicht dreimal am Tag abstürzt. Also

[16:35] die Anforderungen siehst du schon mal hier. Allein beim Kunden und beim Anwender können schon sehr

[16:39] unterschiedlich sein. Dann dritte Gruppe, Management. Auch die haben vielleicht eine

[16:43] Anforderung. Die wollen vielleicht am ehesten noch, dass es günstig ist. Die wollen vielleicht,

[16:48] Gott bewahre, irgendwelche Überwachungsfunktionen haben, um die Anwender zu prüfen, ob die auch

[16:52] schnell genug arbeiten. Sowas werden wir niemals da rein programmieren, keine Frage. Aber nur mal so

[16:56] als Idee. Die haben vielleicht ganz andere Anforderungen. Dann eine meiner Lieblingsgruppen,

[17:00] gerade auch bei uns im Unternehmen, immer müssen wir die berücksichtigen und das ist auch immer

[17:04] wichtig, der Marketingbereich. Die wollen vielleicht, dass das Produkt schön aussieht,

[17:08] dass man das, keine Ahnung, auf Hochglanzfolien toll präsentieren kann, dass bestimmte Farben

[17:13] eingehalten werden. Allein das wird sicherlich für ein Programmierprojekt bei dir gelten. Du

[17:17] musst das Corporate Design deiner Firma einhalten. Du kannst ja nicht einfach selber was ausdenken,

[17:21] zum Beispiel. Also Marketing ganz wichtig. Dann haben wir, wenn wir tatsächlich ein

[17:25] Entwicklungsprojekt haben, die Entwickler natürlich auch mit im Boot. Das gleiche gilt,

[17:29] wenn du ein Adminprojekt machst, natürlich auch für die Administratoren. Also es geht hier nicht

[17:32] nur darum, die Endanwender glücklich zu machen, sondern auch die, die das Produkt entwickeln.

[17:36] Was können die für Anforderungen haben? Die wollen vielleicht eine vernünftige Versionsverwaltung

[17:40] haben. Die wollen eine coole Programmiersprache nutzen. Die wollen bestimmte Frameworks einsetzen.

[17:43] Die wollen Tools, keine Ahnung, wie ein Issue Tracker, wie Jira oder Redmine oder sowas benutzen.

[17:48] Das heißt, die haben ganz andere Anforderungen als das Projekt. Das hat mit der Funktionalität

[17:52] fast gar nichts mehr zu tun. Die gucken mit einem ganz anderen Auge drauf. Nämlich,

[17:55] wie können wir das Produkt vernünftig entwickeln, testen, in den Betrieb bringen?

[17:59] Und wenn wir da schon vom Betrieb reden, eine weitere wichtige Stakeholdergruppe,

[18:04] Support. Denn wenn das Produkt erstmal in Betrieb ist und vielleicht kennst du die Phasen des

[18:10] Produktlebenszyklus. Die längste Phase mit Abstand ist der Einsatz, also der Betrieb des fertigen

[18:16] Produkts. Wenn wir ein Jahr lang eine Software entwickeln und die ist danach 20 Jahre im Einsatz,

[18:21] dann siehst du, dass das der größte Teil des Lebenszyklus ist, diese Software zum Beispiel.

[18:26] Und in dieser Zeit treten vielleicht Fehler auf. Und wer muss die beheben oder wer muss sich darum

[18:30] kümmern? Der Support. Und das sind im Zweifel ganz andere Leute als die Anwender zum Beispiel. Die

[18:36] kriegen halt eine Fehlermeldung, wollen mit dem Ding eigentlich nur arbeiten und rufen dann beim

[18:39] Support an. Und dann geht's los. Wie soll der Support jetzt den Fehler finden? Was braucht

[18:42] der? Der braucht vielleicht ein Logging. Der muss Möglichkeiten haben, sich vielleicht in

[18:46] der Session einzuklinken und sich da was anzugucken. Irgendwelche Debug-Informationen

[18:50] zur Laufzeit sich anzuschauen. Also alles, was den Support bei der Fehlersuche unterstützt,

[18:54] das muss man ja wissen. Das muss man ja einbauen. Ein Programm, was ich schreibe,

[18:58] lockt ja nicht von alleine irgendwas raus. Das muss ich schon programmieren. Und das muss ich

[19:02] wissen, bevor ich anfange damit. So, jetzt kommen wir nochmal zu so ein bisschen allgemeineren

[19:07] Sachen. Und zwar der nächste Punkt Gesetzgeber. Ich komme aus einer Krankenversicherung. Da

[19:13] orientieren wir uns ständig an irgendwelchen Gesetzen, weil der Gesetzgeber sich mal wieder

[19:16] was Neues ausgedacht hat. Und da sind wir verpflichtet dazu, das einzuhalten. Wenn wir

[19:20] in der Krankenversicherung irgendwie zum Beispiel den Datenschutz oder sowas missachten, wow, dann

[19:25] wird uns die Bude zugemacht. Da müssen wir uns dann halten. Ganz einfach. Und das gilt auch für

[19:29] dich. Zum Beispiel Stichwort DSGVO. Da musst du einhalten. Wenn du das nicht machst auf einer

[19:33] Website, kannst du abgemahnt werden. Kannst irgendwann den Laden zumachen. Also Gesetze,

[19:37] alles, was der Staat quasi vorgibt, da halten wir uns besser dran. Auch das sind Anforderungen. Und

[19:43] das sind teilweise sogar sehr harte Anforderungen. Stellen wir uns mal vor, Online-Shop und so,

[19:46] was da die Kunden alles für Auskunftsrechte haben nach DSGVO. Da müssen wir eventuell

[19:50] wirklich richtig intensiv programmieren, um zum Beispiel so eine Datenauskunft überhaupt

[19:55] rausgeben zu können. Um alle Daten über einen Kunden, die wir gesammelt haben, rauszugeben,

[20:00] ja, das ist gar nicht so einfach. Da musst du schon irgendwas vorsehen. Das musst du

[20:03] von Anfang an wissen, sonst wird es ganz schön schwierig am Ende.

[20:07] So, nächster Punkt. Wir sind in der IT und da bauen wir meistens Systeme, die nicht für sich alleine irgendwo stehen, sondern die mit anderen interagieren müssen.

[20:14] Und da wäre für uns ganz wichtig, dass wir uns an Standards halten.

[20:18] Wenn ich einen Webserver aufbaue, dann nehme ich bitte HTTP und HTTPS und denke mir nicht mein eigenes Protokoll aus, zum Beispiel.

[20:24] Wenn ich irgendwie Windows-Freigaben machen will, dann sollte ich vielleicht die eingebaute Funktionalität von Windows benutzen und nicht irgendwie ein Programm schreiben,

[20:32] was über irgendein obskures Netzwerkprotokoll Dateien hin und her transferiert.

[20:35] Dafür gibt es die Standards, damit Systeme miteinander interoperabel funktionieren.

[20:41] Und das ist auch ein Qualitätskriterium übrigens, aber hier extra nochmal als Stakeholder mit aufgeführt. Standards bitte dran halten.

[20:49] Dann vorletzter Punkt, einen habe ich noch, Auditoren.

[20:53] Auch das bringe ich mit aus der Krankenversicherung und auch aus jedem anderen Unternehmen.

[20:57] Da wird es irgendwie mal Audits geben, sei es Wirtschaftsprüfer, die ins Haus kommen oder tatsächlich sogar staatliche Behörden.

[21:02] Bei uns in der Krankenversicherung, da kommt die BaFin und kontrolliert einfach mal, ob wir da alle richtig machen.

[21:07] Und was wollen die dann wissen? Jetzt Wirtschaftsprüfer oder solche anderen Prüfer, die wollen tatsächlich irgendwelche Protokolle sich anschauen.

[21:14] Irgendein rechte Konzept vielleicht. Wer darf was? Vier-Augen-Prinzip.

[21:18] Also wie die Menschen mit dieser Software zum Beispiel arbeiten, die wir da bauen oder mit dem System.

[21:23] Wie sicher ist das? Wie ist der Datenschutz eingehalten? Und so weiter.

[21:27] Und das können wir gegebenenfalls nur liefern, wenn wir solche Sachen auch vorher eingebaut haben.

[21:31] Ich kann jetzt nur mal ein Stichwort nennen, zum Beispiel aus einer Dokumentenverwaltungssoftware.

[21:35] Da gibt es einen Audit-Trail. Das heißt, ich kann genau nachvollziehen, welcher Mitarbeiter hat wann, wie, was für ein Dokument verändert, was hat er draufgeschrieben hat und so weiter.

[21:45] Ich kann mir alte Versionen noch wieder angucken.

[21:47] Das brauche ich alles, wenn ich so eine Nachweispflicht zum Beispiel habe.

[21:52] Und letzter Punkt. Das ist immer einer meiner Lieblingspunkte. Kulturkreis.

[21:56] Auch unser Kulturkreis ist ein Stakeholder.

[21:59] Und ich habe immer ein schönes Beispiel. Farbe.

[22:01] Wir haben eben von Marketing gehört. Marketing sagt, die Oberfläche muss blau.

[22:05] Und wenn ich jetzt so eine Software entwickle, die zum Beispiel weltweit eingesetzt wird, dann muss ich vielleicht vorher mal überlegen, ob die Farbe blau in allen Ländern das bezweckt, was sie soll.

[22:16] Ich nehme mal ein anderes Beispiel, weil ich das weiß.

[22:18] Beziehungsweise ich habe das, glaube ich, mal irgendwo gelesen.

[22:20] In China gilt zum Beispiel die Farbe weiß als Farbe des Todes.

[22:24] Das wäre in Deutschland, glaube ich, nicht so.

[22:26] Da wäre das vielleicht eher schwarz.

[22:28] Und schwarz und weiß sind ja schon mal sehr unterschiedlich.

[22:30] Also von daher, wenn ich eine schöne, weiße, strahlende Oberfläche baue, so Whitespace-mäßig.

[22:35] iPhone, alles weiß.

[22:37] Und ich komme dann in ein fremdes Land, wo das auf einmal so aussieht, als würde ich da irgendwie was für eine Beerdigung produzieren.

[22:43] Dann kommt das vielleicht nicht so gut.

[22:45] Und das ist jetzt nur ein Beispiel.

[22:46] Noch andere Sachen sind natürlich sowas wie Währung gehört dazu.

[22:49] Oder eben auch Sprache von links nach rechts oder von rechts nach links.

[22:53] Wenn ich Software auch für einen arabischen Raum baue, dann muss die auf einmal von rechts nach links lesbar sein.

[22:58] Oder in Japan oder in Korea, wo es diese Schriftzeichen gibt.

[23:02] Wenn ich in Deutschland einen riesen Text habe über drei Absätze, ist das vielleicht in japanischen Schriftzeichen auf einmal nur noch ein Drittel so lang.

[23:09] Auf einmal sieht meine ganze Website, wenn ich dann eine baue, ganz anders aus.

[23:12] Das heißt, das Design muss sich auch entsprechend anpassen, weil die Schrift ganz anders funktioniert.

[23:16] Das sind so Dinge, da denkt man vielleicht gar nicht dran.

[23:18] Wenn man jetzt ein kleines Abschlussprojekt als ITler macht, okay.

[23:21] Aber ich will das ja auch ein bisschen allgemeiner hier formulieren.

[23:23] Und wenn du mal eine Website baust für einen großen weltweit tätigen Konzern, kann ja auch eine Intranet-Anwendung zum Beispiel sein für ein weltweit agierendes Unternehmen.

[23:30] Dann müsstest du darauf achten, dass vielleicht die Sprache in anderen Ländern ein bisschen anders dargestellt wird als in Deutschland.

[23:37] Also, der Kulturkreis ist auch ein wichtiger Stakeholder.

[23:40] Bitte immer mal gucken, wo soll das Ding eigentlich eingesetzt werden, was ich da baue?

[23:43] Und was sind da die Gegebenheiten, an die wir uns vielleicht halten sollen?

[23:48] Gut, bist du auf die Zehn gekommen? Ich weiß nicht.

[23:50] Wir können ja mal gucken.

[23:52] Kunde, Anwender, Management, Marketing, Entwickler, Support, Gesetzgeber, Standards, Auditoren, Kulturkreis.

[23:59] Das waren meine Zehn.

[24:00] Und ich glaube, es gibt noch ein paar mehr.

[24:02] Aber nur als Anregung.

[24:03] Also, denk mal nicht nur an die Leute, wo du weißt, die werden nachher deine Anwendung oder dein System benutzen.

[24:09] Sondern denk auch mal ein bisschen out of the box, wen du eventuell noch fragen musst, wer Anforderungen an dein Projekt hat.

[24:16] Gut, jetzt wissen wir das.

[24:17] Jetzt haben wir zehn Personengruppen, die wir fragen können.

[24:19] Wow.

[24:20] Ich bin mal ganz ehrlich, in so einem klassischen Abschlussprojekt sind das vielleicht nicht ganz so viele.

[24:24] Da sagst du vielleicht so etwas wie, die Software muss so aussehen, wie das CD vorgibt.

[24:28] Also, Corporate Design des Unternehmens.

[24:30] Und damit hast du Marketing schon abgedeckt.

[24:32] Wahrscheinlich wirst du dich eher auf den Kunden oder die Endanwender, vielleicht auch, wenn du zum Beispiel ein System aufsetzt als Physi,

[24:38] vielleicht die anderen Admins, die später damit arbeiten sollen und so konzentrieren.

[24:41] Aber wie gesagt, ich will dir mal einen Denkanstoß geben.

[24:43] Und ganz oft vergisst man Leute und wundert sich dann später, wenn man dann die Software zum Beispiel einführt, dass sich jemand beschwert.

[24:51] Ich nehme mal noch ein Beispiel.

[24:52] Das wäre der elfte Stakeholder, Betriebsrat.

[24:55] Wie oft wir in der mündlichen Prüfung schon Software besprochen haben als Abschlussprojekt.

[24:59] So etwas wie eine Zeiterfassung oder eine Projektplanung.

[25:01] Da hat der Prüfling nicht einmal mit dem Betriebsrat geredet.

[25:04] Aber das ist zustimmungspflichtig, so etwas.

[25:06] Wenn ich zum Beispiel eine Arbeitszeiterfassung einführe, dann muss ich den Betriebsrat fragen.

[25:09] Und da kann ich nicht einfach anfangen, irgendwas zu programmieren, wo ab jetzt jeden Morgen die Mitarbeiter stempeln müssen,

[25:14] ohne vorher zum Beispiel den Betriebsrat ins Boot geholt zu haben.

[25:17] Also, solche Sachen geht gar nicht.

[25:19] Von daher, immer daran denken, habe ich wirklich alle gefragt, die etwas mit meinem Projekt zu tun haben.

[25:25] So, also, jetzt wissen wir, wen wir fragen müssen.

[25:27] Das ist ja schon mal gut.

[25:28] Jetzt ist die Frage, wie fragen wir die denn?

[25:31] Und auch hier kannst du wieder mitraten, wenn du willst.

[25:33] Ich habe zehn Methoden mitgebracht, wie du zu Anforderungen kommst.

[25:37] Also du weißt, du hast da eine Person, sitzen, stehen, was auch immer.

[25:40] Und was hast du jetzt für Möglichkeiten, da die Anforderungen rauszukriegen?

[25:44] Und die erste, die dir wahrscheinlich einfällt, ist Fragen.

[25:47] Das würde ich jetzt über dem Oberpunkt Interview zusammenfassen.

[25:50] Also das dümmste, in Anführungszeichen, was du machen kannst.

[25:52] Hingehen, Fragen.

[25:53] So, das ist logisch.

[25:54] Das ist intuitiv.

[25:55] Ich meine nicht dumm, sondern intuitiv, wollte ich eigentlich sagen.

[25:57] Okay, vielleicht fallen dir ja noch neun weitere Möglichkeiten ein, wie du auf die Anforderungen kommst.

[26:02] Also wenn du willst, kannst du jetzt hier Pause machen.

[26:04] Und dann hören wir uns gleich wieder.

[26:06] Gut, ich habe noch neun mehr.

[26:09] Nummer eins, wenn das Interview nicht funktioniert, weil ihr vielleicht zeitlich getrennt seid, andere Zeitzone, was auch immer.

[26:14] Wenn du ihn nicht direkt fragen kannst, sag ihm doch, schreib mal auf.

[26:18] Und das würde dann einfach Selbstaufschreibung heißen.

[26:21] Relativ simpel, aber vielleicht ist es dir gar nicht eingefallen.

[26:25] Wenn man das etwas strukturierter machen will und nicht einfach sagt, so, hier hast du ein DIN-A4-Blatt, schreib mal auf.

[26:30] Das fällt nämlich vielen Menschen sehr, sehr schwer.

[26:32] Gerade auch Fachmitarbeitern, die haben genau im Kopf, was sie haben wollen, aber sie können es sehr schwer in Worte fassen oder formulieren.

[26:39] Das ist ganz häufig so.

[26:40] Aber die sind einfach nicht geschult.

[26:41] Die sind halt in ihrer Fachlichkeit drin und können das auch super, aber die können das nicht so gut verschriftlichen oder in Wörter fassen.

[26:48] Von daher kannst du ein bisschen unterstützen, wenn du zum Beispiel einen Fragebogen benutzt, wo zum Beispiel bestimmte Sachen vordefiniert sind.

[26:54] So was wie, wie schnell soll denn die Anwendung reagieren?

[26:57] Oder wie wichtig ist ihnen das Layout?

[27:00] Wie wichtig ist ihnen die Maussteuerung oder die Tastatursteuerung?

[27:03] Oder, oder.

[27:04] Da kann man ja ein bisschen was vorgeben und dann wird der Mensch dort vielleicht ein bisschen angeregt und kommt dann auch auf Sachen, auf die er sonst gar nicht gekommen wäre.

[27:13] Ja, nächster Punkt.

[27:14] Wenn wir so gar keine Ahnung haben und wir wollen mal völlig offen rangehen, dann können wir uns mit mehreren Leuten zusammensetzen und dann machen wir ein Brainstorming.

[27:21] Alle schmeißen mal Ideen rein.

[27:23] Wichtigste Regel beim Brainstorming kennst du hoffentlich, es gibt keine Kritik.

[27:27] Das heißt, egal was genannt wird, es wird alles aufgeschrieben.

[27:30] Und das führt dazu, dass wir ganz viele coole Anforderungen wahrscheinlich definieren, an die wir sonst gar nicht gedacht hätten.

[27:35] Einfach als Kreativitätstechnik ist das eine tolle Sache, wenn man überhaupt noch nichts hat und anfangen will, ist so ein Brainstorming echt super gut geeignet.

[27:44] Nächste Methodik geht auch so ein bisschen in die Richtung einer Kreativitätstechnik Mindmapping.

[27:48] Auch das kann man machen.

[27:50] Sich so ein bisschen strukturiert von einem Ausgangspunkt, am besten dem Projekt in der Mitte, loshangeln und so ein paar Äste aufmalen, wie so ein Baum, und immer weiter verschachteln.

[27:58] Also, was weiß ich, ihr soll einen neuen Server aufsetzen.

[28:00] Dann habe ich vielleicht die Frage, welches Betriebssystem, welche Internetanbindung, keine Ahnung, Dauer der Lauffähigkeit oder keine Ahnung, Ausfallsicherheit oder was auch immer mir da einfällt.

[28:10] Und das kann ich dann immer weiter verschachteln und immer weiter vertiefen und so komme ich vielleicht auch noch auf neue Anforderungen.

[28:15] So, das waren schon fünf. Jetzt machen wir weiter.

[28:18] Wenn ich vielleicht ein System habe, was es schon gibt und ich soll das ablösen oder verbessern oder sonst was, dann könnte ich mich einfach mal als Azubi quasi neben einen Mitarbeiter setzen und gucken, was er den ganzen Tag macht.

[28:30] Und wenn man das dann mit so einem fancy englischen Begriff bezeichnen will, könnte ich das Apprenticing nennen.

[28:35] Apprentice, kennst du vielleicht, das ist quasi das englische Wort für Azubi, passt nicht so hundertprozentig, aber Apprenticeship ist so das englische Wort, was am besten auf die deutsche Ausbildung eigentlich passt.

[28:44] Und das bedeutet einfach, du setzt dich daneben und das gilt jetzt nicht nur für deinen Abschlussbericht, weil du da ja noch Azubi bist, sondern auch später.

[28:51] Du kannst dich einfach neben den Anwender setzen und mal gucken, was macht er denn so und so tun, als wärst du der Azubi.

[28:57] Das heißt, der soll dir sagen, mach mal die und die Aufgabe und der zeigt dir dann, wie das in dem System funktioniert.

[29:03] Und du gehst bei dem quasi in die Lehre, in die Ausbildung und guckst dir das mal an.

[29:07] Und dabei wirst du ganz viel Fachlichkeit wahrscheinlich lernen, denn wenn zum Beispiel der Kollege einfach sagt, klicke jetzt mal da und mach das und das und da trägst du 23 in das Feld ein.

[29:16] Dann ist deine Aufgabe zu fragen, warum? Wo kommt die 23 her? Was ist das für ein Wert? Was heißt denn das?

[29:22] Und so kommst du immer tiefer in die Fachlichkeit und verstehst es dann hoffentlich auch irgendwann, was da eigentlich zu tun ist und kannst daraus dann die Anforderungen ableiten.

[29:30] So, wenn du das jetzt nicht ganz so invasiv machst, also nicht so in die Interaktion gehen willst, sondern dich einfach wirklich stumpf auf dem Stuhl daneben setzt und zuguckst, dann könnte man das als Feldbeobachtung auch als eine weitere Methode benennen.

[29:42] Ist im Prinzip mehr oder weniger dasselbe. Du guckst dir an, wie Leute arbeiten, aber einmal bist du ein bisschen aktiver und machst selber mit.

[29:48] Ich gehe in die Ausbildung Apprenticing und einmal guckst du wirklich als externer Beobachter zu. Das ist dann die Feldbeobachtung.

[29:54] Dann habe ich noch einen, der relativ häufig benutzt wird, gerade zu Beginn eines Projekts und zwar ein Workshop.

[30:00] Wir setzen uns alle mit vielen Stakeholdern zusammen an einen Tisch und diskutieren einfach mal. Fang mal an. Erarbeiten mal was. Schreiben vielleicht gemeinsam das Lastenheft auf.

[30:09] Also wirklich mit mehreren Leuten gemeinschaftlich daran arbeiten in Form eines Workshops.

[30:14] So, da habe ich noch zwei schöne. Wenn wir ein altes System ablösen wollen, wenn es da schon was gibt.

[30:20] Das ist natürlich für uns als Entwickler zum Beispiel immer schön. Wir können einfach gucken, was macht das Alte, programmieren das nach, bin fertig.

[30:26] Ja, so schön wäre es. Das funktioniert natürlich auch ganz häufig nicht. Aber wenn ich das mache, dann brauche ich auch einen schönen Namen dafür.

[30:32] Und das könnte man Systemarchäologie nennen. Das heißt, ich gucke mir das alte, das uralte System an und schaue, was kann das denn.

[30:41] Und schon habe ich meine Anforderungen für das neue System. Ergänzen natürlich um alles, was nicht so gut funktioniert, was besser laufen soll, keine Frage.

[30:47] Aber anhand des alten Systems kann man viel ableiten.

[30:50] Ja, und letzter Punkt. Tatsächlich, manchmal hilft es auch, wenn man einfach rät.

[30:56] Das heißt, ich überlege mir, was könnte denn der Fachbereich wollen. Was könnte denn der Anwender am Ende mit der Anwendung machen wollen.

[31:03] Also einfach mal drauf losraten und gucken, was bei rumkommt.

[31:08] Gut, das waren jetzt zehn Möglichkeiten, um an Anforderungen zu kommen. Ich fasse nochmal zusammen.

[31:12] Interview, Selbstaufschreibung, Fragebogen, Brainstorming, Mindmapping, Apprenticing, Feldbeobachtung, Workshop, Systemarchäologie und Raten.

[31:24] Das waren auch nochmal zehn Stück, die dir vielleicht ein bisschen Anregung geben.

[31:27] Denn ja, oft ist es gar nicht so einfach für dein Abschlussprojekt zum Beispiel, die Leute alle zu fassen zu kriegen und direkt mit den Leuten zu reden.

[31:34] Da musst du vielleicht auch mal eine Mail schreiben und fragen, was die wollen. Und schwupp, ist das eine Selbstaufschreibung und so weiter.

[31:40] So, Wahnsinn. Jetzt wissen wir, was Anforderungen sind, wie die sich gliedern lassen.

[31:44] Dann wissen wir, wem wir fragen müssen nach Anforderungen. Das sind unsere Stakeholder.

[31:47] Und jetzt haben wir auch noch zehn Methoden, wie wir die Anforderungen aus den Leuten rauskriegen.

[31:50] Das ist ja Wahnsinn. Da können wir fast direkt loslegen.

[31:53] Aber ganz so einfach ist es dann doch nicht, denn wir haben auch noch Anforderungen an diese Anforderungen.

[31:59] Die sollten nämlich bestimmt formuliert sein, damit wir als Umsetzer nachher auch was damit anfangen können.

[32:04] Es gibt nämlich nichts Schlimmeres, als wenn ein Benutzer zum Beispiel sagt, ich hätte gerne, dass die Anwendung intuitiv bedienbar ist.

[32:11] Und da drehe ich auch immer völlig durch, wenn ich das zum Beispiel in Lastenheften von Prüflingen sehe.

[32:16] Und das schreiben sehr viele, sehr häufig. So Standardsätze wie, muss dem Corporate Design der Firma entsprechen und soll intuitiv bedienbar sein.

[32:25] Und das sind so Anforderungen, wo ich mir denke, Leute, das kann nicht euer Ernst sein, denn das ist absolut unkonkret.

[32:30] Was heißt das intuitiv bedienbar? Das kann dir kein Mensch definieren. Das muss viel genauer sein.

[32:36] Und da wollen wir uns jetzt mal angucken, welche Anforderungen es an diese Anforderungen gibt, damit wir die auch verstehen als Entwickler zum Beispiel.

[32:44] Wenn ich jetzt zu einem Entwickler gehe und sage, hier kommt die Anforderung vom Fachbereich.

[32:47] Macht die Anwendung mal intuitiv bedienbar. Dann sagt der, keine Ahnung, was ich machen soll.

[32:53] Was heißt das intuitiv bedienbar? Wenn ich von links nach rechts scrolle, wird irgendwas größer oder kleiner oder soll ich überhaupt die Maus benutzen?

[33:00] Tastatur soll alles auf Deutsch, Englisch übersetzt werden, damit es intuitiv bedienbar ist.

[33:04] Also was heißt intuitiv bedienbar? Kann kein Mensch verstehen.

[33:07] So, damit wir nicht solche Probleme kriegen, gehen wir jetzt mal so ein paar Anforderungen durch.

[33:12] Auch hier kannst du mal wieder mitraten. Ich habe acht Stück mitgebracht. Acht Anforderungen an Anforderungen.

[33:17] Vielleicht fallen dir ein paar ein. Mach gerne Pause. Denk mal nach.

[33:20] Und jetzt gucken wir uns das Ganze als Ergebnis an.

[33:24] Nummer 1. Anforderungen an Anforderungen. Die müssen eindeutig sein. Also nicht mehrdeutig, also keinen Interpretationsspielraum bieten.

[33:34] Wenn ich sowas sage, wie die Oberfläche könnte blau oder rot oder vielleicht auch gelb sein, dann habe ich als Entwickler oder Umsetzer ja die Wahl.

[33:42] Und wenn der Endanwender am Ende dann doch sagt, eigentlich hätte ich doch lieber gelb gehabt, dann war es halt nicht eindeutig genug.

[33:48] Und der, der es umsetzt, wusste halt nicht genau, was er tun soll.

[33:51] Das ist schlecht, denn dann weiß ich auch am Ende gar nicht, ob ich es jetzt richtig gemacht habe oder nicht.

[33:55] Wenn ich die Wahl habe zwischen mehreren Alternativen, tja, ist ja alles richtig, oder?

[34:00] Gut, dann machen wir weiter. Atomar.

[34:02] Ganz wichtig ist, dass die Anforderung nicht weiter teilbar ist. Das bedeutet ja atomar.

[34:07] Genau wie aus der Datenbank kennst du auch, atomare Werte sollte es nur geben in der ersten Normalform.

[34:12] Einfach, weil sich dann Werte nicht mehr aufteilen lassen in verschiedene.

[34:15] Wie zum Beispiel die Adresse in Straße und Postleitzahl.

[34:18] Das sollte auch für Anforderungen gelten. Ich will die nicht mehr unterteilen können.

[34:22] Warum? Warum muss das so sein?

[34:24] Ja, angenommen, ich habe zwei Anforderungen in einer versteckt.

[34:28] So, keine Ahnung. Angenommen, die Anwendung soll fetten Text ermöglichen und kursiven Text.

[34:34] Bleiben wir wieder bei unserer Word-Anwendung.

[34:37] Was ist denn jetzt, wenn ich den fetten Text implementiert habe, aber den kursiven Text nicht?

[34:41] Dann ist die Anforderung ja nicht erfüllt, weil die Hälfte der Anforderung ist ja nicht umgesetzt.

[34:46] Aber was ist jetzt, wenn die kursive Anforderung sich einfach gar nicht umsetzen lässt, aus welchem Grund auch immer?

[34:50] Dann ist die gesamte Anforderung nicht umgesetzt.

[34:53] Muss der Kunde jetzt dann nicht zahlen, weil die Anforderung ist ja nicht fertig.

[34:57] Das ist schwierig.

[34:58] Also von daher, eine Anforderung muss einen einzigen Punkt enthalten und nicht mehrere,

[35:04] damit ich genau entscheiden kann, ist das jetzt umgesetzt oder nicht.

[35:07] Und dann sind wir automatisch beim nächsten Punkt, nämlich klein.

[35:11] Atomar heißt ja schon nicht weiter teilbar.

[35:13] Atom ist so das Kleinste, was es gibt, wenn man jetzt mal von Quarks und so weiter absieht.

[35:18] Aber lange Zeit waren die ja nicht teilbar, die Atome.

[35:20] Und das heißt automatisch, dass die Anforderungen klein sind und nicht riesengroß.

[35:24] Also eben genau nicht sowas wie, absolut unspezifisch, soll intuitiv bedienbar sein,

[35:29] sondern vielleicht, was könnte da jetzt ein konkretes Beispiel sein,

[35:32] wenn ich mit der Maus über die Eingabebox hoverre, soll da als Tooltipp stehen, was ich da eingeben muss.

[35:40] So, das wäre vielleicht eine konkrete Beschreibung der Hilfe.

[35:43] Und das müsste ich jetzt vielleicht sogar runterbrechen für jedes einzelne Eingabefeld.

[35:47] Dann müsste ich also sagen, hier da, wo der Vorname steht, wenn ich da mit der Maus drüber hoverre,

[35:51] soll da stehen, der Vorname des Kunden.

[35:54] Das wäre eine atomare, eindeutige, kleine Anforderung, die ich dann umsetzen kann.

[36:00] Warum soll die klein sein? Was bringt mir das?

[36:03] Naja, irgendwer muss diese Anforderungen ja umsetzen.

[36:06] Und dann kommen wir gleich zum nächsten Punkt.

[36:08] Die müssen nämlich meistens geschätzt werden.

[36:10] Und das musst du ja zum Beispiel auch in deiner Projektplanung machen.

[36:12] Du sagst, Mensch, ich muss hier was programmieren, dafür brauche ich 42 Stunden.

[36:16] Oder Mensch, ich muss hier einen Windows-Server installieren, das dauert drei Stunden.

[36:20] Und das musst du vorab schätzen, um zu gucken, ob du die Zeit einhältst.

[36:23] Und je größer die Anforderung ist, umso schwieriger ist es, das zu schätzen.

[36:27] Wenn du jetzt mal das Beispiel vom Tooltipp, den du eben anguckst,

[36:30] für ein Feld, ein Tooltipp mit diesem Text zu definieren,

[36:33] da kannst du, wenn du ein bisschen Entwicklungserfahrung hast, genau sagen,

[36:36] okay, das dauert zweieinhalb Stunden.

[36:38] Wenn aber sowas steht wie, mach die Anwendung intuitiv bedienbar,

[36:41] dann hast du überhaupt gar keine Ahnung, wie lange das dauert,

[36:43] weil du gar nicht genau weißt, was alles zu tun ist.

[36:45] Das heißt, die Anforderung muss klein sein und dadurch wird sie automatisch schätzbar.

[36:50] Und das ist eben ganz wichtig für die Projektplanung,

[36:52] damit du überhaupt weißt, ob du das Projekt bis zum gegebenen Termin überhaupt umsetzen kannst.

[36:57] So, dann wäre es noch ganz wichtig, dass die Anforderungen unabhängig voneinander sind.

[37:04] Denn sonst bist du in GA1 der schriftlichen Prüfung für Anwendungsentwickler

[37:09] und zeichnest irgendwelche Netzpläne, denn Anforderungen, die voneinander abhängen

[37:12] und in einer gewissen Reihenfolge umgesetzt werden müssen und so weiter,

[37:14] das ist immer ganz besonders schwierig für die Planung.

[37:17] Am schönsten wäre es, wenn deine Anforderungen nichts miteinander zu tun haben

[37:20] und du völlig losgelöst an den verschiedenen Anforderungen gleichzeitig arbeiten kannst.

[37:25] Das wäre super, weil du dann einfach keine Abhängigkeiten hast,

[37:28] die die Projektplanung erschweren.

[37:30] Du musst nicht immer im Kopf haben, was zuerst gemacht werden muss, was danach

[37:33] und wenn das nicht funktioniert, geht das andere nicht und so weiter.

[37:36] Das wäre super, wenn die nicht abhängig voneinander wären.

[37:41] So, nächster Punkt, den wir noch behandeln sollten.

[37:44] Die Anforderungen sollten auch nützlich sein.

[37:46] Die Anforderungen sollten irgendwas bringen.

[37:48] Das heißt, es sollte nicht einfach irgendwas, weil ich gerade Lust habe,

[37:51] irgendwie was Ausgedachtes sein, sondern es sollte einen Mehrwert bieten.

[37:54] Und da habe ich ein schönes Beispiel aus meiner eigenen Praxis.

[37:57] Ich hatte wirklich mal die Anforderung aus dem Fachbereich,

[38:00] wo ich eine Anwendung entwickelt habe, wo dann die Anforderung kam,

[38:03] der Hintergrund der Anwendung soll bitte rosa sein.

[38:06] Da habe ich mich gefragt, warum soll der rosa sein?

[38:09] Was ist da denn jetzt los?

[38:11] Und dann habe ich mal hinterfragt, ob das denn nützlich ist.

[38:14] Sollte das wirklich rosa sein, weil die Dame, in diesem Fall war es tatsächlich eine Dame,

[38:18] das einfach schön fand oder was war der Hintergrund?

[38:21] Und als ich dann tatsächlich mal angerufen habe und gefragt habe,

[38:24] was ist da denn los? Da war die Antwort einfach,

[38:27] ich bin die ganze Zeit auf einer Testumgebung und der Produktionsumgebung unterwegs

[38:30] und ich würde gerne die Produktionsumgebung rosa machen,

[38:33] damit ich genau weiß, wenn ich da was eingebe, muss ich aufpassen.

[38:36] Wenn ich hier auf Löschen drücke, dann lösche ich echte Kunden

[38:39] und das darf natürlich nicht passieren.

[38:41] Also das heißt, der Hintergrund war, es ging nicht um die Farbe,

[38:44] sondern es ging darum, die Produktionsumgebung deutlich hervorzuheben,

[38:47] damit man keine Fehler macht.

[38:49] Und das war die eigentliche Anforderung.

[38:52] Geäußert in Form der Farbe, weil der Fachbereich sich halt gedacht hat,

[38:56] so ist es am offensichtlichsten, wenn es rot ist, springt es mir ins Auge,

[38:59] ich kann keine Fehler machen.

[39:01] Jetzt mal im übertragenen Sinne.

[39:03] Und das fand ich ein super Beispiel für diese Nützlichkeit der Anforderung.

[39:06] Und so könnte ich es dann aber ein bisschen umformulieren,

[39:08] weil es war technisch einfach gar nicht möglich, das in der Farbe zu machen.

[39:11] Es war so eine Altanwendung.

[39:13] Das heißt, wir mussten es anders lösen und dann konnten wir zum Beispiel,

[39:15] ich weiß nicht, den Text ein bisschen fett machen oder irgendwas blinken lassen

[39:18] oder sonst irgendwas, damit einem das trotzdem ins Auge springt.

[39:21] Denn wenn du jetzt so eine harte Anforderung hast,

[39:23] Fachbereich sagt, das muss aber rot.

[39:25] Und du bist aber in einer Anwendung, wo du gar nicht mit Farben arbeiten kannst,

[39:27] was weiß ich, eine Konsolenanwendung oder sowas,

[39:29] und du kannst diese Anforderung nicht umsetzen,

[39:31] ja, dann stehst du blöd da.

[39:33] Das heißt, frag mal nach, was wirklich der Nutzen dieser Anforderung ist.

[39:37] Und dann kannst du vielleicht auch Alternativen vorschlagen,

[39:39] die technisch dann auch wirklich umsetzbar sind.

[39:42] So, und Stichwort umsetzbar,

[39:44] das ist gleich der nächste Punkt dieser Anforderung.

[39:47] Nämlich, die müssen testbar sein.

[39:50] Du musst eindeutig sagen können,

[39:52] ob du die Anforderung umgesetzt hast oder nicht.

[39:54] Angenommen die Anforderung wäre,

[39:56] der Hintergrund muss rosa sein,

[39:58] wenn du die Anwendung aufmachst und die hat einen blauen Hintergrund,

[40:00] dann ist die Anforderung nicht umgesetzt.

[40:02] Das heißt, der Test schlägt fehl

[40:04] und der Kunde muss das Geld nicht bezahlen, auf Deutsch gesagt.

[40:07] Von daher, überleg dir immer gleich bei den Anforderungen,

[40:10] wie kannst du denn nachweisen, dass du es auch umgesetzt hast.

[40:13] Also wenn da jemand sagt, das System muss aber schnell sein,

[40:17] dann ist schnell etwas, was du nicht umgesetzt hast.

[40:21] belegen kannst. Wenn du zum Beispiel unter schnell verstehst 500 Millisekunden

[40:24] Reaktionszeit und der Kunde ist aber gewohnt, im Echtzeitumfeld zu arbeiten,

[40:28] wo er eine Millisekunde braucht, dann ist das schon ein gewaltiger Unterschied.

[40:32] Das heißt, diese Anforderung ist einfach schlecht formuliert.

[40:34] Die ist so nicht testbar.

[40:35] Stattdessen müsste da sowas stehen.

[40:37] Wenn ich einen Kunden öffne, muss die Maske in 120 Millisekunden angezeigt werden.

[40:42] So, das ist eindeutig messbar und somit testbar.

[40:46] Und dann kann der Kunde sagen Ja oder Nein.

[40:48] Aber es kann nicht zu irgendwelchen Diskussionen kommen, weil Dinge unterschiedlich

[40:51] interpretiert werden. Also gleich mit dazuschreiben zur Anforderung, wie man feststellen

[40:56] kann, dass sie auch umgesetzt wurde.

[40:58] So, letzter Punkt, das ist jetzt die Überleitung zum nächsten Thema.

[41:02] Die Anforderungen sollten einheitlich aufgeschrieben werden oder formuliert werden.

[41:08] Es geht bei unseren Anforderungen nicht darum, dass wir einen Prosa Text schreiben, einen

[41:12] schönen Roman, der sich blumig liest, sondern Anforderungen sollen langweilig sein.

[41:16] Anforderungen sind immer gleich aufgebaut, gleicher Satzbau, gleiche, keine Ahnung,

[41:21] Dinge an der gleichen Stelle.

[41:23] Einfach, weil wir hier meistens eine Riesenliste an Anforderungen haben und wir nicht

[41:27] jedes Mal wieder darüber nachdenken wollen, was denn jetzt hier wohl gemeint ist.

[41:30] Wer ist denn hiervon betroffen?

[41:31] Wie wichtig ist das? Was ist das?

[41:33] Wie ich es messen kann? Etc.

[41:34] Wenn ich einen immer gleichen Aufbau der Anforderung habe, ist das alles automatisch

[41:39] abgedeckt. Und ich muss, wenn ich als Umsetzer mir die Anforderung angucke, nicht jedes

[41:43] Mal neu überlegen, was denn vielleicht gemeint sein könnte, wo ich was finde, wo

[41:47] was, keine Ahnung, die Priorität steht und so weiter.

[41:50] Das heißt, es wäre sinnvoll, wenn wir Anforderungen so einheitlich wie möglich

[41:56] definieren, um eben keine Zeit zu verlieren bei der Interpretation.

[41:59] Dafür haben sich jetzt einige Methoden etabliert, die man in der Praxis häufig

[42:04] anwendet, um Anforderungen zu definieren.

[42:06] Und die möchte ich als nächstes durchgehen.

[42:08] Allerdings noch mal ein kurzer Recap.

[42:10] Was für Anforderungen an Anforderungen haben wir jetzt?

[42:13] Ich habe acht Stück mitgebracht.

[42:15] Eindeutig, atomar, klein, schätzbar, unabhängig, nützlich, testbar, einheitlich.

[42:23] Das waren meine acht. Vielleicht gibt es noch mehr.

[42:25] Ich glaube, mir reichen die auf jeden Fall.

[42:27] Aber wenn wir uns jetzt einige konkrete Maßnahmen angucken, um Anforderungen zu

[42:31] formulieren, werden wir einige dieser Punkte da auf jeden Fall wiederfinden und sehen,

[42:34] dass das einen Sinn hat, dass man sich daran orientiert.

[42:37] Diese konkreten Methoden, die ich mitgebracht habe, das sind einmal die

[42:40] sogenannten Snow Cards, dann habe ich User Stories und das Moskau-Prinzip.

[42:46] Es gibt noch ganz viele andere Möglichkeiten, aber ich habe mir die

[42:49] dreimal rausgepickt, weil ich die auch sehr häufig tatsächlich in

[42:51] Projektdokumentationen sehe von Prüflingen.

[42:54] Und ich finde die auch eigentlich ganz gut, sind schnell erklärt und gut

[42:56] verständlich. Und deswegen gehen wir die mal durch.

[42:59] Ich fange mal an mit dem absoluten Overkill.

[43:01] Das sind die sogenannten Snow Cards.

[43:03] Die kommen aus dem Volere-Template.

[43:05] Das Ding ist schon zig Jahre alt und perfekt ausgearbeitet.

[43:08] Das ist so ein Template, wo sich mal jemand hingesetzt hat und überlegt hat,

[43:11] was könnte es alles für Anforderungen an ein Projekt geben?

[43:14] Und das ist so ein Ding, wo das Inhaltsverzeichnis mit den Überschriften

[43:18] irgendwie schon drei, vier Seiten lang ist.

[43:20] Und das sind alles nur Oberpunkte, um mögliche Anforderungen herauszufinden.

[43:25] Und ich mache mal nur ein Beispiel an etwas, woran du vielleicht noch nie gedacht hast.

[43:28] So physikalische Umgebung deines Produktes könnte in bestimmten Projekten wichtig sein.

[43:34] Angenommen, du sollst als Physi irgendwie einen Server installieren.

[43:38] Wenn du jetzt weißt, dass der in der Forschungsstation in der Arktis stehen wird,

[43:42] dann solltest du vielleicht daran denken, dass das Ding auch bei Minusgraden funktioniert.

[43:47] Und das ist vielleicht nicht ganz so offensichtlich, wenn du das nicht weißt im Vorfeld.

[43:51] Das ist nur ein Beispiel.

[43:52] Es gibt noch viele weitere Punkte in diesem Template.

[43:55] Es ist also ungelogen, das Inhaltsverzeichnis ist mehrere Seiten lang,

[43:58] an was man alles denken könnte bei solchen IT-Projekten.

[44:03] Und das Ding will ich jetzt aber nicht im Detail durchgehen,

[44:05] weil da kann man das ist wirklich für Großprojekte,

[44:07] da kann ich mich Jahre beschäftigen, nur diese Anforderungen aufzunehmen.

[44:09] Das führt aber sehr selten zum Erfolg.

[44:12] Stattdessen wollen wir das vielleicht etwas agiler machen und etwas kürzer und knackiger.

[44:17] Und du kannst diese diese Snow Cards oder Volere Cards mal online angucken.

[44:21] Da sind tatsächlich Felder für alle diese Punkte,

[44:24] die ich gerade genannt habe, der Anforderungen an Anforderungen drin.

[44:27] Eindeutigkeit zum Beispiel.

[44:28] Jede Anforderung bekommt eine ID, schätzbar.

[44:31] Es steht direkt auf der Karte drauf, wie lange ich brauche zum Beispiel.

[44:35] Unabhängig.

[44:35] Es gibt Felder für Vorgänger, Nachfolger, Konflikte etc.

[44:40] Testbar.

[44:40] Es steht direkt drauf in der Anweisung, wie ich testen kann,

[44:43] dass das Ding umgesetzt wurde und eine Einheitlichkeit auch,

[44:45] weil die Karten sehen immer gleich aus.

[44:47] Also alle diese Punkte sind quasi mit diesem Template umgesetzt.

[44:52] Aber es ist einfach mega aufwendig, die alle aufzuschreiben.

[44:56] Ich habe es tatsächlich mal in einem Projekt gemacht.

[44:58] In einem Studentenprojekt haben wir für eine Anwendung

[45:00] wirklich solche Karten aufgeschrieben, alle diese Punkte ausgefüllt.

[45:03] Wir hatten, glaube ich, 60 Anforderungen.

[45:04] Ich weiß nicht, wie viele Stunden wir darin gesessen haben,

[45:07] diese Karten auszufüllen.

[45:08] Man muss dann wirklich für jede Anforderung genau so eine ID vergeben.

[45:12] Okay, das kann so ein System.

[45:13] Aber diese Testbarkeit aufschreiben, diese ganzen Sachen einhalten.

[45:16] Das heißt, wir haben wirklich sehr, sehr viel Zeit reingesteckt.

[45:19] Und ganz ehrlich, am Ende hat da kein Mensch mehr reingeguckt.

[45:21] Das war einfach für die Halde produziert.

[45:24] Und meistens ist es ja auch so, Software und auch IT allgemein.

[45:28] Heutzutage arbeiten wir eher agil, genau vor dem Hintergrund,

[45:32] dass diese ewig lange Planungsphase sowieso meistens für die Katze ist,

[45:36] weil am Ende doch keiner mehr drauf guckt oder sich einfach während der Arbeit

[45:39] schon die ganzen Anforderungen geändert haben.

[45:41] Ich habe mal irgendwo eine schöne Zahl gehört,

[45:43] dass sich in einem IT-Projekt oder allgemein in Projekten

[45:46] in einem Monat ungefähr zwei Prozent der Anforderungen verändern.

[45:51] Was bedeutet das?

[45:53] Ganz extrem zum Jahreswechsel gibt es ein neues Gesetz.

[45:56] Das heißt vielleicht andere Anforderungen kommen in mein Projekt rein

[45:58] oder Sachen, von denen ich ausgegangen bin, sind auf einmal anders.

[46:02] Oder der Kunde entscheidet sich um, will jetzt doch nicht mehr grün,

[46:05] sondern rot haben.

[46:06] Oder es gibt eine neue Marketingstrategie

[46:07] und auf einmal muss alles auf Englisch gemacht werden statt auf Deutsch.

[46:10] Oder, oder, oder.

[46:11] Und im Durchschnitt zwei Prozent der Anforderungen pro Monat.

[46:14] Das heißt, nach einem Jahr kann ich einen Viertel meiner Anforderungen

[46:18] schon mal wegschmeißen oder neu machen.

[46:20] Oder es hat sich alles geändert.

[46:21] Also das heißt, je länger ich für diese Planung brauche,

[46:24] umso größer ist die Wahrscheinlichkeit, dass ich die Hälfte davon wegschmeißen kann,

[46:27] weil sich alles geändert hat in der Zwischenzeit.

[46:29] Von daher wollen wir gerade in der Softwareentwicklung

[46:31] schneller etwas Sichtbares produzieren, um diese Anforderungen zu überprüfen.

[46:35] Und wenn sich die Anforderungen ändern, reagieren wir flexibel darauf

[46:38] oder eben agil in diesem, um das Wort zu benutzen,

[46:42] und planen aber uns nicht Ewigkeiten zu Tode quasi,

[46:46] bevor wir endlich mal was auf die Straße bringen.

[46:48] Und in dem Projekt war das halt eben genauso.

[46:50] Ganz viel Zeit investiert.

[46:52] Und am Ende hatte sich eh die Hälfte davon erübrigt.

[46:56] Und ja, wir haben das ganz umsonst gemacht.

[46:58] Also die Zeit hätten wir uns sparen können.

[47:00] Aber von dieser Karte finde ich noch eine Sache ganz cool.

[47:02] Und die würde ich gerne hier noch einbringen.

[47:04] Und zwar, wenn man sich die Karten mal anguckt,

[47:06] da gibt es so zwei Bereiche, die man mit Punkten bewerten kann.

[47:09] Und zwar die Customer Satisfaction und die Customer Dissatisfaction.

[47:14] Also einmal die Zufriedenheit des Kunden mit dieser Anforderung

[47:18] und aber auch noch mal zusätzlich die Unzufriedenheit des Kunden

[47:21] mit dieser Anforderung.

[47:22] Und das fand ich damals so interessant.

[47:24] Und ich glaube, das finde ich auch.

[47:25] Ja, ich finde es auch heute noch interessant.

[47:26] Deswegen erzähle ich es hier.

[47:27] Warum soll man das unterschiedlich bewerten?

[47:30] Also du kannst dir das so vorstellen.

[47:31] Es gibt einen Punkt Kundenzufriedenheit.

[47:33] Den kannst du bewerten, was weiß ich, von 1 bis 5.

[47:35] 5 heißt, er ist super zufrieden und 1 heißt, er ist nicht so gut zufrieden.

[47:39] Und das Gleiche gibt es noch mal für die Unzufriedenheit.

[47:42] Jetzt kann man sich halt fragen, was soll das Ganze?

[47:43] Und die Idee ist jetzt, dass es Anforderungen gibt,

[47:45] die den Kunden, wenn ich sie umsetze, super zufrieden machen.

[47:48] Da kriegt er vielleicht eine 5.

[47:50] Und wenn ich die nicht umsetze, interessiert es ihn aber nicht.

[47:53] Und das ist genau so etwas, was ich mit dieser,

[47:55] mit diesen beiden Skalen dann darstellen kann.

[47:57] Angenommen, ich setze es um, kriegt er eine 5 für Zufriedenheit.

[47:59] Er freut sich total, dass ich es umgesetzt habe.

[48:01] Aber wenn ich es nicht umsetzen würde, wäre er mir auch nicht böse.

[48:05] Das sind so diese nice to have Features.

[48:07] So keine Ahnung.

[48:09] Der Text soll fett und kursiv sein.

[48:10] Ja, das ist eine Standardanforderung.

[48:12] Wenn das funktioniert, ja, ist ganz nett.

[48:15] Wenn es nicht funktioniert, haut es mir aber um die Ohren.

[48:17] Das wäre genau das Gegenteil.

[48:19] Das heißt, Customer Satisfaction wäre gering, wenn ich es umsetze,

[48:22] weil es ist halt Standard.

[48:23] Aber wenn ich es nicht umsetze, fehlt ihm das total

[48:26] und er haut es mir um die Ohren. Das wäre das Gegenteil.

[48:28] Also wir haben einmal nice to have

[48:29] und wir haben auch die absoluten Standardfeatures,

[48:31] die müssen einfach da sein, sonst knallt es.

[48:33] Und das kann man sehr gut mit diesen beiden Skalen dann ausdrücken.

[48:36] Wenn du es mal so ein bisschen vergleichst mit einem anderen Bereich,

[48:38] der auch für die Ausbildung wichtig ist, nämlich der Mitarbeitermotivation.

[48:42] Da kennst du vielleicht die Begriffe der Motivatoren und der Hygienefaktoren.

[48:46] Und genau das ist im Prinzip das hier dargestellt.

[48:49] Motivatoren kennst du mit Geld wedeln und dann fängt der Mitarbeiter an zu arbeiten.

[48:54] Der freut sich, dass er Geld kriegt.

[48:55] Super, aber wenn er es nicht kriegt, ja gut, er kriegt ja sein Gehalt.

[48:58] Also ist nicht schlimm.

[49:00] Das wäre der Motivator.

[49:01] Ein Hygienefaktor ist etwas, was ihn nicht motiviert, wenn es da ist.

[49:05] Aber wenn es nicht da ist, macht es ihn mega demotiviert.

[49:08] Mein Beispiel ist immer ein WC.

[49:10] Wenn ich in einer Firma arbeite, wo es keine Toilette gibt,

[49:13] dann werde ich ganz schön unzufrieden sein.

[49:15] Aber wenn es in meiner Firma eine Toilette gibt, sage ich nicht

[49:18] geil, was für ein toller Arbeitgeber, sondern es ist einfach Standard.

[49:22] Und genau dieses Prinzip kann man mit diesen beiden Skalen

[49:25] auf meine Anforderungen übertragen, um zu sagen, was macht den Kunden

[49:28] besonders glücklich und was macht den Kunden besonders unglücklich?

[49:32] Und das können unterschiedliche Dinge sein.

[49:35] Übrigens, falls du gerade im Hintergrund irgendwelche komischen Geräusche hörst,

[49:37] das sind meine Hunde, die gerade eine wilde Phase haben.

[49:40] Wir waren gerade draußen und die balken jetzt hier ein bisschen.

[49:43] Also von daher nicht wundern, wenn es komische Geräusche gibt.

[49:46] So, aber zurück zum Thema.

[49:47] Also diese Snow Cards sind toll, haben auch ein paar coole Ideen drin.

[49:50] Finde ich super.

[49:51] Guck sie dir gerne an.

[49:52] Benutzen in der Praxis würde ich sie nicht.

[49:54] Viel zu aufwendig.

[49:55] Stattdessen nehmen wir mal zwei andere Möglichkeiten,

[49:57] die kurz und knackig sind,

[49:58] trotzdem die wichtigsten Punkte der Anforderungen an Anforderungen enthalten

[50:01] und sich in der Praxis aber auch durchaus etabliert haben.

[50:04] Und wir fangen mal an mit der User Story.

[50:06] Die kommt jetzt eher aus dem agilen Kontext, zum Beispiel aus Scrum.

[50:09] Da arbeitet man mit User Stories, womit man also die User Stories

[50:14] sind, eine Möglichkeit, die Anforderungen zu definieren.

[50:16] Und die User Stories sind relativ kurz und knackig.

[50:19] Und zwar ist es so eine Art Template, wie man seine Sätze aufbaut,

[50:21] um die Anforderungen zu beschreiben.

[50:23] Und zwar, wenn ich das mal auf Deutsch mache.

[50:25] Als Rolle möchte ich gerne Funktionalität, damit ich Begründung

[50:32] und ich mache das mal auf Englisch.

[50:34] As a bank client, I would like to log into the banks

[50:38] Internet Banking in order to check my account balance.

[50:42] Also als Kunde der Bank, das ist die Rolle,

[50:46] möchte ich mich in das Internet Banking einloggen, einloggen,

[50:49] das ist die Funktionalität, damit ich meinen Kontostand abfragen kann.

[50:53] Das ist die Begründung, der Grund.

[50:55] Und die drei Sachen gehören immer Minimum zu einer User Story.

[51:00] Jetzt die Frage, warum?

[51:01] Die Rolle ist interessant.

[51:02] Daran kann ich festmachen, wie wichtig ist das?

[51:05] Also wenn der Kunde das will, ist das vielleicht wichtig.

[51:07] Wenn das ein Auditor will, ist das vielleicht nicht so wichtig.

[51:11] Je nachdem, in was für einem Unternehmen man arbeitet.

[51:13] Dann die Funktionalität, die beschreibt, was ich eigentlich implementieren soll,

[51:16] also Login Funktionalität.

[51:19] Und das Letzte, das ist quasi mein,

[51:21] das heißt in der Snowcat Fit Criterion.

[51:23] Das ist das Ding, an dem ich festmache, ob ich es umgesetzt habe.

[51:26] Also die Testbarkeit.

[51:28] Daran kann ich prüfen, passt es oder nicht.

[51:30] Und zwar in diesem Fall möchte ich meinen Kontostand abfragen.

[51:34] Das ist die Begründung des Kunden, was er gerade machen will.

[51:36] Und warum ist das wichtig?

[51:37] Warum darf ich diese Begründung nicht weglassen?

[51:39] Ich kann auch sagen, als Kunde möchte ich mich einloggen können.

[51:42] So, das kann ich auch umsetzen.

[51:43] Die Frage ist aber, warum will der sich denn einloggen?

[51:46] Weil diese Funktionalität ist in diesem konkreten Fall einfach nur Mittel zum Zweck.

[51:50] Der muss sich einloggen können, damit er seinen Kontostand abrufen kann.

[51:52] Was er eigentlich will, ist, er will wissen, wie viel Geld er auf dem Konto hat.

[51:55] Das ist sein Ziel.

[51:57] Und jetzt ist die Frage,

[51:58] wenn ich das aus irgendeinem Grund nicht implementieren kann,

[52:00] zum Beispiel diesen Login,

[52:01] aber ich weiß, dass das Ziel ist, diesen Kontostand abzufragen,

[52:04] dann finde ich ja vielleicht eine andere Möglichkeit.

[52:05] Dann kann ich einen Vorschlag machen, wie es stattdessen geht.

[52:08] Vielleicht kann ich mir auch einfach seinen Kontostand per SMS aufs Handy schicken.

[52:11] Dann muss er sich nicht vereinloggen,

[52:12] aber er hat trotzdem sein Ziel erreicht,

[52:13] nämlich seinen Kontostand abgefragt.

[52:16] So, das ist das Schöne an diesen User Stories.

[52:17] In diesem kurzen, knackigen Aufbau sind ganz viele Dinge ableitbar.

[52:23] Eine Priorität kann ich ableiten.

[52:25] Ich weiß, wie ich es testen kann.

[52:26] Ich weiß, ob es wichtig ist oder nicht.

[52:28] Habe ich schon gesagt, Priorität.

[52:30] Ich weiß aber auch die Funktionalität,

[52:31] also die funktionelle Anforderung steckt mit drin.

[52:33] Ich weiß, dass es nützlich zum Beispiel ist.

[52:35] Ich weiß, wie es testen kann, etc.

[52:37] Also, coole Sache.

[52:39] Lässt sich auch so runterschreiben.

[52:41] Und vor allem haben auch alle Anforderungen den gleichen Aufbau,

[52:43] denn es ist ja immer Rolle, Funktionalität, Begründung.

[52:46] Liest sich also immer gleich.

[52:48] Ich weiß also genau, wo ich gucken muss,

[52:49] wenn ich wissen will, wie ich es testen muss.

[52:51] Da kann ich mir die Begründung angucken.

[52:53] Und außerdem kann ich diese kurzen Sätze auch wunderbar

[52:55] auf so kleine Karteikarten schreiben

[52:57] und dann an so coole Kanban-Boards an die Wand heften.

[53:00] Also, kurz, knackig, trotzdem präzise und alles Wichtige drin.

[53:03] Finde ich eigentlich ein geiles Ding.

[53:05] Deswegen ist es auch so interessant

[53:07] und hat sich auch in ergebenen Projekten so durchgesetzt.

[53:09] Also in Scrum-Projekten oder Kanban,

[53:10] da arbeitet man halt mit diesen User Stories.

[53:12] Das ist da der Standard quasi für die Anforderungsdefinition.

[53:16] So, letzter Punkt, den ich häufig in so klassischeren Projekten eher sehe,

[53:20] den damit kann ich aber auch gut leben,

[53:21] das ist das Moskau-Prinzip.

[53:23] Moskau in der englischen Schreibweise, also M-O-S-C-O-W.

[53:28] Und das Moskau-Prinzip heißt deswegen so,

[53:30] weil die vier Buchstaben M-S-C und W für die Satzanfänge stehen.

[53:34] Die muss ich gleich angucken.

[53:35] Und die beiden O's sind nur eingebaut,

[53:37] damit man es netter aussprechen kann.

[53:38] Eben Moskau und nicht Mskw.

[53:41] Und die M-S-C und W stehen für must, should, could und won't.

[53:47] Und dann ist die Idee, die Anforderungen immer so aufzubauen.

[53:50] Das System muss, sollte, kann oder wird nicht irgendetwas tun.

[53:58] Also zum Beispiel, das System muss dem Kunden ermöglichen, sich einzuloggen.

[54:03] Das System sollte die Schriftgröße veränderbar anbieten.

[54:09] Das System könnte eine rote Oberfläche haben.

[54:14] Und als letztes, das System wird nicht Daten unbefugt zugänglich machen.

[54:20] So, damit kann man jetzt aufschreiben, auch in gewisser Form priorisiert natürlich,

[54:24] was das System denn alles so können muss und muss.

[54:27] Das Must sind eben die absoluten Must-Kriterien.

[54:30] K.O.-Kriterien kann man auch sagen.

[54:31] Wenn das nicht erfüllt ist, ist das Produkt oder das Projekt nicht umgesetzt.

[54:35] Das should ist so ein bisschen, ja, ich will schon fast, also nice to have noch nicht.

[54:40] Aber es wäre ganz gut, wenn das umgesetzt ist.

[54:42] Aber wenn es nicht klappt, ja, okay, würden wir trotzdem bezahlen.

[54:45] Aber wäre schon echt gut, wenn es umgesetzt wäre.

[54:48] Und das could, das sind dann die Wunsch-Kriterien.

[54:51] Also so ein bisschen nice to have, wäre halt mega cool,

[54:54] wenn ich irgendwie die Hintergrundfarbe ändern könnte.

[54:56] Aber ja, gut, wenn es nicht geht, dann ist das halt so.

[54:59] Und das won't, darauf möchte ich jetzt noch einmal genau eingehen.

[55:01] Also das System wird etwas Bestimmtes nicht tun.

[55:04] Da schreibe ich jetzt nicht einfach alles auf, was das System nicht machen soll.

[55:08] Also zum Beispiel ich soll ein Auto bauen.

[55:10] Das Auto wird nicht fliegen können oder das Auto wird nicht schwimmen können.

[55:14] So das wäre natürlich so viel, was dieses Projekt nicht umsetzen wird.

[55:18] Das werden wir nicht alles aufschreiben, sondern wofür ist dieser Punkt da?

[55:21] Es geht explizit darum, Dinge auszuschließen, die man,

[55:24] wenn man das nicht aufschreiben würde,

[55:25] eventuell vermuten könnte, dass das System es trotzdem umsetzt.

[55:29] Also ich nehme auch mal das Beispiel Online-Banking.

[55:31] Wenn ich explizit sage, das System wird mir keinen Login ermöglichen,

[55:35] dann, weil ich das zum Beispiel irgendwie anders löse oder so, ja, SMS-Kontostand,

[55:40] dann ist das natürlich wichtig zu wissen.

[55:41] Denn wenn ich jetzt anfange, ein Banking-System zu bauen,

[55:43] gehe ich davon aus, dass der Kunde sich einloggen wird,

[55:46] weil ich einfach bei allen 59 anderen Banken, die es gibt, genau das habe.

[55:50] Wenn ich jetzt aber ein anderes System baue und ich will das explizit nicht so machen,

[55:54] wie der normale Kunde annehmen würde, dass es gemacht wird,

[55:57] dann sollte ich das am besten aufschreiben.

[56:00] Das ist einmal, wenn ich zum Beispiel Sachen,

[56:01] die sonst intuitiv anders gemacht würden,

[56:04] wenn ich die nicht machen will, schreibe ich das auf.

[56:07] Aber ich kann mit diesem Punkt auch den Scope des Projekts definieren

[56:11] und zwar sagen, was ich in diesem Projekt explizit nicht umsetzen werde,

[56:14] was noch irgendwann später kommt, aber nicht im Rahmen dieses Projekts.

[56:18] Denn auch du wirst sicherlich bei dem Abschlussprojekt

[56:20] noch tausend Ideen haben, was du noch alles dazu machen kannst.

[56:23] Aber du hast einfach keine Zeit oder du hast kein Geld oder

[56:26] du kannst es nicht in der gewünschten Qualität liefern zum Beispiel.

[56:31] Und es wäre wichtig, dann zu sagen, ich weiß, dass das gewünscht ist

[56:35] und das wäre super toll, wenn wir das für den Fachbereich noch machen könnten.

[56:38] Machen wir auch, aber nicht jetzt, sondern erst, wenn wir mit dem Projekt fertig sind,

[56:42] um den Scope halt kleiner zu machen,

[56:44] damit das Projekt überhaupt erfolgreich zum Ende bringst.

[56:46] Und da wäre es wichtig, so was aufzuschreiben,

[56:48] damit dann eben nicht irgendwer der Fachbereich dann doch zum Entwickler geht

[56:51] und sagt Ja, wir hätten ja noch gern dies und das.

[56:53] Und dann so diesen Feature Creep zu verhindern.

[56:56] Das heißt, je länger ich das Projekt mache, umso mehr Features kommen dazu.

[57:00] Das ist ganz normal, weil die Leute so ein bisschen auf den Geschmack kommen.

[57:02] Fachbereich sagt Ach, das ist ja cool, dass das auch geht.

[57:04] Jetzt will ich auch noch dies und das.

[57:06] Und dann wird das Projekt nie zum Ende kommen.

[57:08] Und das ist schlecht.

[57:08] Es muss einen definierten Endzeitpunkt geben.

[57:10] Deswegen aufschreiben, was noch alles nice to have wäre,

[57:14] aber definitiv nicht umgesetzt wird in diesem Projekt.

[57:17] Dafür kann man das Won't auch gut benutzen.

[57:20] Gut, jetzt haben wir drei Verfahren kennengelernt,

[57:22] also die mega umständlichen, aber auch sehr detaillierten Snow Cards.

[57:26] Dann gibt es die User Stories, die ich super finde,

[57:30] auch gerade in agieren Projekten sehr etabliert sind.

[57:32] Und das Moskau Prinzip, was quasi eine Priorisierung schon eingebaut hat

[57:35] und in so klassischen Projekten oder sind wir ganz ehrlich,

[57:38] auch in so kleinen Projekten wie so einem Abschussprojekt?

[57:41] Ganz ehrlich, das sind 40 Stunden, beziehungsweise 80 für die

[57:44] Anwendungsentwickler.

[57:46] Da brauchen wir kein 300 seitiges Lastenheft.

[57:47] Das ist mal völlig klar.

[57:49] Von daher kann man auch eventuell sagen,

[57:50] das System muss 1, 2, 3, 4.

[57:52] Es sollte 4, 5, 6 und könnte und wird nicht.

[57:56] Und dann habe ich auf einer halben Seite mein Lastenheft fertig.

[57:58] Das kann sein für so ein IT-Beruf für Abschlussprojekte.

[58:01] Das ist völlig okay bei so einem kleinen Umfang.

[58:03] Von daher, ich muss also nicht mit dem Riesenhammer kommen,

[58:06] kann ich natürlich alles machen.

[58:07] Und wenn das Unternehmen das sowieso so macht,

[58:09] würde ich mich auch daran langhangeln.

[58:10] Übrigens noch mal ein Tipp für dein konkretes Abschlussprojekt.

[58:12] Denkt dir da nicht was Neues aus, sondern nimm einfach das Prinzip

[58:16] oder die Methode, nach der dein Unternehmen auch jetzt schon arbeitet.

[58:19] Zum Beispiel wir arbeiten mit einem Ticketsystem.

[58:22] Für solche Projekte werden halt Tickets aufgemacht

[58:23] für die einzelnen Anforderungen.

[58:24] Dann solltest du das für ein Abschlussprojekt auch nutzen.

[58:27] Und jetzt nicht einfach, weil du im Podcast gehört hast,

[58:29] dass es noch geile User-Stories gibt, das jetzt alles auf links drehen.

[58:33] Weil dir werden ja sicherlich im Fachgespräch

[58:34] auch Fragen dazu gestellt oder vielleicht zumindest.

[58:37] Und wenn du die gar nicht beantworten kannst,

[58:38] weil du dir die Methode einmal kurz,

[58:40] quasi sich hier eine Stunde im Podcast angehört hast

[58:42] und dann meintest, du musst das unbedingt so machen,

[58:45] dann kannst du natürlich im Fachgespräch

[58:46] nicht so gut auf Fragen dazu antworten.

[58:48] Deswegen würde ich dir das nicht empfehlen.

[58:49] Mach stattdessen einfach das, was du gewohnt bist zu tun,

[58:52] wie dein Unternehmen einfach arbeitet.

[58:54] Sollte allerdings dein Unternehmen so arbeiten,

[58:56] dass ihr gar nicht mit Lasten- und Pflichtenheft

[58:58] oder Anforderungen an sich arbeitet,

[58:59] dann würde ich es mir nochmal überlegen.

[59:01] Denn in irgendeiner Form musst du die Anforderungen erfassen.

[59:03] Das ist dein Job als Projektleiter deines Abschlussprojekts.

[59:06] Von daher komme ich jetzt auch mal langsam ein bisschen zum Ende.

[59:08] Wir haben ja schon eine Stunde hier geschnackt.

[59:10] Du weißt jetzt einiges über Anforderungen, warum die wichtig sind.

[59:13] Hast vielleicht ein paar Anregungen für dein konkretes Projekt bekommen.

[59:16] Wen musst du fragen, wenn du weißt, wen du fragen musst.

[59:19] Wie fragst du die?

[59:20] Du weißt, wenn du die Anforderungen aufschreiben willst,

[59:22] wie du das tun kannst, worauf du achten musst.

[59:24] Und hast sogar noch ein paar konkrete Methoden,

[59:26] wie du die aufschreiben kannst, heute mitbekommen.

[59:28] Ich hoffe, das hilft dir bei der Vorbereitung

[59:31] auf dein Abschlussprojekt und auch bei der Umsetzung nachher.

[59:33] Aber auch völlig losgelöst davon bei allen anderen Projekten,

[59:35] die du machst.

[59:36] Denn Anforderungsermittlung oder Analyse

[59:38] ist immer ein wichtiger Bestandteil.

[59:40] Wenn du da was falsch machst und nicht genau weißt,

[59:42] was der Kunde will,

[59:43] ja, dann kannst du ihm auch nicht das liefern, was er haben will.

[59:45] Und dann wird es teuer oder er bezahlt nicht oder, oder, oder.

[59:48] Also, leg Wert auf die Anforderungen.

[59:51] Das ist auch dein Job als Azubi.

[59:54] Mindestens mal bei deinem Abschlussprojekt.

[59:55] Von daher wichtiges Thema.

[59:57] Und ich habe mir gern die Zeit genommen,

[59:58] das hier mal ausführlich zu erklären.

[59:59] Ich hoffe, du hast ein bisschen was mitgenommen.

[1:00:01] Wenn dir noch was so einfällt zum Thema Anforderungsmanagement,

[1:00:04] Analyse, Aufnahme, wie auch immer du es nennen willst,

[1:00:08] dann schreib mir gern einen Kommentar zu dieser Episode.

[1:00:10] Du findest auch alles, was ich erwähnt habe,

[1:00:12] natürlich wieder als Shownotes auf der Website

[1:00:15] unter itberufepodcast.de

[1:00:17] slash 159

[1:00:19] für die heutige 159. Episode.

[1:00:23] So, und mein Aufnahmeprogramm ist gerade frisch

[1:00:26] über die 1-Stunden-Marke hinweg.

[1:00:27] Deswegen, glaube ich, habe ich für heute genug erzählt.

[1:00:29] Ich sage vielen, vielen Dank für die Aufmerksamkeit

[1:00:31] und bis zum nächsten Mal.

[1:00:33] Tschüss!