Wesentliche Techniken, um fehlende Anforderungen ausfindig zu machen?

Bewerten Sie den Lebenszyklus der Elemente des Modells in Bezug auf ein generisches / Gesamtmodell wie

• Weißt du, woher jede Entität kommt und wie du sie in dein System bekommst?
• Weißt du, wo jede einmal erworbene Entität wie lange verweilen wird?
• Weißt du, was mit jeder Entität zu tun ist, wenn sie nicht mehr benötigt wird?

für eine feinkörnigere Analyse des Lebenszyklus der Entitäten in der Spezifikation, erstellen Sie eine CRUDE-Matrix für die wichtigsten Entitäten in den Anforderungen; Dies ist eine Matrix mit den Operationen / Anwendungen als Zeilen und den Entitäten als Spalten. Setzen Sie in jeder Zelle ein C, wenn die Anwendung die Entität erstellt, R für Lesen, U für Aktualisierungen, D für Löschen oder E für "Bearbeitungen"; "E" umfasst C, R, U und D (die meisten "Master Table Maintenance" -Apps sind Es). Dann überprüfe jede Spalte auf C, R, U und D (oder E); Wenn einer fehlt (außer E), finde heraus, ob es benötigt wird. Die Zeilen und Spalten der Matrix können neu angeordnet werden (manuell oder unter Verwendung einer Affinitätsanalyse), um zusammenhängende Gruppen von Einheiten und Anwendungen zu bilden, die im Allgemeinen Teilsystemen entsprechen; Dies kann später bei der Verteilung des physischen Systems helfen.

Es ist auch nützlich, der CRUDE-Matrix eine Entitätsspalte "User" hinzuzufügen und für jede Anwendung (oder Feature oder Funktionsbereich oder was auch immer Sie die Verarbeitungs- / Verhaltensaspekte der Anforderungen nennen möchten) anzugeben, ob Input von benötigt wird der Benutzer, erzeugt Ausgabe für den Benutzer oder Interagiert mit dem Benutzer (ich verwende hierfür I, O und N und mache den Benutzer immer zur ersten Spalte). Dies hilft zu identifizieren, wo Benutzerschnittstellen für Dateneingabe und Berichte benötigt werden.

Ziel ist es, die Vollständigkeit der Spezifikation zu überprüfen; Mit den oben genannten Techniken kann überprüft werden, ob der Lebenszyklus der Entitäten in Bezug auf die identifizierten Entitäten und Anwendungen "geschlossen" ist.

Fortwährende, häufige, offene und wechselseitige Kommunikation mit dem Kunden scheint mir die wichtigste "Technik" zu sein, soweit es mich betrifft.

Kommt darauf an.

Es hängt davon ab, ob Sie dafür bezahlt werden, das zu liefern, was Sie gesagt haben, oder dass Sie qualitativ hochwertige Software an den Kunden liefern.

Wenn ersteres, einfach Mehrdeutigkeit aus den Spezifikationen zu beseitigen und dann bauen, was Sie zugestimmt haben. Versuchen Sie, sich von allem zu entfernen, was nicht messbar ist (wie "schnell", "cool", "bissig" usw.).

Wenn letzteres, was Galwegian gesagt hat + Zeit oder einfach alles nicht absolut tot-tote kritisch geschnitten und so schnell wie möglich gebaut wurde. Die Produktion hat eine bemerkenswerte Möglichkeit zu beleuchten, was Sie in Analysis vermisst haben.

Hier finden Sie die fehlenden Anforderungen.

1. Zerlegen Sie die Anforderungen in kleine kleine Schritte. Wirklich klein. Etwas, das in zwei Wochen oder weniger gebaut werden kann. Sie werden viele Lücken finden.

2. Priorisieren Sie diejenigen in das, was am besten wäre, zuerst zu haben, was als nächstes zu dem kommt, was nicht wirklich wichtig ist. Sie werden feststellen, dass einige Lückenfüller keine Rolle spielten. Sie werden auch feststellen, dass einige der ursprünglichen "Anforderungen" lediglich wünschenswert sind.

3. Diskutieren Sie Meinungsverschiedenheiten darüber, was für die Endnutzer am wichtigsten ist und warum. Zwei Benutzer haben drei Meinungen. Sie werden feststellen, dass einige Benutzer keine Ahnung haben und keine ihrer "Anforderungen" benötigt werden. Du wirst feststellen, dass manche Menschen kein Rückgrat haben und Dinge, die sie nicht mutig genug sind, um laut zu sagen, "erforderlich" sind.

4. Erhalte nur einen Konsens über die ersten zwei oder drei. Diskutiere nicht jede Nuance. Es ist nicht möglich, sich Software vorzustellen. Es ist nicht möglich, sich vorzustellen, wie Software sein wird und wie sie sie verwenden wird. Die "Anforderungen" der meisten Leute sind Beschreibungen, wie der Kampf um die unangemessenen Geschäftsprozesse, an denen sie heute festhalten, zu bewältigen ist.

5. Erstellen Sie zuerst den wichtigsten Teil mit der höchsten Priorität. Gib es den Benutzern.

6. GOTO 1 und wiederholen Sie den Vorgang.

"Warte", sagst du, "Was ist mit dem Gesamtbudget?" Was ist damit? Sie können nie das Gesamtbudget kennen. Mach folgendes:

Sehen Sie sich jedes in Schritt 1 definierte Inkrement an. Geben Sie einen Preis pro Inkrement an. In der Reihenfolge der Priorität. Auf diese Weise kann jemand so viel oder so wenig auswählen, wie er möchte. Es gibt keine große, gruselige "Big Budget Schätzung mit einer Menge Nullen". Es ist alles verhandelbar.

Ich habe eine Modellierungsmethode namens Behavior Engineering (bE) verwendet, die den ursprünglichen Spezifikationstext verwendet, um das resultierende Modell zu erstellen. Wenn Sie das Modell haben, können Sie fehlende oder unvollständige Abschnitte der Anforderungen leichter identifizieren.

Ich habe die Methode in bisher sechs Projekten verwendet, die von weniger als zehn Anforderungen bis zu über 1.300 Anforderungen reichen. Wenn Sie mehr wissen möchten, würde ich vorschlagen, zu www.behaviourengineering.org dort einige wirklich gute Arbeiten bezüglich der Methodik zu machen.

Die Firma, für die ich arbeite, hat ein Werkzeug zur Modellierung erstellt. Die Arbeitsrate, um das Modell tatsächlich zu erstellen, ist etwa 5 Anforderungen für einen Anfänger und einen Experten etwa 13 Anforderungen pro Stunde. Das Tolle an der Methode ist, dass Sie nicht wirklich etwas über die Domäne wissen müssen, für die die Spezifikation geschrieben wurde. Mit nur dem Benutzertext wie Nomen und Verben findet der Modellierer in sehr kurzer Zeit Lücken im Modell.

Ich hoffe, das hilft

Michael Larsen

Wie wäre es mit dem Bau eines Prototyps?

Als ich viel Literatur über Softwareanforderungen gelesen habe, habe ich diese zwei interessanten Bücher gefunden:

• Problemrahmen: Analysieren & amp; Strukturierung von Softwareentwicklungsproblemen von Michael Jackson (kein Sänger! :-).

• Praktische Softwareanforderungen: Ein Handbuch für Inhalt und Stil von Bendjamen Kovitz.

Diese beiden Autoren heben sich wirklich von der Masse ab, weil sie meiner bescheidenen Meinung nach einen wirklich guten Versuch machen, die Entwicklung von Anforderungen in einen sehr systematischen Prozess zu verwandeln - mehr wie Technik als Kunst oder schwarze Magie. Insbesondere Michael Jacksons Definition dessen, was Anforderungen wirklich sind - ich denke, es ist das sauberste und genaueste, das ich je gesehen habe.

Ich würde diesen Autoren keinen guten Dienst erweisen, wenn ich versuche, ihren Ansatz in einem kurzen Beitrag hier zu beschreiben. Also werde ich das nicht tun. Aber ich werde versuchen zu erklären, warum ihr Ansatz für Ihre Frage äußerst relevant zu sein scheint : es erlaubt Ihnen, die meisten (nicht alle, aber die meisten!) Von Ihnen Anforderungen Entwicklung Arbeit zu einem Haufen zu verarbeiten von Checklisten *, die Ihnen sagen, welche Anforderungen Sie definieren müssen, um alle wichtigen Aspekte des gesamten Kundenproblems abzudecken. Mit anderen Worten, dieser Ansatz soll das Risiko minimieren, wichtige Anforderungen zu verpassen (einschließlich derer, die oft implizit bleiben) .

Ich weiß, dass es mag mag klingen mag, aber es ist nicht. Es bedarf noch erheblicher mentaler Anstrengungen, um zu diesen "magischen" Checklisten zu kommen: Man muss zuerst das Problem des Kunden artikulieren, dann gründlich analysieren und schließlich in sogenannte "Problemframes" zerlegen (die mit dieser Magie einhergehen) check-lists nur dann, wenn sie mit einigen typischen von den Autoren definierten Problemfeldern übereinstimmen. Wie ich schon sagte, verspricht dieser Ansatz nicht, alles einfach zu machen. Aber es verspricht definitiv, den Prozess der Anforderungsentwicklung so systematisch wie möglich zu gestalten.

Wenn die Anforderungsentwicklung in Ihrem aktuellen Projekt bereits von Anfang an weit fortgeschritten ist, ist es möglicherweise nicht möglich, zu diesem Zeitpunkt zu versuchen, den Problemrahmenansatz anzuwenden (obwohl dies stark davon abhängt, wie Ihre aktuellen Anforderungen organisiert sind). Dennoch empfehle ich dringend, diese zwei Bücher zu lesen - sie enthalten eine Menge Weisheit, die Sie vielleicht noch auf das aktuelle Projekt anwenden können.

Meine letzten wichtigen Notizen zu diesen Büchern:

• Soweit ich weiß, ist Mr. Jackson der ursprüngliche Autor der Idee von "Problemframes". Sein Buch ist ziemlich akademisch und theoretisch, aber es ist sehr, sehr lesbar und sogar unterhaltsam.

• Herr. Kovitz 'Buch versucht zu zeigen, wie Mr. Jackson Ideen in der realen Praxis angewendet werden können. Es enthält auch viele nützliche Informationen zum Schreiben und Organisieren der tatsächlichen Anforderungen und Anforderungen Dokumente.

Sie können wahrscheinlich vom Kovitz-Buch ausgehen (und sich nur auf Mr. Jacksons Buch beziehen, wenn Sie wirklich tiefer in die theoretische Seite einsteigen müssen). Aber ich bin sicher, dass Sie am Ende des Tages beide Bücher lesen sollten, und Sie werden das nicht bereuen. : -)

HTH ...

Ich stimme mit Galwegian überein. Die beschriebene Technik ist weitaus effizienter als der Ansatz "Warten auf Kunden, um uns anzuschreien".