Was gehört ins Projektkonzept?

Wer ein Softwareprojekt beginnt, beauftragt einen Dienstleister mit der Umsetzung einer Idee in ein Stück Software. Das ist ein sehr abstrakter Vorgang, da man weder Idee noch Endprodukt direkt vermitteln kann. Ein schriftliches, detailliertes Konzept sorgt zu Beginn dafür, dass eine gemeinsame Idee allen Projektbeteiligten zur Verfügung gestellt wird. Es dient als Basis für die Schätzung von Aufwand, Kosten und Zeiten.

Zu Beginn jeden Projektes muß das Ziel klar sein. Nicht wenige Projekte starten mit vager Zielvorstellung, da sind Mißverständnisse vorprogrammiert. Was gehört also ins Konzept, damit zu Beginn eine einheitliche Vorstellung der zu erbringenden Leistung besteht?

1. Die Ausgangssituation

Es ist wichtig zu verstehen, aus welcher Situation heraus der Auftraggeber das Projekt beginnt. Erfolg im Projekt definiert sich aus der Sicht des Auftraggebers, nicht des Auftragnehmers. Das Konzept sollte dies enthalten:

  • Aktuelle Situation
    Was tut der Auftraggeber, wie funktioniert sein Geschäft? Auch wenn sich Kunde und Lieferant schon länger kennen, ist es sinnvoll, die Situation zu Beginn des Projektes zu beschreiben, um ggfs. später Änderungen nachvollziehen zu können.
  • Motivation
    Warum beginnt der Auftraggeber das Projekt? Gibt ist einen konkreten Anlaß oder Auslöser? Sind zB gesetzliche Bestimmungen oder Veränderungen im Umfeld des Kunden Anlaß für das Projekt?
  • Ziel
    Was soll mit Projektende erreicht sein, welche Veränderung der Ausgangsssituation ist angestrebt? Ist das Ziel meßbar? Dann sollten Kenngrößen für das Maß des Erfolges angegeben werden.
  • Lösungsbeschreibung
    In bewusst nicht technischer Weise soll beschrieben werden, welcher Lösungsansatz gewählt wird und wie dieser zur Zielerreichung führt.

2. Beschreibung der Lösung

Dies ist der wichtigste Teil des Konzeptes, er sollte auch den größten Umfang haben. Entscheidend ist, dass die Leser den Inhalt verstehen. Gerade bei technischen Konzepten ist es nicht immer leicht, eine natürliche, nicht-fachliche Sprache zu wählen. Das Risiko besteht darin, dass der Kunde ein Konzept abnickt, das er tatsächlich nicht in vollem Umfang verstanden hat.

  • Anwendungsfälle
    Jede Funktion wird durch einen Textabschnitt vollständig beschrieben. Ich bevorzuge kurze, übersichtliche Beschreibungen von Funktionen der Software, analog zu user stories in der agilen Entwicklung. Nummerieren sie diesen Bereich durch, damit sie jede Funktion anhand der Nummer leicht wiederfinden können. Die Liste aller Anwendungsfälle markiert den Funktionsumfang, der bei Projektende als "Ziel erreicht" gilt. Jeder Anwendungsfall beschreibt:
    • Wer tut etwas? "Ein angemeldeter Nutzer …"
    • Was wird getan? "… öffnet die Produktübersicht …"
    • Was ist das Ergebnis? "… und sieht alle Produkte, die seiner Firma zugeordnet sind."
    • Welche Varianten gibt es? "Dabei kann die Übersicht nach folgenden Spalten x,y,z sortiert werden."
  • Zu verarbeitende Daten
    Die Anwendungsfälle erwähnen Datentypen, die in der Software enthalten sind. (Im Beispiel oben ist es das Produkt.) Neben einer allgemeinen Beschreibung sollte eine Abschätzung der zu erwartetenden Menge an Daten dieses Typs enthalten sein. Für jeden Datentyp muss beschrieben werden, welche Attribute vorzusehen sind. Achten Sie darauf, jedes Attribut zu berücksichtigen, das in den Anwendungsfällen zB für Filter oder Einschränkungen verwendet wird. Geben Sie für jedes Attribut an:
    • Name
    • Typischer Inhalt
    • Bedingungen (zB "muß gefüllt sein", "darf nicht größer als x sein" oder "muß Wert aus Liste sein")
  • Entwürfe und Layouts
    Für jeden Anwendungsfall muss beschrieben werden, wie sich die Software zu diesem Zweck präsentieren soll. Das User Interface muss dabei alle im Text genannten Anwendungsfälle und Funktionen unterstützen. Entwürfe sollten in schematischer Form zB als Wireframes vorliegen, da zu frühe Detaillierung im Projekt eher schädlich als förderlich ist.

In diesem Abschnitt wird die Lösung aus Sicht der Anwender beschrieben. Achten Sie darauf, hier nicht in technische Details abzugleiten siehe Was gehört nicht hinein? am Ende des Textes.

3. Rahmenbedingungen

Während die Anwendungsfälle den unmittelbaren Geschäftsnutzen des Projektes beschreiben, legen die Rahmenbedingungen fest, innerhalb welcher Vorgaben eine Umsetzung erfolgen kann.

  • Technische Umgebung
    Beschreiben sie die technischen Gegebenheiten bei Betrieb und Nutzung der Lösung. Sind Vorgaben hinsichtlich Betriebsystem von Server und/oder Client zu beachten? Für welche Endgeräte sind Anwendungsfälle und Entwürfe konzipiert? Bestehen Beschränkungen hinsichtlich Lieferanten oder einzusetzenden Produkten?
  • Einsatzbedingungen
    Wie soll das Ergebnis des Projektes verwendet werden? Gibt es Vorgaben hinsichtlich Reaktionsgeschwindigkeit oder Ausfallsicherheit des Systems? Sind Infrastruktur-Faktoren wie Netzwerk oder Bandbreite zu beachten? Was ist mit Sicherheitsaspekten, müssen bestimmte Inhalte besonders geschützt werden? Sind rechtliche Bestimmungen beim Einsatz zu beachten?
  • Erforderliche Schnittstellen
    Benötigt die Software Schnittstellen zu anderen Systemen? Wenn ja, wofür und für welche Anwendungsfälle? Sind diese Schnittstellen bereits bekannt und sokumentiert? Welche Lizenzen oder Berechtigungen werden zur Einrichtung dieser Schnittstellen benötigt?
  • Vorkenntnisse, Einschränkungen
    Welche Erfahrung mit Softwareprojekten hat der Kunde, welche Kenntnisse und Fähigkeiten können vorausgesetzt werden? Sind insbesondere Erfahrungen als Projektleiter oder -teilnehmer vorhanden, wenn ja: Welche? Gibt es sprachliche oder kulturelle Besonderheiten im Team? Da der Kunde im Softwareprojekt zumeist gewisse Mitwirkungspflichten hat, ist es wichtig zu wissen, welcher Kenntnisstand bei den Mitgliedern der Projektgruppe vorhanden ist.

… und was nicht?

Sehen sie davon ab, im Rahmen der Lösungsbeschreibung zu früh zu technisch zu werden: Spezifische Komponenten und Versionen, Methoden und Modelle sollten nur genannt werden, wenn ihr Einsatz aus dokumentierten Gründen zwingend erforderliche ist.

Das Konzept beschreibt das Ziel, der optimale Weg sollte anschließend gesucht und gefunden werden. Nicht selten werden im Konzept schon konkrete Produkte oder Techniken als Teil der Lösung vorausgesetzt, ohne im Detail zu begründen, warum dies geschieht. Das führt schon mal dazu, dass nicht das passendste Produkt oder die beste Technik für die Anforderung gewählt wird. Widerstehen Sie daher der Versuchung, im Konzept die Lösung vorwegzunehmen.


Gibt es in ihren Konzepten weitere wichtige Punkte? Hinterlassen Sie einen Kommentar, ich freue mich auf Ihre Ergänzung!