Was ist der geeignete Weg, um mit impliziten Anforderungen umzugehen?

Ich bin in Forschung und Entwicklung und arbeite an einem neuen Softwareprodukt.

Das Management konzentriert sich verständlicherweise auf die Hauptmerkmale, die einem Kunden am offensichtlichsten einen Vorteil verschaffen. Es gibt jedoch viele Anforderungen, die ebenfalls als wichtig angesehen werden können (z. B. Leistung, zukünftige Erweiterbarkeit, Rückverfolgbarkeit von Daten, Sicherheit, reibungslose Benutzeroberfläche ). Diese impliziten Anforderungen sind wahrscheinlich die größere Anzahl für jedes Produkt und können, wenn sie nicht erfüllt werden, zu einem unglücklichen Kunden führen.

Ich befürchte, dass irgendwie erwartet wird, dass diese Dinge während der Entwicklung automatisch implementiert werden. Für mich ist alles ein atomarer Aspekt, der seine eigene Aufmerksamkeit und Entwicklungsanstrengung erfordert.

Ich habe das Gefühl, dass das Management möglicherweise zu beschäftigt ist, um solchen Aspekten zu viel Aufmerksamkeit zu schenken. Aus Gründen meines eigenen Entwicklerstolzes, der Qualitätskontrolle und der Fähigkeit, den Aufwand zu berücksichtigen, den ich aufgewendet habe, wann und wie sollte ich implizite Anforderungen dokumentieren und kommunizieren?

(dh Funktionen, die in einem Produkt vorhanden sind, über die jedoch weder mit dem Kunden noch mit dem Management ausdrücklich gesprochen wurde)

Klärung

Vielen Dank für das Interesse an der Frage. Der Kern der bisherigen Antworten scheint zu sein:

"Sie müssen implizite Anforderungen explizit machen."

Ratten ... das ist mir nicht eingefallen.

Die Anforderungen, die ich meine, können von den folgenden Arten sein:

• Der Kunde kann von diesen Anforderungen nichts hören, da ich eine lange Liste von Möglichkeiten vorstelle, wie das Produkt versagen kann, anstatt darüber zu sprechen, wie es sie glücklich macht.
• Das geschäftige Management hat das Gefühl, dass ich ihre Zeit verschwende, wenn ich über "offensichtliche" Merkmale spreche.
• Ich werde nur einige dieser Anforderungen während der Implementierung beschreiben können. Während der Planung habe ich möglicherweise nur das Gefühl, dass ein bestimmtes Problem während der Entwicklung gezielte Anstrengungen erfordern könnte.
• Ich bin nicht auf der notwendigen Höhe im Totempfahl der Firma, um meine Arbeitsbedingungen zu bestimmen.

Ich bitte um Richtlinien, wie [implizite] Anforderungen halb formalisiert werden können, während ich weniger Aufwand als bei vollständigen Anforderungen unternehme, mich aber auf den Tag des Jüngsten Gerichts vorbereiten muss, damit ich nicht mit leeren Händen erwischt werde.

Implizite Anforderungen explizit zu machen, ist die richtige Antwort.

Informationen zu Ihren Follow-up-Einschränkungen:

Der Kunde kann von diesen Anforderungen nichts hören, da ich eine lange Liste von Möglichkeiten vorstelle, wie das Produkt versagen kann, anstatt darüber zu sprechen, wie es sie glücklich macht.

Stellen Sie sich vor, Sie sind Architekt und entwerfen Gebäude für große Unternehmen.

Big Co. Inc. bittet Sie, am Ufer einen Wolkenkratzer für sie zu bauen. Es muss einen Pool auf dem Dach und einen weiteren Pool im 10. Stock haben. Es muss einen Wandgarten haben, der die Außenwand vom 15. bis zum 17. Stock bedeckt.

Dies sind die Anforderungen des Kunden. Würden Sie zögern, der Anforderungsliste die Anforderungen hinzuzufügen, damit das Gebäude sein eigenes Gewicht sowie zwei mit Wasser gefüllte Pools und einen riesigen Wandgarten trägt?

Würden Sie zögern hinzuzufügen, dass es Wasserleitungen, elektrische Leitungen und ein System geben muss, um den Pool mit Wasser zu füllen und das Wasser sauber zu halten?

Sie sind der Architekt, Sie wissen, was für ein Gebäude notwendig ist, dafür bezahlen sie Sie.

Sie wissen, dass ein Gebäude mit mehr als drei Stockwerken einen Aufzug benötigt. Sie brauchen niemanden, der Ihnen das sagt.

Das geschäftige Management hat das Gefühl, dass ich ihre Zeit verschwende, wenn ich über "offensichtliche" Merkmale spreche.

Der Aufzug ist also offensichtlich. So offensichtlich es auch ist, es wirkt sich immer noch auf die Gesamtkosten, den Gesamtbedarf an Arbeitskräften, die ETA für das Projekt und wahrscheinlich auch auf andere Aspekte aus.

Ich werde nur einige dieser Anforderungen während der Implementierung beschreiben können. Während der Planung habe ich möglicherweise nur das Gefühl, dass ein bestimmtes Problem während der Entwicklung gezielte Anstrengungen erfordern könnte.

Hier bricht die Architektenanalogie, hauptsächlich aufgrund der fließenden Natur der IT. Mein einziger Rat hier ist, dass Sie von einem iterativen Prozess profitieren können, mit dem Sie das Ungeplante planen können. Agile scheint ziemlich beliebt zu sein.

Ich bin nicht auf der notwendigen Höhe im Totempfahl der Firma, um meine Arbeitsbedingungen zu bestimmen.

Ihr Unternehmen sollte jemanden haben, der dafür verantwortlich ist, dass die Anforderungsliste vollständig ist.

• Wenn sie kein großes Problem haben, versuchen Sie, sie dazu zu bringen, es zu beheben, oder beginnen Sie, Ihren Lebenslauf zu polieren.
• Wenn sie es tun, aber diese Person ihre Arbeit nicht richtig gemacht hat, rufen Sie sie an und eskalieren Sie nach Bedarf.
• Wenn sie es tun und diese Person Sie sind, aber Sie nicht die Befugnis erhalten haben, Ihren Job zu erledigen, dann bitten sie Sie, etwas Unmögliches zu tun. Ihr bester Schritt ist, nicht zu spielen (auch bekannt als Versuch, sie dazu zu bringen, es zu reparieren oder Fangen Sie an, Ihren Lebenslauf zu polieren.

Definiere alles. Das einzig mögliche Negative dabei ist, dass Sie möglicherweise etwas zurückbekommen, das sich darüber beschwert, dass Sie das Offensichtliche sagen.

Geben Sie dann das Offensichtliche an.

Dies ist der Schlüssel: Alles, was Sie nicht definieren, kann mit "Sie haben es uns nie gesagt ..." wieder ins Gesicht geworfen werden.

Alles, was nicht definiert ist, kann möglicherweise in Ihrem Gesicht explodieren. "Besser sicher als leid" sind ausgezeichnete Worte, nach denen man leben kann.

Der Branchenbegriff für die von Ihnen beschriebenen Anforderungen lautet:

Nicht-funktionale Anforderungen

Sie sollten unter allen Aspekten durch technische Ressourcen identifiziert und als atomare Arbeitseinheiten in den Projektplan aufgenommen werden. Wenn Sie ein agiles Projekt durchführen, werden diese in User Story-Form geschrieben und dem zu bearbeitenden Backlog hinzugefügt. Als technische Ressource müssen Sie sich für die Zeit einsetzen, um an diesen zu arbeiten, und sicherstellen, dass sie während Ihrer Sprint- oder Projektplanungssitzung mit dem Unternehmen eine angemessene Priorität haben. Darüber hinaus muss die Qualitätssicherung auch für diese Arbeitseinheiten einen geeigneten Testplan erstellen.

Zufällig haben uns einige dieser impliziten Anforderungen gebissen, weil sie nicht definiert waren und die Qualitätssicherung sie daher nicht getestet hat und die Fehler in die Produktion gingen und einige Zeit nicht gefunden wurden, was nicht nur den Aufwand verursachte, den Kunden das zu erklären Problem und warum es nicht früher gefunden wurde, sondern ein tatsächliches rechtliches Problem für unser Unternehmen. (Es war ein Bericht, der sich mit Informationen befasste, die der Regierung gemeldet werden mussten.)

Wenn es wichtig genug ist, muss es getestet werden und daher Teil der Anforderungen sein.

Anforderungen können aus jeder Quelle stammen, sofern sie auf ihren Herkunftsort zurückgeführt werden können und nicht miteinander in Konflikt stehen. Kunden können ihre Anforderungen angeben, aber Anforderungen ergeben sich auch aus Gesetzen und Vorschriften, Industriestandards, Geschäftsanforderungen und sogar früheren Erfahrungen, die durch die Lieferung ähnlicher Produkte an andere Kunden gewonnen wurden.

Jede dieser Anforderungen sollte mit einer beliebigen Methode erfasst werden, mit der Sie Anforderungen erfassen, damit sie nicht vergessen werden. Auf diese Weise können sie auch verglichen werden, um sicherzustellen, dass eine hinzugefügte Anforderung nicht tatsächlich im Widerspruch zu einer Kundenanforderung steht oder eine Kundenanforderung beispielsweise nicht im Widerspruch zu Vorschriften steht.

Sie sollten diese Anforderungen erfassen und von Anfang an verwalten und an die Mitarbeiter weiterleiten, die die Software entwerfen, implementieren und testen. Auf diese Weise wird sichergestellt, dass jeder vollständig versteht, wie die gelieferte Software aussehen soll.

Wenn Sie jedoch eine dieser Anforderungen hinzufügen, sollten Sie diese bei den entsprechenden Stakeholdern überprüfen. Sie können nicht einfach Anforderungen hinzufügen, ohne sicherzustellen, dass Sie die Software weiterhin innerhalb des vorgesehenen Zeitplans und Budgets liefern können.

Dies ist der Fall, wenn ein vielfältiges Team mit Mitarbeitern, die sich auf verschiedene Bereiche spezialisiert haben, hinzukommt. Es erfordert auch mehr sr. Leute im Team, die den Rest führen.

Zum Beispiel sollten Leistung, zukünftige Erweiterbarkeit und Rückverfolgbarkeit von Daten eigentlich alles Dinge sein, an die von Anfang an gedacht wird. Sie sind kein Kontrollkästchen, das Sie später einfach wieder hinzufügen können. Sie müssen die Grundlage Ihres Entwurfs bilden.

In Bezug auf die Sicherheit ist dies der Fall, wenn jemand, der mit diesem Bereich vertraut ist, von Anfang an in Ihrem Team ist, um beim Entwurfsprozess zu helfen.

UI-Design hat die Tendenz, ein Produkt zu beißen, wenn es nicht richtig gemacht wird. Hier kommt eine UX-Person ins Team, die Modelle und Bildschirmabläufe für das Team erstellt. Aber auch dies sollte im Vorfeld getan werden.

Ihre Anforderungen könnten eine Website sein, auf der Benutzer den aktuellen Bestand eines lokalen Geschäfts nachschlagen können. Bei der Gestaltung dieses Systems spielen diese impliziten Anforderungen eine Rolle.

Unter dem Gesichtspunkt des Projektmanagements bedeutet dies, dass das Budget Entwurfszeit sowie die richtige Testzeit enthalten muss. Es sollte auch Check-ins mit dem Kunden geben, um ihm zu zeigen, was getan wurde, um sicherzustellen, dass Sie auf dem richtigen Weg sind.

Alle impliziten Anforderungen, die letztendlich Arbeit für das Team verursachen, sollten explizit angegeben werden.
Wenn nicht, werden sie auch enden

1. Sie später beißen, wenn die Leute sie trotzdem ansprechen, was zu Entwicklungsüberschreitungen führt
2. ignoriert und später als Fehler gemeldet
3. Trotzdem implementiert zu werden, obwohl es nicht geplant war, was zu Überläufen und Fehlerberichten führte, da sie nicht implementiert wurden, wie der Kunde gedacht hatte, dass sie hätten sein sollen, aber nie erwähnt wurden.

Indem Sie implizite Anforderungen explizit machen, sparen Sie sich viele Kopfschmerzen.