Wie fängt man denn jetzt nun an eine Software zu planen?
kurzes Vorwort:
Ich muss sagen, ich habe mir die letzten Tage mehrfach an das Thema versucht und ich glaube eine kompetente Erklärung die alles abdeckt ist in einem überschaubaren Beitrag kaum möglich. Ich denke niemand will hier einen Beitrag sehen mit 40.000 Wörter…
Das wird sich durch alle Themen ziehen, je nach dem wie tief man in einzelne Thematiken abdriften will, können wir hier ganze Bücher schreiben, einerseits kenne ich mich dann doch nicht so gut aus andererseits ist das nur ein Hobby und mir fehlt dazu dann doch etwas die Zeit.
Im Endeffekt möchte ich eine kleine Sammlung der wichtigsten Methoden, Begriffe und Standards aufarbeiten, die man dann für Fragen oder zur Lösung dieser heranziehen kann.
ANFORDERUNGEN FESTLEGEN
Der allseits anerkannte erste Schritt eine Software zu planen ist es die Anforderungen an die Software festzulegen.
Dazu muss man aber erstmal Wissen was Anforderungen einer Software sind, um diese festzulegen zu können.
Das heißt im Grunde welche Person ist von dem Projekt betroffen oder beteiligt (Stakeholder) und was erwartet dieser Stakeholder (eine Fähigkeit oder Eigenschaft, die ein System haben soll) von meiner Software.
Das ganze macht man mit einer Anforderungsanalyse:
Je nach Organisation geht man da etwas anders an die Sache ran bzw. von einem anderen Blickwinkel heran, jedoch gibt es 3 Schritte die in allen Varianten irgendwie vertreten sind.
- Ermittlung, Analyse
- Strukturierung und Abstimmung
- Prüfung und Bewertung
Ermittlung und Analyse
„Nichts geht über…“ sagt man schnell mal aber Nichts geht über das Wissen welche Anforderungen wirklich gebraucht werden, ja wirklich! Du willst nicht Tage vielleicht sogar Wochen mit Dingen verbringen, für die dich keiner bezahlt, nicht in der Softwareentwicklung aber auch in keinem anderen Beruf, damit das nicht vorkommt ermittelt und analysiert man welche Anforderungen ein Projekt hat.
Alle Anforderungen des Kunden müssen so genau wie möglich beschrieben sein, es darf keine mit gemeinten Annahmen des Kunden über das zu entwickelnde System geben. Will der Kunde das das wirklich oder glaube ich nur zu Wissen das er es will, diese beiden Zustände können manchmal gewaltig von einander abweichen.
Anforderungen müssen eindeutig definiert sein das hilft extrem Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden. Will der Entwickler diesen Knopf dort in grün oder will er alle Knöpfe in grün.
Die Anforderungen sollten in einer Sprache und in einem Sprachniveau verständlich formuliert sein womit sich alle Seiten auskennen, soweit Fachsprache benutzt werden muss, sollte diese so genau wie möglich erklärt sein(Jeder ist ein Fachmann aber in seinem eigenem Gebiet, das sollte man berücksichtigen), eine verständlich und übersichtlich geschriebene Dokumentation der Anforderung die an alle beteiligten Seiten ausgegeben wird, kann im Zweifel viel Nachsprache und Probleme verhindern.
Jede Anforderung muss eindeutig identifizierbar sein, über eine Kennung oder oder ID sodass man im Nachgang immer ein identifizierbare Anforderung bekommt
Anforderungen sollten mit Abnahmekriterien(erreichbaren Ziel) verknüpft sein sodass man diesen in der Abnahme auch problemlos nachvollziehen kann, ob diese Anforderung erfüllt ist, dies ist der Weg um eine Anforderung vorwärts verfolgbar macht.
Wenn man eine Rückwärtsverfolgung möglich machen will, sollte jede implementierte Funktion einer Software kontrollierbar sein, aufgrund welcher Anforderungen sie erstellt wird, des weiteren sollten alle implementierten Funktionen widerspruchsfrei zu anderen Funktionen sein um die Anforderung konsistent zu halten.
Strukturierung und Abstimmung
Wenn du die Anforderungen erfasst hast, stellst du bei der ein oder anderen Anforderung schnell fest das sie im ersten Moment machbarer, realistischer, notwendiger sind als andere, deshalb beginnt nach der Erfassung der nächste logische Schritt, die Strukturierung und die Klassifizierung!
Anforderungen werden dadurch schnell übersichtlicher, das wiederum das Verständnis der Zusammenhänge zwischen den Anforderungen erhöht, jetzt kannst du als nach folgenden Gründen sortieren:
- gibt es Anforderungen die abhängig von andere Anforderungen sind
- gehören Anforderungen fachlich-logisch zusammen
- Welche Anforderungen gehören zu welcher Benutzerrollen
Weitere Strukturierungsmöglichkeiten sind :
- funktionale und nicht funktionale Anforderungen von einander abgrenzen oder
- fachliche sowie technische Anforderungen (fachlich motiviert)
- rein technische Anforderungen (technisch motiviert)
Die so strukturierten Anforderungen werden zwischen Kunde(oder einem Vertreter des Kunden) und des Entwicklers(oder einen Vertreter des Entwicklers) weiter verfeinert in dem durch einen iterativen Prozess sich dem besten Ergebnis angenähert wird!
Prüfung und Bewertung
Wenn die Strukturierung erfolgte oder sogar schon zum Teil während diese noch läuft, erfolgt die wichtige Qualitätssicherung der Anforderungen nach entsprechende Merkmale:
- korrekt: Die Anforderungen müssen widerspruchsfrei sein
- machbar: Die Anforderung muss realistisch sein
- notwendig: Die Anforderungen müssen vom Kunden(Auftraggeber) gewollt sein
- priorisiert: Es muss eine der Vorrang(Reihenfolge) von Anforderungen geklärt sein
- nutzbar, nützlich: Die Realisierung muss ein produktives System im Auge behalten
Das Ergebnis dieser Informationen dient als Basis zum Beispiel für das Pflichtenheft auch wenn dieses gar nicht mehr so häufig anzutreffen ist, durch den starken Wachstum der letzten Jahre von agilen Projektentwicklungen, das wir unter anderem Scrum oder andere agile Methoden zu verdanken haben!
Es benötigt aber grundsätzlich in jeder Methode, sei wie agil oder auch nicht eine gute Aufnahme der Anforderungen
