Liegen die Anforderungen des Kunden für ein Microcontroller-Projekt vor, so müssen diese nach dem Wasserfall-Modell als nächstes analysiert, mit Realisierungsoptionen versehen und als Pflichtenheft dokumentiert werden.
Wird ein Microcontroller-Projekt nach dem Wasserfall-Modell entwickelt, dann müssen zunächst die Anforderungen aus Auftraggebersicht definiert und in einem Lastenheft dokumentiert werden. Welche Aspekte sollten hierbei erfasst werden?
Mit Einreichung der Projektanträge beginnt der zweite Prüfungsteil in den IT-Berufen. Bei den eingereichten Anträgen gibt es eine Reihe leicht vermeidbarer formeller und fachlicher Fehler, die hier gelistet werden. Außerdem gibt es einige subjektive Empfehlungen, die vielleicht helfen, den Projektantrag zu schärfen damit keine zeitfressenden Nachbesserungen nötig sind. Viele Punkte sind für alle Fachinformatiker*innen relevant, speziell zugeschnitten sind sie aber für die Fachrichtungen Anwendungsentwicklung und Daten- und Prozessanalyse.
Die meisten Auszubildenden nutzen in ihren Abschlussarbeiten das „Wasserfallmodell“ basierend auf einer Grafik, die Winston W. Royce als Beschreibung einer unbefriedigenden Ausgangslage herangezogen hat. Dass er daraufhin fünf wesentliche Schritte formuliert hat, die diesem Modell hinzugefügt werden müssen, um Risiken zu minimieren, ist über die Zeit scheinbar wieder verloren gegangen. Wir versuchen uns diesen fünf Schritten über das Originaldokument und Leitfragen zu nähern.
Gute Software braucht gute Dokumentation – ohne unnötigen Aufwand. Eine erste Anlaufstelle ist häufig die `Readme.md`-Datei in git-Repositorys. Aber: für wen schreibe ich die eigentlich? Was sollte, was muss da rein? Wie formatiere ich die Readme-Datei mit Markdown?
Mit Hilfe der Netzplantechnik lassen sich zusätzlich zur Abfolge- und Ressourcenplanung (Gantt) auch noch Aussagen über Puffer und Flaschenhalse im Vorgangsnetzwerk treffen. Tutorial zum Aufbau eines Netzplans.
Nicht alle Anforderungen sind gleich wichtig, nicht alle Anforderungen sind auf Anhieb gut formuliert/dokumentiert. Woran erkenne ich gute Anforderungen, woran erkenne ich wichtige Anforderungen? Und: gibt es auch zu viel Spezifikation?
Es stehen die Wünsche der Stakeholder im Raum – und auch die Normen und Gesetze wollen als Anforderung dokumentiert werden. Welche unterschiedlichen Artefakte gibt es, in denen Anforderungen erfasst werden können, und wo eignen sie sich besonders?
Welche Techniken gibt es, um Anforderungen zu ermitteln, dokumentieren, gliedern, validieren und messbar zu machen? Welche Kriterien werden an gute fachgerechte und überprüfbare Anforderungen angelegt?
UML-Usecase-Diagramme lassen sich mit vielen Tools erstellen. Um sie aber als versionierbaren Code direkt in die Readme-Dateien des Repositories zu übernehmen führt kaum ein Weg an PlantUML vorbei.
Ein Bild sagt mehr als tausend Worte: Funktionale Anforderungen lassen sich im Kundengespräch oft am schnellsten mit einem Diagramm zeichnen. Ein paar Strichmännchen, ein paar Ellipsen, ein Rechteck – aber was bedeuten die Notationsmittel genau, und wo setzte ich sie sinnvollerweise ein?
Aus den Usecase-Diagrammen kennen wir den Begriff Anwendungsfall. Aber was steckt dahinter – und wo kann es uns behilflich sein?
Anforderungen kommen nicht vom Himmel gefallen. Viele Projekte scheitern daran, dass nie hinreichend definiert wurde, was eigentlich die Ziele sein sollen. Wie kann eine systematische Anforderungsanalyse aussehen?
