Anforderungsermittlung (nicht nur für dein Abschlussprojekt) – IT-Berufe-Podcast #159

Hi, hier ist Stefan. In dieser Podcast-Dokumentation geht es um die Projektdokumentation. Wenn du dazu noch mehr Informationen von mir haben willst, dann schau doch mal auf meiner Website vorbei. Unter "die perfekte Projektdokumentation.de" und jetzt viel Spaß mit der Podcast-Dokumentation. Herzlich willkommen zum IT-Bogufe Podcast, dem Podcast, der rund um die Ausbildung in den IT-Bogufen. In dieser Episode geht es um die Anforderungs-Empitlung, unter anderem für dein Abschlussprojekt. Viel Spaß! Hallo und herzlich willkommen zur 159. Episode des IT-Bogufe Podcasts. Mein Name ist Stefan Macke und heute geht es mal wieder um eine allgemeines Thema, was für alle IT-Bogufe daraus ein interessant sein sollte. Gut, dass der IT-Bogu-Podcast jetzt so heiß und nicht mehr anlängst den Weg der Podcast, beim letzten Mal haben wir uns ein bisschen über funktionale Promierung unterhalten, das ging mehr so in Richtung der Amlängst-Empitlung. Aber heute geht es um das Thema Anforderungs-Empitlung oder Anforderungsanalyse oder Aufnahme oder wie auch immer. Und jetzt kommen Sie sich fragen, wer braucht das? Na ja, jeder Prüfling braucht das. Denn alle IT-Bogufe enden ja mit einem Abschlussprojekt, was Teil der Note ist. Und zu diesem Abschlussprojekt gibt es auch eine ganze Reihe an Anforderungen sicherlich. Und da ist es "The Job des Prüflings", also genau "Dein Job", da seh' ich, diese Anforderungen aufzunehmen für dein eigenes Projekt. Und wie man das am besten macht, was überhaupt Anforderungen sind, wofür wir die Brauchen, wie wir die erheben, wen wir fragen müssen. Und was es vielleicht auch sogar für Anforderungen an diese Anforderungen gibt, nämlich wie man die Anwesen aufschreibt, das wollen wir uns alles heute mal ein bisschen auf der Zunge zigieren lassen. Ich habe dann ein bisschen was mitgebracht. Ich glaube, das könnt heute ein bisschen länger an der Ohren, wir schauen mal, wie es schnell ich durchkomme. Und ja, nochmal zur Erklärung, also was haben wir vor? Du willst dein Abschlussprojekt starten? Hast auch grob eine Idee, worum es geht. Ich hoffe, du hast hier schon ein vernünftiges Projektthema ausgesucht. Dazu habe ich auch schon eine Podcast-Ebisode aufgenommen, wie man das am besten macht. Und wie du auf Ideen kommst und darum solltest heute nicht gehen. Sondern du hast jetzt schon dein Thema vor Augen, du weißt, was du machen willst. Grob und jetzt geht es darum, dass zu verfeinern. Was sind genau die Anforderungen, die du eigentlich umsetzen sollst? Und da kann man jetzt natürlich überlegen, ist es überhaupt, dein Job diese Anforderungen aufzunehmen. Und ich sage einfach mal, ja, das ist in meisten Fällen so. Wenn du in einem ganz tollen Unternehmen bist, wo du die Anforderungen auf einem Silbert Blatt vom Fachbereich oder von deinem Kunden oder von deinem vorgesetzten wir immer, serviert bekommst, ist das alles ganz toll? Ich glaube, in der Praxis sieht das eher nicht so aus. Wahrscheinlich hast du irgendwie so eine grobe Idee oder eine Richtung bekommen, wohin es gehen soll, was du erreichen sollst, aber wie das jetzt genau ausgestaltet werden soll. Also die Idee ist, quasi. Das ist eigentlich dein Job, das aufzunehmen. Zumindest würde ich das so sehen, wenn ein Prüfling ein Projekt umsetzen sollt ihr den gesamten Projektablauf begleiten und dokumentieren vor allem auch in der Projektdokumentation. Und dazu gehört unbedingt auch die Anforderungsanalyse oder eben Aufnahme. Und wenn man jetzt überlegt, in was für einem AT-Fakt das ganze enden könnte, dann wäre das für mich in so einem Projektdokumentation so etwas wie ein Lasten-Heft. Oder wenn man noch einen Schritt weitergeht, das Pflichten-Heft. Eigentlich ist es ja so, dass der Auftrag Geber das Lasten-Heft erstellt. Also der Kunde, der sagt, was ihr haben will, fachlich grob vorgegeben, was die Anwendung zum Beispiel, die du erstellt, oder das System, das du installierst, oder was auch immer du machst in deinem Abschlussprojekt, was das bieten soll quasi. Und dann bist du in der Pflicht das Pflichten-Heft zu stellen. Wow, zumer Pflicht, ja. Das heißt der Auftragnehmer, der das Projekt umsetzt, der erstellt das Pflichten-Heft. Und das ist mit technischen Details, was genau umgesetzt wird, wenn ich es mal wieder an eine Anwendung zum Beispiel mache, die entwickelt werden soll, welche Programmiersprache, welche Architektur, wenn ich ein Physi zum Beispiel habe, welches konkrete Betriebssystem wird denn eingesetzt. Wie groß soll die Festplatte werden? Ist es eine Cloud oder on-premise? Und ich weiß nicht was. Also ganz genau die technischen Details, die erstellt der Auftragnehmer, ich bring es auch mal natürlich ein normaler Auftragnehmer, also der der ist umsetzt. Und das Lasten-Heft, wo die Anforderungen eigentlich drinstehen, das kommt vom Kunden. Ich weiß aber, dass es in der Praxis häufig so läuft, dass auch der Prüfling das Lasten-Heft erstellt. Ich kann es nur jetzt zum Beispiel auf Unser Unternehmen übertragen. Da haben wir jetzt nicht die perfekt ausgebildeten Menschen im Fachbereich, die dir so ein Lasten-Heft unterschreiben, wo alles drin steht, was gemacht werden soll. So nach dem Motto du Christa, so ein Stabilpapier und da musst du nie wieder mit den Leuten reden und setz das einfach um. Das funktioniert in der Praxis eher weniger. Es gibt ganz häufig irgendwelche Rückfragen und spätestens dann musst du ja so ein paar Tools an der Hand haben, wie du genau rausbekommst, was du eigentlich machen sollst. Und darum sollst heute gehen. Ich möchte jetzt heute mit dir nicht Lasten- und Flist-Flichten-Heft im Detail durchgehen. Wie man das aufstellt, habe ich schon mal, glaube ich, ein sehr langen Blockartikel zu geschrieben. Ich weiß es gar nicht mehr, kannst mal suchen, weil mir im Block darum sollst heute nicht gehen. So das geht wirklich um die Anforderung. Und du kannst das konkret beziehen auf dein Abschussprojekt, aber auch auf alles andere, was du auf der Arbeit machen musst. Also, wie kommst du zu den Anforderungen? Und bevor wir jetzt mal damit anfangen, kleine Überblick, was ich heute so vorhab oder in dieser Episode, wir fangen erstmal an, was sind überhaupt Anforderungen? Wir lassen die sich gliedern, wofür braucht man die? Und dann kommen wir zum Begriff der "Stakeholder". Wir definiert überhaupt unsere Anforderungen. Wir müssen wir fragen, um solche Anforderungen herauszukommen. Und dann haben wir noch konkrete Methoden der Anforderungsermittlung. Das heißt, wenn du jetzt vor der Aufgabe stehst, du weißt, wie du fragen musst und was Anforderungen sind. Aber wie Christu die jetzt raus aus diesen Leuten? Das sind dann konkrete Methoden zum Abschluss. Und dann gibt es noch ein paar konkrete Anforderungen an die Anforderungen selbst, wie du die am besten aufschreibst, damit die auch vollünftig umsetzbar sind. Und das letzte ist, habe ich dann noch ein paar Beispiele, wie man konkret Anforderungen dann formulieren kann. Also, wie ich es sich hab heute eine Randvollagenda. Deswegen würde ich sagen, wir starten einfach mal direkt durch. Aber bevor wir mit den Anforderungen loslegen, fangen wir mal mit einem anderen Begriff an. Und zwar der Qualität. Hast du bestimmt schon mal gehört? So wahrscheinlich auch öfter mal, hörst du immer mal wieder Qualität, hohe Qualität, niedrige Qualität. Was heißt das eigentlich? Und es gibt eine schöne Dien-Norm, bis zum Beispiel sogar eine Iso-Norm, die man auch wunderbar, zumindest als Software-Wikler, für die Abschlussprüfung lernen kann. Und da drin sind verschiedene Punkte der Software Qualität aufgeführt. Zu dem Thema werde ich ganz sicher noch mal eine Podcast-Bisode aufnehmen. Das habe ich mir schon auf mein List geschrieben. Das ist ein super wichtiges Thema. Kommt ganz oft auch in der mündlichen Prüfung ran, zumindest bei uns im Bereich der Amöngste-Inwicklung. Und die Iso-Norm von der ich spreche, ist die 96/26 oder 911/26. Und da drin sind ja in einem etwas abstrakteren Modell verschiedene Punkte der Software Qualität dargelegt. Die kann man alle wunderbar auswendig lernen und erklären. Möfen wir jetzt auch nicht alle? Ja, das sind glaube ich über 20 Punkte, gegliedert in sechs Oberpunkte. Dazu gehört sowas wie Änderbarkeit, Benutzbarkeit, Funktionalität, Zuverlässigkeit, Übertragbarkeit, Effizienz. Das war noch schon die sechs Oberpunkte der Iso. Nur das zu schon mal weißt, in welcher Richtung es geht. Da werde ich sicherlich noch mal was zu aufnehmen, habe ich gesagt. Aber was ist überhaupt Qualität? Und wenn man da jetzt mal eine Definition schaut, dann stellt man fest, dass Qualität die Übereinstimmung mit den Anforderungen ist. Beziehungsweise der Grad, der Erreichung oder der Umsetzung dieser Anforderungen. Und ich mache das immer gerne fest an einem Beispiel, einem Flugzeug, wenn du jemanden fragst, ob ein Flugzeug von hoher Qualität ist. Da musst du immer schauen, wen fragst du denn? Und was sind die Anforderungen dieser Person? Überleg mal bei einem Flugzeug, wahrscheinlich wenn die meisten Menschen fragst, werden die in Form des Fluggastes dieses Flugzeug bewerten. Also, haben die genug Beinfreiheit, ist keine Ahnung. Ist der Sitz direkt am Notausgang, ist das vernünftiges Essen, schmeckt der Tomaten, sagt Wasser umar. Das ist dann ein qualitativ hoherwärtiges Flugzeug, wenn das alles gilt. Das alles interessiert aber zum Beispiel den Flugkapitän, also den Piloten, überhaupt nicht. Die Beinfreiheit hinten irgendwo in der Holzklasse interessiert den Piloten nicht, der braucht ganz andere Sachen. Aber vielleicht ganz andere Sachen, so was wie Modenz der Stand der Technik oder vernünftige Checklisten. Keine Ahnung, Blitzschutz. Ich weiß nicht, was der Piloten sonst noch so war, aber der hat vermutlich ganz andere Anforderungen an dieses Flugzeug als ein Gast. Von daher werden die beiden vielleicht zu einer sehr unterschiedlichen Aussage über die Qualität des Flugzugs kommen, weil sie mit ganz anderen Augen drauf gucken und ganz andere Anforderungen haben an dieses Flugzeug. Und genau darum geht es auch bei uns in der IT, wenn wir Projekte umsetzen, dass wir diese verschiedenen Blickwinkel berücksichtigen müssen. Und natürlich sind die alle unterschiedlich progressiert. Also was der Pilot sagt, ist vielleicht im Zweifeln ein bisschen wichtiger als was der Malleurlau vorhin sagt. Von daher muss man natürlich auch immer Gewichten und eine Reinfolge bringen. Und das ist auch dann dein Job als der, der das Projekt umsetzt. Du sollst ja eine Ausbildung auch lernen, Projekt Leitung zu machen, Projekt Planung zu machen, gerade auch für den eigenes Projekt. Und da musst du schon entscheiden, angenommen du hast zwei konkurrierende Anforderungen, welche gewinnt denn jetzt? Und da musst du bewerten, vielleicht von welchem Menschen die zum Beispiel gestellt wurde und wer da vielleicht etwas wichtiger ist als der andere. Und da kommen wir jetzt nämlich direkt zum schon zum Punkt. Wer hat denn diese Anforderungen überhaupt aufgestellt? Und ich nehme das mal schon kurz vorweg, die Leute, die Anforderungen an unser Projekt stellen können. Und das kann jede beliebige Person oder eine Personengruppe auf sein, eine Institution. Irgendwer, der an diesem Produkt oder an diesem Prozess des Erstellens dieses Produktes beteiligt ist, das sind Steak Holder. Und da habe ich auch eine schöne Geschichte aus einer Prüfung. Da hat tatsächlich jemand, der kannte das Wort Steak Holder, hat aber Steak vorne nicht ST-AKI geschrieben, wie es eigentlich geschrieben wird. S-T-E-A-K-A, also wie das Steak, was man auf den Grill liegt. Und das war sehr schön in der mündlichen Prüfung. Der war felsenfest davon überzeugt, dass das irgendwas mit einem Steak zu tun hatte, was überhaupt nicht stimmt. So dann es geht hier um Steak Holder mit A-K-E. Und wenn du Steak direkt auf Deutsch übersetzt aus dem Englischen, dann heißt das sowas wie ein Pfosten oder ein Holzbflock, eine Stange, eine Stütze oder ein Zaunpfahl. und zwar auch ein paar Sachen, die wir uns nicht so sagen können. Na ja, der hat irgendwie einen Block in unser Projekt gerannt. Das heißt, so nalte Motto, der hat einen Fuß in der Tür, der will irgendwas von diesem Projekt. Das kommt noch so ein bisschen aus der Goldgräberzeit. Wenn man, oder die Leute, die früher in den USA unterwegs waren und danach Gold gestürft haben, die haben da ihren Steak abgesteckt. Das heißt, die haben überall kleine Holzflöcke reingemacht in die Erde und gesagt, "So, oder dieses mein Gebiet hier suche ich nach Gold." Und wenn da jemand anders reinkamen, dann, na ja, weiß ich nicht, was dann passiert. Okay, zurück zum Thema. Also, dieses Steakholder um die soll es gehen und nicht um die Steakholder im Sinne von Grillmeister. Ja, das ist hier nicht gemeint. Und dieses Steakholder können unterschiedliche Anforderungen an uns stellen. Und wir werden auch gleich noch mal auf eingehen, wer genau dieses Steakholder sein können. Ich möchte aber vorab noch einmal grundsätzlich Anforderungen so ein bisschen unterteilen. Es gibt nämlich zwei verschiedene Arten von Anforderungen. Und zwar die funktionalen Anforderungen und die nicht funktionalen Anforderungen. Und das ist ganz wichtig, denn die sind beide ultra wichtig für unser Projekt. Wir müssen beide Brüchsel dienen, aber vom Umfang hier sind die deutlich unterschiedlich. Und zwar für kurze Erklärung, was es überhaupt ist, die funktionalen Anforderungen, die beziehen sich direkt auf die zu erbringenen Deleistung des Produkts. Nehmen wir mal ein Text für Abwinnungsprogramm wie Microsoft Word. Wenn der Kunde sagt, ich muss die Möglichkeit haben, hier Text FET zu machen oder kursiv zu setzen. Dann ist das direkt eine funktionale Anforderung. Entweder kann es das Programm oder nicht. Die nicht funktionalen Anforderungen beziehen sich auf alles andere außer diese konkrete Funktionalität. Nehmen wir mal das Beispiel wieder zurück zu Word, wenn ich den Text FET mache und der Wirt FET, dann ist das Funktionale umgesetzt. Wenn das eigentlich drei Sekunden dauert, bis der Text FET wird, weil das Programm so langsam ist, dann ist eine nicht funktionale Anforderung vielleicht nicht erfüllt. Nämlich, dass das Programm vernünftig bedienen war sein soll und es war eine gewissen Geschwindigkeit. Oder wenn ich Word starte um ein PC-Ratsab, weil der 16GB-Ramm schluckt für ein FET ist wort, dann habe ich auch eine andere. Nämlich zum Beispiel die Speichereffizienz nicht eingehalten. Und jetzt ist das interessante, wenn man sich auch diese Qualitätsnorm anguckt bei der Software Qualität. Es gibt einen Punkt Funktionale Anforderung und dann gibt es gefühlte 27 Punkte nicht Funktionale Anforderung. Also ich über 3, jetzt vielleicht ein bisschen, das sind aber wirklich über 20. Ich habe die genaue Zahl des Graden nicht im Kopf. Ich meine, als ich das damals mal aus, wenn ich lerne, durfte waren es 24 Punkte und eine davon war Funktionale. Und 23 war nicht Funktionale. Das heißt, alles drum herum. Wie schnell ist das Programm, stürzt das ab, ist das Fehler tollerand. Also sind zum Beispiel Fehler-Meldungen sprechen, kann ich das auf beliebigen Betriebssystemen installieren oder nur auf EIM. Das sind alles so Beispiele für nicht Funktionale Anforderungen. Und das gibt es nicht nur in der Software-Inwicklung. Ich zieht hier hier immer die ganze Zeit, die diese ISO-Norm. Aber das gilt auch für alle anderen Projekte. Also wenn wir einen Physipo-Projekt nehmen, kann ich das System, was ich da aufsätze von heute auf morgen zum Beispiel auf eine neue Version heben. Also ich habe eine Windows 10 Installation, kann ich die einfach hochziehen zum Beispiel. Das ist zum Beispiel etwas, was natürlich interessant ist, auch wenn es für einen eigentlichen Betrieb vielleicht irrelevant ist. So, das heißt, für alle unsere Projekte haben wir einen ganzen Haufen nicht Funktionale Anforderung und die müssen wir genau so berücksichtigen, wie die Funktionale Anforderung. Nur leider sind die nicht Funktionale Anforderungen oftmals nicht so einfach zu definieren. Denn wenn ich jetzt ein Fachbereich frage, sag mal, ich will hier nur neue Anwendung programmieren. Textverarbeitung, was soll die denn können? Dann wird dem mir sicherlich nicht als erstes sagen, ja die muss aber besonders schnell sein. Also innerhalb von 100 Millisekunden will ich den Text aber sehen. So, dann wird mir genauso was sagen, wie "Fat-Cosive-Überschrift-Inhaltsverzeihendes etc., also die Funktionalen" sagen. Aber die nicht Funktionalen, allein vom Umfang hier sind sie halt viel viel mehr und im Zweifel tragen sie auch dazu bei, dass der Kunden das Produkt nicht akzeptiert. Wie gesagt, ich kann die beste Textverarbeitung haben, wenn die einfach mega langsam ist, wird kein Kunde die benutzen wollen. Also, von daher beides müssen wir berücksichtigen und manchmal sind die nicht Funktionalen oder meisten sind die nicht Funktionale Anforderungen sehr, sehr schwer zu ermitteln, weil das einfach so erwartet wird. Ich erwarte, wenn ich im Programm starte, dass es nicht abstürzt, das schreibe ich nicht extra auf. Also, von daher ziehe die Gameliseisonorm rein und guckt die diese nicht Funktionalen breiche da an. Aber wie gesagt, ich mache noch mal eine Episode separaten, wo dafür. Also, Funktionale Anforderungen, nicht Funktionale. Das käme schon. Wunderbar. Und jetzt geht's weiter. Jetzt haben wir unsere "Stakeholder" und die können wir jetzt fragen, was sind denn eure Anforderungen an der neue Produkt, was ich hier schaffen will? Und bitte, Produkt, wie gesagt, kann es Software sein, kann ein Netzwerk sein, was ich installiere, kann ein, ich weiß es nicht. Irgendwann sein, was ich lüten soll für die System-Elektroniker. Also, das ist ganz egal, was wir hier machen als Produkt. Ich gehe mit meinen Beispielen immer auf die Software, weil ich das halt jeden Tag mache. Aber es gilt auch für alle anderen Projekte, alle anderen IT-Bogen. Und jetzt ist die Frage, wer sind denn eigentlich alles unseres "Stakeholder"? Denn ich kann mir vielleicht verschiedene Anforderungen an meinem Produkt ausdenken, oder ich frag den Kunden, aber reicht das denn? Wie muss ich denn noch fragen? Und ich habe einfach mal nur zum Beispiel eine Liste mitgebracht an möglichen "Stakeholder" an unser Projekt. Du kannst ja mal, wenn du ein bisschen mitmachen willst. Das habe ich noch nie gemacht im Wortgras. Du kannst das ja mal machen. Du kannst ja mal auf Pause und überlegt mal kurz, wer könnte denn ein Interesse an deinem Projekt haben? Und ich gebe meine Zahl vor. Ich habe zehn Personen oder Personengruppen mitgebracht, die ein Interesse an deinem Projekt haben könnten, die du theoretisch einbeziehen musst bei der Anforderungs-Ermittlung. Natürlich, die Liste ist sehr lang und nicht für alle Projekte sind alle immer wichtig. Das ist völlig klar. Aber ich würde mir einen Denk-Anschluss geben, woran du denken könntest, wenn du jetzt wirklich mal ein größeres Projekt umsetzt. Vielleicht hast du ja auch eine andere Regelung für dein konkretes Projekt und hast eine Gruppe, tatsächlich vergessen. Und ja, dir fällt das jetzt ein, dass du dir noch mal befragen musst. Also, überlegt doch mal kurz, ich habe zehn Gruppen mitgebracht. Und wenn du jetzt Pause drücken willst, dann macht das mal. Und jetzt geht's los mit den zehn Gruppen. Ich vermehr ganz vorne an, eine Gruppe habe ich eben schon selber genannt und zwar der Kunde. Also, der Kunde, der das Geld bezahlt am Ende für das Projekt, ich glaube, der hat viel zu melden. Wenn der eine Anforderung hat, dann sollten wir die umsetzen, denn sonst gibt es kein Geld. Also, das ist glaube ich relativ selbst erklärt. Dann machen wir weiter. Nächste Gruppe, Anwender. Und das muss nicht das gleiche sein. Ein Kunde kann zum Beispiel an Unternehmen sein, kaufen neue Software bei mir ein. Die Leute, die mit dem Ding dann jeden Tag arbeiten müssen, sind aber vielleicht gar nicht der Kunde, also das Unternehmen, sondern die Mitarbeiter dieses Unternehmens. Und die haben vielleicht ganz andere Anforderungen als der Kunde. Der Kunde will vielleicht, also, es billig ist. Der Anwender will vielleicht, dass es benutzbar ist. Also, die Usabilität ist vielleicht ganz wichtig. Oder, die selbst erklärbarkeit. Oder, dass es eben nicht drei mal am Tag abstürzt. Oder, oder, oder. Also, die Anforderungen, siehst du schon mal hier allein beim Kunden und beim Anwender, können schon sehr unterschiedlich sein. Dann dritte Gruppe, Management. Auch die haben vielleicht eine Anforderung. Die wollen vielleicht am ersten noch, dass es günstig ist. Die wollen vielleicht Gottbewahre irgendwelche Überwachungsfunktionen haben, um die Anwender zu prüfen. Ob die auch schnell genug arbeiten. Also, weil wir niemals da reinpohermieren, keine Frage. Aber nur mal so als Idee. Die haben vielleicht ganz andere Anforderungen. Dann, eine meiner Lieblingsgruppen. Gerade auch bei unserem Unternehmen immer müssen wir die berücksichtigen. Und das ist auch mal wichtig. Der Marketingbereich. Die wollen vielleicht, dass das Produkt schön aussieht. Dass man das keine Ahnung auf Hochglanzfolie enttoll präsentieren kann. Das bestimmte Farben eingehalten werden. Allein das wird sicherlich für ein Programmierprojekt bei dir gelten. Du musst das Corporate Design deiner Firma einhalten. Du kannst dir einfach selber was ausdenken, zum Beispiel. Also Marketing, ganz wichtig. Dann haben wir, wenn wir mit der entwickelungsprojekt haben, die Entwickler natürlich auch mit dem Boot. Das Gleiche gilt, wenn du ein Abbildenprojekt machst, natürlich auch für die Administratoren. Also es geht hier nicht nur darum, die Endanwender glücklich zu machen, sondern auch die, die das Produkt entwickeln. Was können die Verantwortung haben? Die wollen vielleicht eine vernünftige Versionsverwaltung haben. Die wollen eine coole Promisprache nutzen. Die wollen bestimmte Frameworks einsetzen. Die wollen Tools, keine Ahnung, Wien-E-Shoot-Tracker, wie Gera oder Red-Mine oder sowas benutzen. Das heißt, die haben ganz andere Anforderungen als das Projekt. Das hat mit der Funktualität fast gar nichts mehr zu tun. Die gucken mit einem ganz anderen Auge drauf. Wie können wir das Produkt vernünftig entwickeln, testen in den Betrieb bringen? Wenn wir da schon vom Betrieb reden, eine weitere wichtige Steak-Holo-Gruppe support. Denn wenn das Produkt erst mal in Betrieb ist und vielleicht kennst du die Phasen des Produktlebenszüchlus. Die längste Phase mit Abstand ist der Einsatz, also der Betrieb des fertigen Produkts. Wenn wir ein Jahr langen Software entwickeln und die ist dann nach 20 Jahren im Einsatz, dann siehst du, dass das der größte Teil des Lebenszüchluses dieses Software zum Beispiel ist. Und in dieser Zeit treten vielleicht Fehler auf. Und wer muss die beheben oder wer muss ich drum kümmern, der Support. Und das sind im Zweifel ganz andere Leute als die Anwender zum Beispiel. Die kriegen halt eine Fehler-Meldung. Wir wollen mit dem Ding eigentlich nur arbeiten und rufen dann beim Support an. Und dann geht es los. Wie soll das Support jetzt den Fehler finden? Was braucht er? Der braucht vielleicht eine Logging. Der Muss Möglichkeiten haben sich vielleicht in der Session einzuklingen und sich da was anzugucken. Irgendwie die Backinformationen zu Laufzeit sich anzuschauen. Also alles was den Support bei der Fehler-Suche unterstützt, das muss man ja wissen, das muss in der Einbauen. Ein Programm, was ich schreibe, lockt die ja nicht von alleine irgendwas raus. Das muss ich schon programmieren und das muss ich wissen, bevor ich anfange damit. Jetzt kommen wir mal zu so ein bisschen allgemeineren Sachen. Und zwar der nächste Punkt, Gesetzgeber. Ich komme aus einer Krankenversicherung. Da orientieren wir uns ständig an irgendwelchen Gesetzen, weil der Gesetzgeber sich mal wieder etwas Neues ausgedacht hat. Und da sind wir verpflichtet dazu, das einzuhalten. Wenn wir in der Krankenversicherung, zum Beispiel den Datenschutz oder so was missachten, dann wird uns die Bude zugemacht. Da müssen wir uns dann halten, ganz einfach. Und das gilt auch für dich, zum Beispiel, Stichwort DSGVO, da musst du einhalten. Wenn du das nicht machst auf einer Website, kannst du abgemahnt werden. Kannst du irgendwann den Laden zumachen. Also Gesetze, alles was der Staat quasi vorgibt, da halten wir uns besser dran. Auch das sind Anforderungen und das sind teilweise sogar sehr harte Anforderungen. Stimmen wir uns mal vor, online shopp und so, was da die Kunden alles für Auskunftsrechte haben nach DSGVO. Da müssen wir eventuell wirklich richtig intensiv programmieren, um zum Beispiel eine Datenauskunft überhaupt rausgeben zu können, um alle Daten über einen Kunden, die wir gesammelt haben raus. zu geben. Ich dachte, das ist gar nicht so einfach. Da musst du schon irgendwas vorsehen. Das musst du von Anfang an wissen, sonst wird es ganz schön schwieriger mende. So, nächster Punkt, für sit-in-IT. Und da bauen wir meisten Systeme, die nicht für sich alleine irgendwo stehen, sondern die mit anderen interagieren müssen. Und da wäre für uns ganz wichtig, dass wir uns an Standards halten. Wenn ich ein Web-Server aufbaule, dann nehme ich bitte Http und Https und denk mir nicht mein eigenes Protokoll aus, zum Beispiel. Wenn ich irgendwie Windows freigaben machen will, dann sollte ich vielleicht die eingebote Funktivität von Windows benutzen und nicht irgendwie einen Programm schreiben, was über ein obskurses Netzwerk-Potokolleteil in NDR transferiert. Dafür gibt es die Standards, damit Systeme miteinander interoperabel funktionieren. Und das ist auch ein Qualitätsgetehrung übrigens, aber hier extra noch mal als Steakholder mit aufgeführt, Standards bissel dran halten. Dann vor letzter Punkt ein habe ich noch Audi Toren. Auch das bringe ich mit aus der Krankenversicherung und auch aus jedem anderen Unternehmen. Da wird es irgendwie mal Audits geben. Sei es Wirtschaftsprüfer, die ins Haus kommen oder tatsächlich sogar staatliche Behörden bei uns in der Krankenversicherung. Da kommt die Bar-Fienen und kontrolliert einfach mal, ob wir da alle richtig machen. Und was wollen die dann wissen? Jetzt Wirtschaftsrüper oder solche anderen Prüfer. Die wollen tatsächlich irgendwelche Protokolle sich anschauen. Irgend ein rechte Konzept, vielleicht, wer darf was, vier Augenprinzip. Also wie die Menschen mit dieser Software zum Beispiel arbeiten, die wieder bauen oder mit dem System. Wie sicher ist das? Wie ist der Datenschutz eingehalten? Und so weiter. Und das können wir gegebenenfalls nur liefern, wenn wir solche Sachen auch vorher eingebaut haben. Ich kann jetzt nochmal ein Stichwort nennen, z.B. aus einer Dokumentenverwaltung Software. Da gibt es einen Audit Trail. Das heißt, ich kann genau nachvollziehen, welcher Mitarbeiter hat, wann, was für Dokument verändert, was hat er drauf geschrieben hat und so weiter. Ich kann mir alte Version noch wieder angucken. Das brauche ich alles, wenn ich so eine Nachweispflicht z.B. habe. Und letzter Punkt, das ist immer einer meiner Lieblingspunkte, Kulturkreis. Auch unser Kulturkreis ist ein Stakeholder und ich habe immer ein schönes Beispiel, Farbe. Wir haben eben Vermarketing gehört, Marketing sagt, die Oberfläche muss blau. Und wenn ich jetzt so eine Software entwicke, die z.B. weltweit eingesetzt wird, dann muss sich vielleicht vorher mal überlegen, ob die Farbe blau in allen Ländern, das bezweckt, was sie soll. Ich nehme einen anderes Beispiel, weil ich das weiß. Beziehungsweise ich habe das glaube ich mal irgendwo gelesen. In China gilt z.B. die Farbe weiß als Farbe des Todes. Das wäre in Deutschland glaube ich nicht so. Da wäre der vielleicht eher schwarz. Und schwarz und weiß sind ja schon mal sehr unterschiedlich. Also von daher, wenn ich eine schöne weiße, strahlende, Oberfläche baue, so White Space,mäßig, iPhone, alles weiß. 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, dann kommt das vielleicht nicht so gut. Und das ist jetzt nur ein Beispiel. Noch andere Sachen sind natürlich sowas wie Währung gehört dazu oder eben auch Sprache von links nach rechts oder von rechts nach links. Wenn ich Software auch für einen arabischen Raum baue, dann musst du ja auch einmal von rechts nach links lesbar sein. Oder in Japan oder in Korea, wo es diese Schriftzeichen gibt. Wenn ich in Deutschland einen Riesen-Text habe, über was ich drei Absätze, ist das vielleicht in Japan in den schriftzeichen auf einmal nur noch ein Drittel so lang. Auf einmal sieht meine ganze Website, wenn ich dann eine baue, ganz anders aus. Das heißt, dass Design muss ich auch entsprechend anpassen, weil die Schrift ganz anders funktioniert. Das sind so Dinge, denk mal vielleicht gar nicht ran, wenn man jetzt ein kleines Abschlussprojekt als IT-Ler macht, okay, aber ich will ja es ja auch ein bisschen allgemeiner hier formulieren. Und wenn du meine Website baust für einen großen weltweit tätigen Konzern, kann ja auch eine Internetanwendung zum Beispiel sein, für einen weltweit agierendes Unternehmen. Dann müsste du darauf achten, dass vielleicht die Sprache in anderen Ländern ein bisschen anders dargestellt wird, als in Deutschland. Also der Kulturkreis ist auch ein wichtiger Stakeholder. Bitte immer mal gucken, wo soll das Ding einig eingesetzt werden, was ich da baue und was sind da die gegeben halten, an die wir uns vielleicht halten soll. Gut, bis da auf die Zähnen gekommen, ich weiß nicht, wir können ja mal gucken, Kunde, Anwender, Management, Marketing, Entwickler, Support, Gesetzgeber, Standards, Auditoren, Kulturkreis. Das waren meine Zähnen und ich glaube, es gibt noch ein paar Mir, aber nur als Anregung, also denkt mal nicht nur an die Leute, wo du weißt, die werden nachher deine Anwendung oder deinen System benutzen, sondern denk auch mal ein bisschen "Auto the Box", wie du eventuell noch fragen musst, wer Anforderungen dein Projekt hat. Gut, jetzt wissen wir das, jetzt haben wir 10 Personengruppen, die wir fragen können. Wow, ich bin mal ganz ehrlich, in so einem klassischen Abschussprojekt sind es vielleicht nicht ganz so viele, da sagst du vielleicht sowas wie die Software, musst du auch so wie das CD vorgibt, also Corporate Design des Unternehmens und damit hast du Marketing schon abgedeckt. Wahrscheinlich wirst du dich eher auf den Kunden oder die Endanwender vielleicht auch, wenn du zum Beispiel ein System aufsetzt als Physi, vielleicht die anderen Admin, sie später damit arbeiten sollen oder so konzentrieren. Aber wie gesagt, ich will dir mal einen Denkanschluss geben und ganz oft vergisst man Leute und wundert sich dann später, wenn man dann die Software zum Beispiel einführt, das sich jemand beschwert. Ich nehme mal noch ein Beispiel, das wäre der 11.Stakeholder Betriebsrat, wie oft wir in einer möglichen Prüfung schon Software besprochen haben als Abschussprojekt, so was wie eine Zeiterfassung oder eine Projektplan, da hat der Prüfling nicht einmal mit dem Tripsrat geredet. Aber das ist zustimmungspflichtig sowas, wenn ich zum Beispiel eine Arbeitszeiterfassung einfüre, da muss ich die Betriebsrat fragen und da kann ich nicht einfach anfangen, irgendetwas zu pohramieren, wo ab jetzt jeden Morgen die Mitarbeiter stempeln müssen, ohne vorher zum Beispiel, die mit Tripsrat ins Boot cool zu haben. Also solche Sachen geht gar nicht, von daher immer daran denken, habe ich wirklich alle gefragt, die was mit meinem Projekt zu tun haben. Also jetzt wissen wir, wen wir fragen müssen, das ist ja schon mal gut. Jetzt ist die Frage, wie fragen wir die denn? Und auch hier kannst du wieder mit raten, wenn du willst. Ich habe zehn Methoden mitgebracht, wie du zu Anforderungen kommst. Also du weißt, du hast eine Person sitzen, stehen, was auch immer. Und was hast du jetzt für Möglichkeiten, da die Anforderungen rauszukriegen? Und die erste, die wahrscheinlich einfällt ist, fragen, das würde ich jetzt über dem Overpunkt Interview zusammenpassen. Also das dümmste Anführungs- sagen, was man kann, hingehen, fragen. So, das ist logisch, das ist intuitiv. Ich meine nicht dumm, sondern intuitiv, wollte ich eigentlich sagen. Okay, vielleicht fallen dir ja noch neun weitere Möglichkeiten an, ein, wie du auf die Anforderungen kommst. Also wenn du willst, kannst du jetzt hier Pause machen und dann hören wir uns gleich wieder. Gut, ich habe noch neun mehr Nummer eins, wenn das Interview nicht funktioniert, weil ihr vielleicht zeitliche Trend seid, andere Zeitzone, was er immer, wenn du ihn nicht direkt fragen kannst, sag ihm doch, schreib mal auf und das würde dann einfach selbst auf Schreibung heißen. Ja, relativ simpel, aber vielleicht ist es dir gar nicht eingefallen. Wenn man das etwas strukturiert haben, machen will und nicht einfach sagt, so hier hast den Dina 4 Blatt, schreib mal auf, das fällt nämlich vielen Menschen sehr, sehr schwer, gerade auch Fachmitarbeitern, die haben genau im Kopf, was sie haben wollen, aber sie können sehr schwer in Worte fassen oder formulieren. Das ist ganz häufig so. Aber die sind einfach nicht geschult, 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. Von daher kannst du ein bisschen unterstützen, wenn du zum Beispiel einen Fragebogen benutzt, wo zum Beispiel bestimmt Sachen vordefine sind, sowas wie wie schnell soll denn die Anwendung reagieren oder wie wichtig ist ihn das Layout, wie wichtig ist ihnen die Maustäuerung oder die Tastatursteuerung oder oder, 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 wir uns gar nicht gekommen werden. Ja, nächster Punkt, wenn wir sogar keine Ahnung haben und wir wollen mal völlig offen ran gehen, da können wir uns mit mehr Leuten zusammen setzen und da machen wir ein Brain Storming. Alle schmeißen mal Ideen rein, ja, wichtigste Regel beim Brain Storming, kennst du hoffentlich, es gibt keine Kritik, das heißt, egal was genannt wird, es wird alles aufgeschrieben und das führt dazu, dass wir ganz viele coole Anforderungen wahrscheinlich definieren, die wir sonst gar nicht gedacht hätten. Einfach als Kreativitätstechnik ist das eine tolle Sache, wenn man überhaupt noch nichts hat und anfangen will, ist von Brain Storming echt super gut geeignet. Nächste Methodik geht auch so ein bisschen in die Richtung einer Kreativitätstechnik mein Mapping, auch das kann man machen, sich so ein bisschen strukturiert von einem Ausgangspunkt am besten dem Projekt in der Mitte los hangeln und so ein paar Äster aufmain, wie so ein Baum und immer weiter verschachteln. Also was wir sehe, ihr sollt neuen Server aufsetzen, dann habe ich vielleicht die Frage, welches Betriebssystem, welche Internetanwendung, keine Ahnung, dauer der Laufigkeit oder keine Auffällsicherheit oder was wir immer wieder einfällen. Und das kann ich dann immer weiter verschachteln und immer weiter vertiefen und so komme ich vielleicht auch noch auf neue Anforderungen. So, da waren schon fünf, wir müssen mal weiter, 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. Und wenn man das damit so ein fancy englischen Begriff bezeichnen will, könnte ich das Apprentice singnen. Apprentice kennst du vielleicht, da ist quasi da englische Wort für Azubi, passt nicht so 100%ig, aber Apprentice ship ist so das englische Wort, was am besten auf die deutsche Ausbildung eigentlich passt. Und das bedeutet einfach, du setzt dich daneben und das gilt ja nicht nur für dein Appresprek, weil du da ja noch Azubi bist, sondern auch später, du kannst dich einfach neben den Anwender setzen und mal gucken, was macht er denn so? Und so tun, als wärst du dir Azubi. Das heißt, der soll dir sagen, mach mal die und die Aufgabe und der zeigt dir dann, wie das in dem System funktioniert und du gehst bei dem quasi in die Lehre, in die Ausbildung und guckst dir das mal an. Und dabei wirst du ganz viel Fachlichkeit wahrscheinlich lernen, denn wenn zum Beispiel der Kollege einfach sagt, klick jetzt mal da und macht das und das und da trägst du 23 in das Feld ein, dann ist deine Aufgabe zu fragen, warum, wo kommt die 23 her, was ist das für ein Wert? Was heißt denn das? Und so kommst du immer tiefer in die Fachlichkeit und verstehst es dann hoffen, die ja irgendwann was da eigentlich zu tun ist und kannst daraus dann die Anforderungen ableiten. So wenn du es jetzt nicht ganz so invasiv machst, also nicht so in die Interaktion gehen willst und dich einfach wirklich stumpf auf ein Stuhl daneben setzt und zu kookst, dann könnte man das als Feldbeobachtung auch als eine weitere Methode benennen. Ist im Prinzip mehr oder weniger das selbe, guckst dir an wie Leute arbeiten, aber einmal bist du ein bisschen aktiver und mach selber mit, ich geh in die Ausbildung, Apprenticeing und einmal guckst du wirklich als externer Beobachter zu, das ist dann die Feldbeobachtung. Ja, dann habe ich noch einen der relativ häufig benutzt wird, gerade zu Beginn eines Projekts und zwar ein Uhr. Wir setzen uns alle mit vielen Stakeholder zusammen einen Tisch und diskutieren einfach mal fangen wir an, er arbeiten mal was. Schreiben vielleicht gemeinsam das Lasten heft auf. Also wirklich mit mehreren Leuten, gemeinschaftlich daran arbeiten in Form eines Workshops. So, dann habe ich noch zwei Schöne. Wenn wir ein altes System ablösen wollen, wenn es schon was gibt. Das ist natürlich für uns als Entwickler zum Beispiel immer schön. Wir können einfach gucken, was macht das alte, probieren wir das nach, bin fertig. Ja, so schön, wir erst. Das funktioniert natürlich auch ganz häufig nicht. Aber wenn ich das mache, dann brauche ich auch einen schönen Namen dafür. Und das könnte man Systemarcheologienen. Das heißt, ich gucke mir das alte, das Ur-alt-System an und schau, was kann das denn? Und schon habe ich meine Anforderungen für das neue System. Ja, ergänzend natürlich um alles, dass nicht so gut funktioniert, was besser laufen soll, keine Frage. Aber anhand des alten Systems kann man viel ableiten. Ja, und letzter Punkt. Tatsächlich, manchmal hilft es auch, wenn man einfach red. Das heißt, ich überlege mir, was könnte den der Fachbereich wollen? Was könnte denn der Anwender am Ende mit der Anwendung machen wollen? Also einfach mal drauf losraten und gucken, was bei rumkommt. Gut, das waren jetzt 10 Möglichkeiten, um Anforderungen zu kommen. Ich fasse mal zusammen. Interview, Selbstaufschreibung, Fragebogen, brainstorming, Mindmapping, Apprenticing, Feldbeobachtung, Workshop, Systemarcheologi und Raten. Das waren auch noch mal 10 Stück, die dir vielleicht ein bisschen Anregungen geben. Denn ja, oft ist es gar nicht so einfach für den Abschlussprojekt zum Beispiel, die Leute alle zu fassen zu kriegen und direkt mit den Leuten zu reden. Da musst du vielleicht auch mal eine Mail schreiben und fragen, was die wollen und schwupp ist, dass eine Selbstaufschreibung. Und so weiter. So, Wahnsinn. Jetzt wissen wir, was Anforderungen sind, wie die sich gliedern lassen. Dann wissen wir, wie wir eine Fragen müssen nach Anforderungen. Das sind unsere Steakhäule. Und jetzt haben wir auch noch 10 Methoden, wie wir die Anforderungen aus den Leuten raus kriegen. Das ist ja Wahnsinn. Da können wir fast direkt loslegen. Aber ganz so einfach ist es dann doch nicht. Denn wir haben auch noch Anforderungen an diese Anforderungen. Die sollten nämlich bestimmt formuliert sein, damit wir als Umsetzernach auch was damit anfangen können. Es gibt nämlich nichts schlimmeres als wenn ein Benutzert zum Beispiel sagt, ich hätte gerne, dass die Anwendung intuitiv bedientbar ist. Und da drehe ich auch immer völlig durch, wenn ich das zum Beispiel in Lasten heften, von Prüfflingen sehe und das schreiben sehr viele sehr häufig. So standert es jetzt wie, muss dem Corporate-Design der Al, der Firma entsprechen. Und soll intuitiv bedientbar sein. Und das sind so Anforderungen, wo ich mir denke, Leute, das kann ich euch erinnert sein. Denn das ist absolut unkonkret. Was heißt das intuitiv bedientbar? Das kann dir kein Mensch definieren. Das muss viel genauer sein. Und da, wo wir uns jetzt mal angucken, welche Anforderungen es an diese Anforderungen gibt, damit wir die auch verstehen als Entwickler zum Beispiel. Wenn ich jetzt zu einem Entwickler gehe und sage, hier kommt die Anforderungen vom Fachbereich. Macht die Anwendung mal intuitiv bedientbar. Dann sagt der, keine Ahnung, was ich machen soll. Wenn ich von links nach rechts, Skrolle, wird irgendwas größer oder kleiner. Oder soll ich überhaupt die Maus benutzen? Tastatur soll alles auf Deutschenglisch übersetzt werden, damit's intuitiv, also was heißt intuitiv bedientbar? Kann kein Mensch verstehen. So, damit wir nicht solche Probleme kriegen, gehen wir jetzt mal so ein paar Anforderungen durch. Auch hier kannst mal wieder mitraten. Ich habe acht Stück mitgebracht. Acht Anforderungen an Anforderungen. Fällt fallen die ein paar ein? Macht gern Pause, denk mal nach. Und jetzt gucken wir uns das Ganze als Ergebnis an. Nummer eins, Anforderungen an Anforderungen. Die müssen eindeutig sein. Also nicht mehr deutig, also kein Interpretationsspielraum bieten. Wenn ich sowas sage, wie ein Rioberflächer könnte blau oder rot oder vielleicht auch gelb sein. Ja, dann habe ich als Entwickler oder als Umsätzehrjahr die Wahl. Und wenn der Endanwendung am Ende sind, dann doch sagt auch eigentlich hätte ich doch lieber gelb gehabt. Dann war es halt nicht eindeutig genug. Und der das umsetzt, wusste halt nicht genau, was er tun soll. Das ist schlecht. Denn dann weiß ich auch am Ende gar nicht, ob ich das richtig gemacht habe oder nicht. Wenn ich die Wahl habe zwischen mehreren Alternativen, ist ja alles richtig. Gut, dann machen wir weiter Atomar. Ganz wichtig ist, dass die Anforderungen nicht weiter teilbar ist. Das bedeutet ja Atomar. Genau wie aus der Datenbank, kennst du auch Atomare, Werte, sollte es nur geben in der ersten Normalform. Einfach, weil sich dann Werte nicht mehr aufteilen lassen in verschiedene. Wie zum Beispiel die Adresse, in Straße und Postleizahl. Das sollte auch für Anforderungen gelten. Ich will die nicht mehr unterteilen können. Warum? Warum muss das so sein? Ja, angenommen. Ich habe zwei Anforderungen in einer versteckt so, keine Ahnung. Angenommen. Die Anwendung soll fetten Text ermöglichen und kursiven Text. Bleiben wir wieder bei unserer Werteanwendung. Was ist denn jetzt, wenn ich den fetten Text implementiert habe, aber den kursiven Text nicht? Dann ist die Anforderungen ja nicht erfüllt. Weil die Hälfte der Anforderung ist ja nicht umgesetzt. Aber was ist jetzt, wenn die kursive Anforderungen sich einfach gar nicht umsetzen lässt, aus welchem Grund auch immer, dann ist die gesamte Anforderung nicht umgesetzt. Muss der Kunde jetzt dann nicht zahlen, weil die Anforderungen ist ja nicht fertig. So, das ist schwierig. Also von daher eine Anforderung muss einen einzigen Punkt enthalten und nicht mehrere, damit ich genau entscheiden kann, ist das jetzt umgesetzt oder nicht. Und dann sind wir automatisch vom nächsten Punkt nämlich klein. Atoma heißt ja schon nicht weiter teilbar. Atom ist so, da ist klein, was es gibt. Wenn man jetzt mal von Quarks und so weiter absieht. Aber lange Zeit waren die ja nicht teilbar. Und das heißt automatisch, dass die Anforderungen klein sind und nicht riesengroß. Also eben genau nicht so, was wie absolut unspezifisch soll intuitiv bedienbar sein. Sondern vielleicht, was könnte da jetzt ein konkretes Beispiel sein. Wenn ich mit der Maus über die Eingabe box havere, soll da als Tooltipp stehen, was ich da eingeben muss. So, das wäre vielleicht eine konkrete Beschreibung der Hilfe. Und das müsste ich jetzt vielleicht über runterbrechen für jedes einzelne Eingabe fällt. Ja, man müsste ja so sagen, hier, da wo der Vorname steht. Wenn ich damit der Maus drüber havere, soll da stehen der Vorname des Kunden. Ja, und das wäre eine atomare eindeutige kleine Anforderung, die ich dann umsetzen kann. Warum soll die klein sein? Was bringt mir das? Na ja, irgendwie haben wir diese Anforderungen ja umsetzen. Und da kommen wir gleich zum nächsten Punkt. Die müssen nämlich meistens geschätzt werden. Und das muss du ja zum Beispiel auch in deiner Projektplanung machen. Du sagst, Mensch, ich muss hier ja programmieren. Dafür brauche ich 42 Stunden. Oder, Mensch, ich muss hier ein Windows Server installieren. Das dauert drei Stunden. Und das musst du vorab schätzen und so gucken, ob du die Zeit einhältst. Und je größer die Anforderung ist, um so schwieriger ist es das zu schätzen. Wenn du jetzt mal das Beispiel vom Tooltipp dir eben anguckst, für ein Feld, ein Tooltipp mit diesem Text zu definieren, da kannst du, wenn du ein bisschen Entwicklungserfahrung hast, genau sagen, okay, das dauert zwei und ein half Stunden. Wenn aber sowas steht, wie macht die Anwendung intuitiv bedienbar? Dann hast du überhaupt gar keine Ahnung, wie lange das dauert, weil du gar nicht genau weißt, was alles zu tun ist. Das heißt, die Anforderung muss klein sein und dadurch wird sie automatisch schätzbar. Und das ist eben ganz wichtig für die Projektplanung, damit überhaupt weißt, ob du das Projekt bis zum gegebenen Termin überhaupt umsetzen kannst. Ja? So dann wäre es noch ganz wichtig, dass die Anforderungen unabhängig voneinander sind. Denn sonst, ja, bist du in GA1, ist der schriftlichen Prüfung für Anmöngse-Mickler und zeichnet es irgendwelche Netzpläne, denn Anforderungen, die voneinander abhängen und in einer gewissen Reihenfolge, wie es jetzt werden müssen und so weiter, das ist immer ganz besonders schwierig für die Planung. Am schönsten wäre es, wenn deine Anforderungen nichts miteinander zu tun haben und du völlig losgelöst an den verschiedenen Anforderungen gleichzeitig arbeiten kannst. Ja? Das wäre super, weil du dann einfach keine Abhängigkeiten hast, die die Prickplanung erschwerten. Du musst nicht im Kopf haben, was zuerst gemacht werden muss, was danach. Und wenn das nicht funktioniert, geht das andere nicht, unsere weiter. Das wäre super, wenn die nicht abhängig voneinander wären. So, nächster Punkt, den wir noch behandeln sollten, die sollten auch nützlich sein, die Anforderungen. Ja, sollte irgendwas bringen. Das heißt, es sollte nicht einfach irgendwas, weil ich mir, weil ich gerade Lust hab, irgendwie etwas ausgedachtes sein, sondern es sollte ein Mehrwert bieten. Und da habe ich ein schönes Beispiel aus meiner eigenen Praxis, ich hatte wirklich mal die Anforderungen aus dem Fachbereich, wo ich eine Anmöngung entwickelt habe, wo dann die Anforderungen kam, der Hintergrund der Anwendung soll bitte Rosa sein. Da habe ich mich gefragt, so, warte, warum soll der Rosa sein? Was da denn jetzt los? Und dann habe ich mal hinterfragt, ob das denn nützlich ist. Sollte das wirklich Rosa sein, weil die Dame, in diesem Fall, was da so eine Dame, da das einfach schön fand oder was war der Hintergrund. Und als ihr dann tatsächlich mal angerufen habt, und befracht, habt ihr mal Rosa hintergruen, was da denn los? Da war die Antwort einfach, ja, nun, ich bin die ganze Zeit auf einer Testumgebung und der Produktionsumgebung unterwegs. Und ich würde gerne die Produktionsumgebung Rosa machen, damit ich genau weiß, wenn ich da was eingebe, muss ich aufpassen. Wenn ich hier auf Löschendrücke dann lösche ich echte Kunden. Und das darf natürlich nicht passieren. Also, das heißt, der Hintergrund war es ging nicht um die Farbe, sondern es ging echter um die Produktionsumgebung, deutlich hervorzuheben, damit man keine Fehler macht. So und das war der eigentliche, die eigentliche Anforderung. Geoist hat in Form der Farbe, weil der Fachbereich sich halt gedacht hat, so ist es am offensichtlichsten, wenn es rot ist, springt es mir ins Auge, ich kann keine Fehler machen. Jetzt mal übertragen sind. Ja, und das fand ich super Beispiel für diese Nützlichkeit, der Anforderung. Und so könnte ich es dann aber ein bisschen umformulieren, weil es war technisch einfach gar nicht möglich, das in der Farbe zu machen, was so ein alt Anwendung. Das heißt, wir mussten das anders lösen. Und dann konnten wir zum Beispiel, ich weiß nicht, den Text ein bisschen fett machen oder irgendwas blinken lassen oder sonst irgendwas, damit einem das trotzdem ins Auge springt. Denn wenn du jetzt so eine harte Anforderung hast, Fachbereich sagt, so das muss aber rot. Ja, und du bist aber in der Anwendung, wo du gar nicht mit Farben arbeiten kannst, was was sehe ich, eine Konsolenanwendung oder so was. Und du kannst diese Anforderung nicht umsetzen. Ja, dann stehst du blöd da. Ja, das heißt, frag mal nach, was wirklich der Nutzen dieser Anforderung ist. Und dann kannst du vielleicht auch Alternativen vorschlagen. Die technisch dann auch wirklich umsetzbar sind. So, und stichwort umsetzbar, das ist leicht der nächste Punkt, diese Anforderungen an Anforderungen, nämlich, die müssen testbar sein. Du musst eindeutig sagen können, ob du die Anforderung umgesetzt hast oder nicht. Angenommen, die Anforderungen wäre, der Hintergrund muss rosa sein, wenn du die Anwendung aufmachst, und die hatten blauen Hintergrund, dann ist die Anforderung nicht umgesetzt. Das heißt, der Test schlägt viel und der Kunde muss halt nicht bezahlen, auf Deutsch gesagt. Von daher überlegt dir immer gleich bei den Anforderungen, wie kannst du den Nachweisen, dass du es auch umgesetzt hast? Also, wenn da jemand sagt, das ist ein Thema, muss aber schnell sein. Dann ist schnell etwas, was du nicht belegen kannst. Wenn du zum Beispiel unter schnell verstehst, 500 Millisekundenreaktionszeit und der Kunde ist aber gewohnt, im Echstzeitumfeld zu arbeiten, wo er eine Millisekunde braucht, dann ist er schon gewaltiger Unterschied. Das heißt, diese Anforderung ist einfach schlecht formuliert, die ist so nicht testbar. Schötersen müsste da so was stehen. Wenn ich einen Kunden öffne, muss die Maske in 120 Millisekunden angezeigt werden. So, das ist eindeutig messbar und somit testbar. Und dann kann der Kunde sagen, ja oder nein, aber es kann nicht zu irgendwelchen Diskussionen kommen, weil Dinge unterschiedlich interpretiert werden. Also, gleich mit der Zuschreiben zur Anforderung, wie man feststellen kann, dass sie auch umgesetzt wurde. So, ein letzter Punkt, das ist jetzt die Überleitung zum nächsten Thema. Die Anforderungen sollten einheitlich aufgeschrieben werden oder formuliert werden. Es geht bei unserer Anforderung nicht darum, dass wir einen Proza-Text schreiben, einen schönen Roman, der sich blumig liest, sondern Anforderungen sollen langweilig sein. Anforderungen sind immer gleich aufgebaut. Gleiche, Herr Satzbau, gleiche, keine Ahnung, Dinge an der gleichen Stelle. Einfach, weil wir hier meistens eine Riesenlisternanforderungen haben und wir nicht jedes Mal wieder darüber nachdenken wollen, was denn hier wohl gemeint ist. Wer ist denn hier vom Betroffen? Wie wichtig ist das? Was ist das, wie ich es messen kann, etc.? Wenn ich einen immer gleichen Aufbau der Anforderung habe, ist das alles automatisch abgedeckt. Und ich muss, wenn ich als Umsetzer mit die Anforderungen angucke, nicht jedes Mal neu überlegen, was den vielleicht gemeint sein könnte. Wo, was, wo ich, was finde, wo, was keiner an die Priorität steht und so weiter. Das heißt, es wäre sinnvoll, wenn wir Anforderungen so einheitlich wie möglich definieren, um eben keine Zeit zu verlieren bei der Interpretation. Dafür haben sich jetzt einige Methoden, etabliert, die man in der Praxis häufig anwendet um Anforderungen zu definieren und die möchte ich ja jetzt nächstes durchgehen. Allerdings noch mal ein kurzer Recap, was für Anforderungen an Anforderungen haben wir jetzt. Ich habe acht Stück mitgebracht, eindeutig, atomak, klein, schätzbar, unabhängig, nützlich, testbar, einheitlich. Das waren meine acht, vielleicht gibt es noch mehr. Ich glaube, mir reichen die auf jeden Fall. Aber wenn wir uns jetzt einige konkrete Maßnahmen angucken, um Anforderungen zu formulieren, werden wir einige dieser Punkte da auf jeden Fall wiederfinden und sehen, dass es ein Sinn hat, dass man sich daran orientiert. Diese konkreten Methoden, die ich mitgebracht habe, das sind einmal die sogenannten Snowcards. Dann habe ich User Stories und das Moskau-Prinzip. Es gibt noch ganz viele andere Möglichkeiten, aber ich habe mir die drei mal rausgepickt, weil ich die auch sehr häufig tatsächlich in Projektdokumentationen sehe von Prüflingen und ich finde die auch eigentlich ganz gut, sind schnell erklärt und gut verständlich und deswegen gehen wir die mal durch. Ich fange mal an mit dem "overkill", es sind die sogar ein Snowcards, die kommen aus dem volere Template. Das Ding ist schon zehn Jahre alt und perfekt ausgearbeitet. Das ist so ein Template, wo sich jemand hingesetzt hat und überlegt hat, was könnte es alles für Anforderungen an ein Projekt geben. Und das ist so ein Ding, wo das Inhaltsverzeihen ist mit den Überschriften irgendwie schon drei, vier Seiten lang ist und das sind alles nur Oberpunkte, um mögliche Anforderungen herauszufinden. Und ich mach mal nur ein Beispiel an etwas, woran du vielleicht noch nie gedacht hast, so physikalische Umgebungen deines Produktes. Könnte in bestimmten Projekten wichtig sein, angenommen, du sollst als Physi irgendwie ein Server installieren. Wenn du jetzt weißt, dass der Innerforschungsstation in der Art deaktisch stehen wird, dann solltest du vielleicht dran denken, dass das Ding auch bei Minusgraden funktioniert. Und das ist vielleicht nicht ganz so offensichtlich, wenn du das nicht weißt im Vorfeld. So, das ist nur ein Beispiel. Es gibt noch viele weitere Punkte in diesem Template. Es ist also unumgelogen. Das Inhaltsverzeihen ist das mehrere Seiten lang. An was man alles denken könnte bei solchen IT-Projekten. Und das Ding will ich jetzt aber nicht in bir Teil durchgehen, weil da kann man das wirklich für Großprojekte, da kann ich mich jahre mit beschäftigen, nur diese Anforderungen aufzunehmen. Das führt aber sehr selten zum Erfolg. Stattdessen wollen wir das vielleicht etwas Agile machen und etwas Kürzer und Knackiger. Und du kannst diese Snowcards oder Volere-Karts mal online angucken. Da sind tatsächlich Felder für alle diese Punkte, die ich gerade genannt habe, der Anforderungen an Anforderungen drin. Eindeutigkeit zum Beispiel. Jede Anforderung bekommt eine Idee. Schätzbar. Es steht direkt auf der Karte drauf, wie lange ich brauche zum Beispiel. Unabhängig. Es gibt Felder für Vorgänger nach Folger, Konflikte etc. Testbar. Es steht direkt auf eine Anweisung, wie ich testen kann, dass das Ding umgesetzt wurde. Und eine Einheitlichkeit auch, weil die Karten sehen immer gleich aus. Also alle diese Punkte sind quasi mit diesem Template umgesetzt. Aber es ist einfach mega aufwendig, die alle aufzuschreiben. Ich habe es tatsächlich mal in dem Projekt gemacht, in dem Studentenprojekt. Haben wir für eine Anwendung wirklich solche Karten aufgeschrieben. Alle diese Punkte ausgefüllt. Wir hatten glaube ich 60 Anforderungen. Ich weiß nicht, wie viel Stunden wir da drin gesessen haben, diese Karten auszuführen. Muss dann wirklich für jede Anforderung genau so eine Idee vergeben. Okay, das kann so ein System. Aber diese Testbarkeit aufschreiben. Diese ganzen Sachen einhalten. Das heißt, wir haben wirklich sehr viel Zeit rein gesteckt und ganz ehrlich, am Ende hat da kein Mensch mehr reingeguckt. Das ist einfach für die Halded produziert. Und meistens ist es ja auch so Software und IT allgemein. Heutzutage arbeiten wir eher agil. Genau vor dem Hintergrund, dass diese ewig lange Planungsphase sowieso meistens für die Katze ist, weil am Ende doch keine mehr drauf guckt oder sich einfach während der Arbeit schon die ganzen Anforderungen geändert haben. Ich habe mal eine schöne Zahl gehört, dass sich in einem IT-Projekt oder allgemein in Projekten in einem Monat ungefähr 2% der Anforderungen verändern. Was bedeutet das? Ganz extrem. Zum Jahreswechsel gibt es ein neues Gesetz. Das heißt vielleicht andere Anforderungen kommen in meinen Projektein oder Sachen von denen nicht ausgegangen bin, sind auf einmal anders. Oder der Kunde entscheidet sich um. Will jetzt doch nicht mehr grünen, sondern rot haben. Oder es gibt eine neue Marketingstrategie und auf einmal muss alles auf Englisch gemacht, währendestellt auf Deutsch. Oder oder oder. Und im Durchschnitt 2% der Anforderungen pro Monat. Das heißt, nach einem Jahr kann ich einen Viertel meiner Anforderung schon mal wegschmeißen oder neu machen. Oder das hat sich alles geändert. Also, das heißt, jeden länger ich für diese Planung brauche, umso größer ist die wahrscheinlich gar nicht, weil sie die Hälfte von wegschmeißen kann, weil sich alles geändert hat in der Zwischenzeit. Und wir wollen, wir gerade in der Software-Inwicklung, schneller etwas sichtbares produzieren, um diese Anforderungen zu überprüfen. Und wenn sich die Anforderungen ändern, reagieren wir flexibel darauf, oder eben agil in diesem um das Wort zu benutzen. Und planen aber uns nicht Ewigkeiten zu totek, bevor wir endlich mal was auf die Straße bringen. Und in dem Projekt war das eben genauso, ganz viel Zeit investiert. Und am Ende hatte sich eh die Hälfte davon erübricht. Und ja, wir haben es ganz umsonst gemacht. Also die Zeit hat uns sparen können. Aber von dieser Karte finde ich noch eine Sache ganz cool und die würde ich gern hier noch einbringen. Und zwar, wenn man sich die Karten mal anguckt, da gibt es so zwei Bereiche, die man mit Punkten bewerten kann und zwar die "Customer's Satisfaction" und die "Customer's Satisfaction". Also einmal die Zufriedenheit des Kunden mit dieser Anforderungen und aber auch noch mal zusätzlich die Unzufriedenheit des Kunden mit dieser Anforderungen. Und das fand ich damals so interessant und ich glaube, das finde ich auch, ja, ich finde es auch heute noch ein hanges Sand, deswegen jetzt sehe ich es hier. Warum soll man das unterschiedlich bewerten? Also du kannst ja es zu vorstellen. Es gibt einen Punkt, Kunden zufriedenheit. Die kannst du bewerten, was wir sehe ich von 1 bis 5. 5 heißt, der ist super zufrieden und 1 heißt, der ist nicht so gut zufrieden. Und deshalb, dass das Gleiche gibt es noch mal für die Unzufriedenheit. Jetzt kann man sich halt fragen, was soll das Ganze? Und die Idee ist jetzt, dass es Anforderungen gibt, die den Kunden, wenn ich sie umsetze, super zufrieden mache. Ja, da kriegt ja vielleicht eine 5 und wenn ich die nicht umsetze, interessiert sie aber nicht. Und das ist genau so etwas, was ich mit diesen beiden Skalen dann darstellen kann. Angenommen mich setze es um, kriegt eine 5 für zufriedenheit. Der freut sich total, dass ich sie umgesetzt habe. Aber wenn ich es nicht umsetzen würde, wäre mir auch nicht böse. Das sind so diese nice to half features. So, keine Ahnung. Der Text soll fett und kursiv sein. Joa, das ist eine Standardanforderung. Wenn das funktioniert, ist ganz nett. Wenn es nicht funktioniert, haut es mir aber um die Ohren. Das ist genau das Gegenteil. Das heißt, Kastemas Satisfaction wäre gering, wenn ich es umsetze, weil es ist halt standard. Aber wenn ich es nicht umsetze, fehlt ihm das total und der haut es mir um die Ohren. Das wäre das Gegenteil. Also wir haben einmal nice to half und wir haben auch die absoluten Standard features. Die müssen einfach da sein, sonst knall es. Und das kann man sehr gut mit diesen beiden Skalen dann ausdrücken. Wenn das mal so ein bisschen vergleichs mit einem anderen Bereich, der auch für die Ausbildung wichtig ist, nämlich der Mitarbeiter Motivation, da kennst du vielleicht die Begriffe der Motivaturen und der Hygiene-Faktoren. Und genau das ist im Prinzip das hier dargestellt. Motivaturen kennst du mit Geldvedeln und dann fängt der Mitarbeiter an zu arbeiten. Der freut sich, dass er Geld kriegt. Super. Das nicht kriegt, ja gut er kriegt er sein Gehalt, also ist nicht schlimm. Das wäre der Motivator. Ein Hygiene-Faktor ist etwas, was ihm nicht motiviert, wenn es da ist, aber wenn es nicht da ist, macht es ihm mega-demotiviert. Mein Beispiel ist immer ein VC. Wenn ich in einer Firma arbeite, wo es keine Toilette gibt, dann werde ich ganz schön unzufrieden sein. Aber wenn es immer noch Firma eine Toilette gibt, sage ich nicht, geil, was für ein toller Arbeitgeber, sondern es ist einfach Standard. Und genau dieses Prinzip kann man mit diesen beiden Skalen auf meinen Anforderungen übertragen, um zu sagen, was macht den Kunden besonders glücklich? Und was macht den Kunden besonders unglücklich? Und das können unterschiedliche Dinge sein. Übrigens falls du gerade im Hintergrund irgendwelche komischen Geräusche hörst, das sind meine Hunde, die gerade eine wilde Phase haben. Wir waren gerade draußen und die beiden jetzt hier ein bisschen. Also von daher nicht wundern, wenn es komische Geräusche gibt. Aber zurück zum Thema, also dieses No-Cards sind toll, haben auch ein paar coole Ideen drin, finde ich super, guck sie dir gerne an, benutzen in der Praxis, würde ich sie nicht viel zu auffällig. Ja, schon dessen nehmen wir mal zwei andere Möglichkeiten, die kurz und knackig sind, trotzdem die wichtigsten Punkte der anderen. Forderungen an Anforderungen enthalten und sich in der Praxis aber auch durchhose Tablet haben. Und wir fangen mal an mit der User Story. Die kommt jetzt eher aus dem agilen Kontext, zum Beispiel aus Scrum, da arbeiten mit User Stories, wo mit man also User Story sind eine Möglichkeit, die Anforderungen zu definieren. Und User Stories sind relativ kurz um knackig und zwar ist das so eine Attemplate, wie man seine Sätze aufbaut, um die Anforderungen zu beschreiben. Und zwar, wenn ich das mal auf Deutsch mache, als Rolle möchte ich gerne Funktionalität damit ich Begründung. Und ich mach das mal auf Englisch. "As a bank client, I would like to lock into the bank's Internet banking in order to check my account balance." Also, als Kunde der Bank, das ist die Rolle, möchte ich mich in das Internet banking einloggen, einloggen, das ist die Funktionalität, damit ich mein Kunde standabfragen kann. Das ist die Begründung der Grund. Und die drei Sachen gehören immer minimum zu einer User Story. Jetzt die Frage warum. Die Rolle ist interessant, daran kann ich festmachen, wie wichtig ist das. Also wenn der Kunde das will, ist das vielleicht wichtig, wenn das ein Audi Tour will, ist das vielleicht nicht so wichtig. Je nachdem was von Unternehmen man arbeitet. Dann die Funktionalität, die beschreibt, was ich eigentlich implementieren soll. Also lock in Funktionalität. Und das letzte, das ist quasi mein, das heißt in der Snowcard Fit Cry-Tour. Das ist das Ding, an dem ich festmache, ob ich es umgesetzt habe. Also die Testbarkeit. Daran kann ich prüfen, passt es oder nicht. Und zwar in diesem Fall möchte ich meinen Konto standabfragen. Das ist die Begründung des Kunden, was ich gerade machen will. Und warum ist das wichtig? Warum darf ich diese Begründung nicht wegg lassen? Ich kann noch mal sagen, als Kunde möchte ich mich einloggen können. So das kann ich auch umsetzen. Die Frage ist aber, warum will der sich denn einloggen? Weil diese Funktionalität ist in diesem konkreten Fall einfach nur Mittel zum Zweck. Der muss sich einloggen können, damit er seinen Kunde standabrufen kann. Was er eigentlich will, ist, er will wissen wie viel Geld er offenkonto hat. Das ist sein Ziel. Und jetzt ist die Frage, wenn ich das aus irgendeinem Grund nicht implementieren kann zum Beispiel diesen Lock-Innen. Aber ich weiß, dass das Ziel ist, diesen Kunde standab zu fragen, dann finde ich ja vielleicht eine andere Möglichkeit. Dann kann ich einen Vorschlag machen, wie es stattdessen geht. Vielleicht kann ich mir auch einfach seinen Kunde stand PSMS aufs Handy schicken. Da muss er sich nicht für einloggen, aber er hat trotzdem sein Ziel erreicht, nämlich sein Kunde standab gefragt. Das ist das Schöne an diesen User Stories. In dieser kurzen Knappigen, in diesem kurzen Knappigen Aufbau sind ganz viele Dinge ableitbar. Eine Priorität kann ich ableiten. Ich weiß, wie ich es testen kann. Ich weiß, ob es wichtig ist oder nicht. Ich habe schon gesagt, Priorität. Ich weiß aber auch die Funktionalität, also die Funktionalanforderung steckt mit drin. Ich weiß, dass es nützlich zum Beispiel ist. Ich weiß, wie es testen kann, etc. Also coole Sache lässt sich auch so runter schreiben und vor allem haben auch alle Anforderungen die gleichen Aufbau, denn es ist ja immer Rolle, Funktionalität, Begründung. Liesst sich also immer gleich. Ich weiß also genau, wo ich gucken muss, wenn ich wissen will, wie ich es testen muss. Aber ich kann mir die Begründung ranken. Außerdem kann ich diese kurzen Sätze auch wunderbar auf so kleine Kartakarten schreiben und dann an so coole Camembert-Boards an die Wand heften. Also kurz knack ich trotzdem präzise und alles wichtig drin. Find ich eigentlich ein geiles Ding. Deswegen ist es auch so interessant und hat sich auch in ergeben Polken so durchgesetzt. Also in Scrammprojekten oder Camben arbeitet man halt mit diesen User Stories. Das ist da der Standard quasi für die Anforderungsdefinition. So, letzter Punkt, den ich häufig in so klassisch erem Projekten eher sehe, damit kann ich aber auch gut leben. Das ist das Moskau Prinzip. Moskau in der englischen Schreibweise, also M-O-S-C-O-W. Und das Moskau Prinzip heißt deswegen so, weil die vier Buchstaben M-S-C und W für die Satzanfänge stehen, die muss gleich angucken. Und die beiden O-S sind nur eingebaut und man es netter aussprechen kann, eben Moskau und nicht Miskwe. Und die M-S-C und W stehen für mast, shut, cut und wound. Und dann ist die Idee, die Anforderungen immer so aufzubauen, dass System muss sollte, kann oder wird nicht irgendetwas tun. Also zum Beispiel, das System muss dem Kunden ermöglichen, sich einzulongen. Das System sollte die Schriftgröße veränderbar anbieten. Das System könnte eine Rote Oberfläche haben. Und als letztes, das System wird nicht Daten unbefugend zugänglich machen. So, damit kann man jetzt auch schreiben, auch in gewisser Form priorisiert natürlich, was das Systemen alles so können muss. Und muss, das mast, sind eben die absoluten Muskriterien, KO-kriterien kommen auch sagen, wenn das nicht erfüllt ist, ist das Produkt oder das Projekt nicht umgesetzt. Das Schutt ist so ein bisschen, ja, ich will schon fast also nice zu helfen noch noch nicht, aber so wäre ganz gut, wenn das umgesetzt ist. Aber wenn es nicht klappt, ja okay, würden wir trotzdem bezahlen, aber wer schon echt gut wenn es umgesetzt wäre. Und das Kutt, das sind dann die Wunschkriterien, also so ein bisschen nice to have, wer halt mega cool, wenn ich irgendwie die Hintergrundfarbe ändern könnte, aber ja gut wenn es nicht geht, dann ist das halt so. Und das won't, darauf möchte ich jetzt einmal genau eingehen, also das System wird etwas bestimmt bis nicht tun. Da schreibe ich jetzt nicht einfach alles auf, was System nicht machen soll. Also zum Beispiel, ich soll ein Auto bauen, das Auto wird nicht fliegen können, so oder das Auto wird nicht schwimmen können. So, ne, das wäre natürlich so viel, was dieses Projekt nicht umsetzen wird, das werden wir nicht alles aufschreiben, sondern wofür ist dieser Punkt da? Es geht explizit darum Dinge auszuschließen, die man, wenn man das nicht aufschreiben würde, eventuell vermuten könnte, dass das System es trotzdem umsetzt. Also ich nehme mal auch mal das Beispiel online banking, wenn ich explizit sage, das System wird mir keinen lock in ermöglichen, dann weil ich das zum Beispiel irgendwie anders löse oder so, SMS konnte stand, ja, dann ist das natürlich wichtig zu wissen, denn wenn ich jetzt anfange ein banking-System zu bauen, gehe ich davon aus, dass der Kunde sich einlocken wird, weil ich einfach bei allen 59 anderen Banken, die es gibt, genau das habe. Wenn ich jetzt aber ein anderes System baule und ich will das explizit nicht so machen, wie der normale Kunde annehmen würde, dass es gemacht wird, dann sollte ich das am besten aufschreiben, ja, das ist einmal, wenn ich zum Beispiel Sachen, die sonst intuitiv anders gemacht würden, wenn ich die nicht machen will, schreibe ich das auf. Aber ich kann mit diesem Punkt auch den Scope-Disprojekt definieren und zwar sagen, was ich in diesem Projekt explizit nicht umsetzen werde, was noch irgendwann später kommt, aber nicht im Rahmen dieses Projekts, denn auch du, wie es sicherlich bei einem Abschlussprojekt noch tausend Ideen haben, was du noch alles dazu machen kannst, aber du hast einfach keine Zeit oder du hast kein Geld oder du kannst es nicht in der gewünschen Qualität liefern zum Beispiel. Und es wäre wichtig, dann zu sagen, ich weiß, dass das gewünscht ist und dass wir super toll, wenn wir das für den Fachbereich noch machen könnten, machen wir auch, aber nicht jetzt, sondern erst wenn wir mit dem Projekt fertig sind, um den Scope halt kleiner zu machen, damit das Projekt überhaupt erfolgreich zum Ende bringt. Und da wäre es wichtig, so was aufzuschreiben, damit dann eben nicht irgendwie der Fachbereich dann doch zum Entwickler geht und sagt, ja, wir hätten ja noch gerne dies und das und dann so diesen Feature-Creep zu verhindern, das heißt, je länger ich das Projekt mache, um so mehr Features kommen dazu, das ganz normal, weil die Leute so ein bisschen auf ein Geschmack kommen, Fachbereich sagt, auch das ist ja cool, das ist auch okay, jetzt will ich auch noch dies und das, ja und dann wird das Projekt nie zum Ende kommen und das ist schlecht, es muss ein definierten Enzallpunkt geben, deswegen aufschreiben, was noch alles nice-to-have wäre, aber definitiv nicht umgesetzt wird in diesem Projekt, dafür kann man das WOMENT auch gut benutzen. Gut, jetzt haben wir drei Verfahren kennengelernt, also die mega umständlichen, aber auch sehr detaillierten Snowcards, dann gibt es die User Stories, die ich super finde, auch gerade in agieren Projekten sehr etablier sind und das Moskauprinzip, was quasi eine Präuzierung schon eingebaut hat und in so klassischen Projekten oder sind wir ganz ehrlich auch in so kleinen Projekten wie zum Abschussprojekt, ganz ehrlich, das sind 40 Stunden, bisschen mal so 80 für die Anmängungsentwickler, da brauchen wir kein 300-seitiges Lasten heftet, ist mal völlig klar, ja, von daher kann man auch eventuell sagen, das System muss 1,4, es sollte 4,5,6 und könnte und wie jetzt nicht, und dann habe ich auf eine halben Seite mein Lasten erfährdig, das kann sein für so ein IT-Berufe Abschussprojekt, das ist völlig okay, bei so einem kleinen Umfang. Von daher, ich muss also nicht mit dem Riesenhammer kommen, kann ich natürlich alles machen und wenn das Unternehmen das sowieso so macht, würde ich mich auch daran langhangeln übrigens noch mal ein Tipp für dein konkretes Abschussprojekt, denkt dir dir nicht was Neues aus, sondern nehm einfach das, das Prinzip oder die Methode, nach der der Unternehmen auch jetzt schon arbeitet, ja, zum Beispiel wir arbeiten mit einem Ticketsystem für solche Projekte, werden halt Tickets aufgemacht für die einzelnen Anforderungen, dann solltest du das für ein Abschussprojekt auch nutzen, ja. Und jetzt nicht einfach, weil du ein Podcast gehört hast, dass es noch geile User Stories gibt, das ist jetzt alles auf links drehen, ja, weil die werden ja sicherlich im Fachgespräch auch Fragen dazu gestellt oder vielleicht zumindest und wenn du die gar nicht beantworten kannst, weil du dir das die Methode einmal kurz, ja, also sehe ich hier eine Stunde im Podcast angert hast und dann meintest du musst das unbedingt so machen, dann kannst du natürlich im Fachgespräch nicht so gut auf Fragen dazu anwohnen. Deswegen würde ich dir das nicht empfehlen, machst ja dessen einfach das, was du gewohnt bist zu tun, wie dein Unternehmen einfach arbeitet, ja. Sollte allerdings dein Unternehmen so arbeiten, dass ihr gar nicht mit Lasten und Flächenheft oder Anforderungen an sich arbeitet, dann würde ich es mir nochmal überlegen, denn in irgendeiner Form musst du die Anforderungen erfassen, das ist dein Job als Projekt Leiter deines Abschussprojekts. Von daher komme ich jetzt auch mal langsam ein bisschen zu Ende, wir haben ja schon eine Stunde hier geschnackt, du weißt jetzt einiges über Anforderungen, warum die wichtig sind, hast vielleicht ein paar Anregungen für dein konkretes Projekt bekommen, wen musst du fragen, wenn du weißt, wie du fragen musst, wie fragst du die, du weißt, wenn du die Anforderungen aufschreiben willst, wie du das tun kannst, worauf du achten musst und hast sogar noch ein paar konkrete Methoden, wie du die aufschreiben kannst, heute mitbekommen. Ich hoffe, das hilft dir bei der Vorbereitung auf dein Abschussprojekt und auch bei der Umsetzung nachher, aber auch für dich losgelöst davon be allen anderen Projekten, die du machst, denn Anforderungsermittlung oder Analyse ist immer ein wichtiger Bestandteil, wenn du da was falsch machst und nicht genau weißt, was der Kunde will, dann kannst du ihm auch nicht das liefern, was er haben will, dann wird es teuer oder er bezahlt nicht oder oder oder. Also, legt Wert auf die Anforderungen, das ist auch dein Job als Azubi, mindestens mal bei dein Abschussprojekt von daher wichtiges Thema und ich habe mir gerne die Zeit genommen, dass ihr mal ausführlich zu erklären. Du hast ein bisschen was mitgenommen. Wenn dir noch was zu einfällt zum Thema Anforderungsmanagement, Analyse, Aufnahme, wie ihr rummer du es nennen willst, dann schreibt mir gerne einen Kommentar zu dieser Episode. Du findest auch alles was ich erwähnt habe, natürlich wieder als Show Notes auf der Website unter IT-Berufepotcast.de/159 für die heutige 159. Episode. So, und mein Aufnahmprogramm ist gerade frisch über die einstundenmarke hinweg. Deswegen, glaube ich, habe ich heute genug erzählt, ich sage vielen vielen Dank für die Aufmerksamkeit und bis zum nächsten Mal. Tschüss!