Bevor wir uns mit dem Thema objektorientierte Analyse und Design befassen (was den meisten von uns neben dem eigentlichen Schreiben von Code den größten Spaß an dem macht, was wir tun), ist es wichtig, noch ein paar Dinge zum Verständnis der Kundenanforderungen zu beachten .

Im vorigen Beitrag habe ich erwähnt:

Wenn Sie sich von Anfang an Zeit nehmen, um zu verstehen, was sie wollen, müssen die Anforderungen kein 50-seitiges Dokument sein, in dem beschrieben wird, wie jedes einzelne Modul funktionieren muss.

Wenn ich zum Beispiel Anforderungen (oder ein Statement of Work) zusammenstelle, wie ich sie normalerweise nenne, wenn ich sie an Kunden schicke, überschreite ich selten zehn Seiten und es sind oft weniger.

Und obwohl es Zeiten gibt, in denen es länger dauert, denke ich, dass ein Teil der Gründe für die Entwicklung eines kurzen Anforderungskatalogs in den Vorgesprächen liegt, um sicherzustellen, dass Sie und der/die Kunden eine gemeinsame Sprache entwickelt haben, mit der Sie arbeiten können.

Wenn Sie das tun, müssen die Anforderungen und die Leistungsbeschreibung – wie auch immer Sie sie nennen – nicht so lang sein.

Schreiben einer Leistungsbeschreibung

Zunächst möchte ich im Kontext dieses Beitrags zwischen einem Statement of Work und Requirements unterscheiden.

• Anforderungen sind das, was der Kunde gebaut haben möchte.
• Die Leistungsbeschreibung beschreibt, was Sie tun werden, wie Sie es tun werden und für wie viel.

Auf Letzteres gehe ich in diesem Beitrag näher ein. Aber es genügt zu sagen, dass Anforderungen in Form von Diskussionen, Dokumentationen oder beidem kommen können, soweit es den Kunden betrifft.

Bevor ich mich mit den verschiedenen Teilen dessen befasse, was ich in eine Leistungsbeschreibung aufnehme, gibt es ein paar Dinge, die meiner Meinung nach erwähnenswert sind:

1. Schreiben Sie keine Leistungsbeschreibung, bis Sie alle Anforderungen des Kunden haben.
2. Stellen Sie sicher, dass der Kunde weiß, was er von einer Leistungsbeschreibung erwarten kann.
3. Wenn Sie sich die Zeit nehmen, eine Leistungsbeschreibung zu schreiben, entscheiden Sie, ob Sie die Zeit in Rechnung stellen oder nicht, und stellen Sie sicher, dass der Kunde weiß, dass er dafür bezahlen muss oder nicht

Dies ist eines dieser Dinge, die von Freelancer zu Freelancer oder von Agentur zu Agentur ablaufen. Vor diesem Hintergrund sind hier die Teile einer Leistungsbeschreibung, die ich normalerweise einfüge.

Erstellung einer Leistungsbeschreibung

Immer wenn ich eine Leistungsbeschreibung vorbereite, habe ich eine Vorlage, die ich verwende. Ich werde hier eine Aufschlüsselung bereitstellen, die einen Großteil davon abdeckt.

So funktioniert jeder Abschnitt:

1 Leistungsbeschreibung

Der Zweck dieses Dokuments besteht darin, [eine vorgeschlagene Lösung für DAS PROJEKT zu definieren].

Die Anforderungen des Projekts wurden von [NAME DES KUNDEN], [ROLLE DES NAMEN DES KUNDEN IM NAMEN IHRES UNTERNEHMENS] bereitgestellt. Die Bedingungen der Vereinbarung sind eine Kombination der von [NAME DES KUNDEN] und [NAME IHRES NAMENS DER AGENTUR] vereinbarten.

2 Anforderungen im Überblick

Der Zweck dieses Dokuments besteht darin, [eine vorgeschlagene Lösung für DAS PROJEKT zu definieren].

Die Anforderungen des Projekts wurden von [NAME DES KUNDEN], [ROLLE DES NAMEN DES KUNDEN IM NAMEN IHRES UNTERNEHMENS] bereitgestellt. Die Bedingungen der Vereinbarung sind eine Kombination der von [NAME DES KUNDEN] und [NAME IHRES NAMENS DER AGENTUR] vereinbarten.

3 Sprachen und Technologie

Der Webserver, die Software, die Tools und der Ansatz, die zum Erstellen der Lösung verwendet werden.

4 Unterstützte Browser

Wenn es sich um ein webbasiertes Projekt handelt, behandeln Sie die unterstützten Browser, ob es reaktionsfähige Funktionen geben wird oder nicht, und wie die vorherigen Punkte getestet werden.

5 Sprachen und Technologie

Der Webserver, die Software, die Tools und der Ansatz, die zum Erstellen der Lösung verwendet werden.

6 Projektanforderungen und Meilensteine

Normalerweise der längste Abschnitt des Dokuments. Es fasst zusammen:

• Die Anforderungen,
• Wie jede Anforderung erstellt und geliefert wird,
• Alle zusätzlichen Hinweise, die dem Kunden bekannt sein sollten.

7 Vorgeschlagener Zeitplan

Dies basiert auf den im vorherigen Abschnitt beschriebenen Meilensteinen und dem Feedback des Kunden.

8 Andere Faktoren

Verschiedene Dinge, die Sie freiwillig einschließen möchten, z. B. was Sie oder Ihre Agentur in das Projekt einbringen möchten, wie sich verzögertes Feedback auf das Projekt auswirken kann und so weiter.

9 Geschätzte Kosten

Dazu gehören die Gesamtkosten des Projekts und eine optionale Aufschlüsselung des Zahlungsplans.

Es ist notwendig

Ich weiß: Ich habe das bereits in früheren Beiträgen dieser Serie gesagt. Das ist nicht der glamouröseste Teil unserer Arbeit. Stattdessen würden wir stattdessen direkt in die Programmierung springen.

Aber woher wissen Sie, was Sie bauen sollen (und es gut bauen), wenn wir uns nicht richtig mit dem Problem befasst haben, das wir zu lösen versuchen?

Und das gibt uns alles, was zu objektorientierter Analyse und Design führt.

Objektorientierte Analyse

Jetzt, da wir den Papierkram (oder sogar das „Geschäftszeug“, wie manche es nennen mögen) aus dem Weg geräumt haben, ist es an der Zeit, uns in die Programmierung vorzuarbeiten.

Zuvor ist es jedoch wichtig, die Anforderungen zu analysieren und festzulegen, welche Teile des Projekts welchem ​​Zweck dienen sollen. Zum Beispiel:

• Benötigen wir eine bereits vorhandene Software?
• Müssen wir Adapter oder Datenschichtcode schreiben?
• Wie bauen wir die Anwendungsschicht und die darin enthaltenen Entitäten auf?
• Was ist mit dem Frontend

Und für viele beginnt hier der Spaß. Also bin ich gespannt darauf, auch darüber zu sprechen. Wir beginnen im nächsten Beitrag.