Warum sollte man zwischen funktionalen und nicht funktionalen Anforderungen unterscheiden?

Ich verstehe den Unterschied zwischen beiden, werde aber von meinen Kollegen gefragt, ob Kennzeichnungsanforderungen als funktional oder nicht funktional (oder vorübergehend) gelten. Warum sich die Mühe machen? Er verbrachte zwei Tage damit, eine Anforderungsliste für ein Projekt durchzuarbeiten, und sah keinen Nutzen darin, da das Endergebnis darin bestand, das Dokument einer anderen Geschäftseinheit mit dem Erlass "Alles tun" vorzulegen.

Was ich fürchte, sind Anforderungen, die in einem Dokument zusammengefasst sind. Ich habe versucht, den Nutzen in praktischen Begriffen zu erklären, konnte ihn aber nicht verkaufen. Wie verkaufe ich den Vorteil, zu dokumentieren, welche Anforderungen funktionsfähig und welche nicht funktionsfähig sind?

Durch die explizite Trennung von Anforderungen wird es einfacher, das richtige System zu entwerfen.

Bei nichtfunktionalen Anforderungen (ich bevorzuge die Qualitätsattribute Konzept / Begriff - sollte neue Erkenntnisse liefern, die über die funktionalen und nicht funktionalen hinausgehen) sind Sie eher mit den Eigenschaften der Software als mit der Funktionalität befasst. Das ist , wie das System eine Funktion ausführt, nicht nur , was das System tut. Qualitätsanforderungen haben einen erheblichen Einfluss auf die Architektur des Systems in einer Weise, wie es die funktionalen Anforderungen nicht tun, und aus diesem Grund sollten sie unterschiedlich behandelt werden.

Wenn Sie die Qualitätsattribute von den funktionalen Anforderungen trennen, können Sie verschiedene Arten von Anforderungen auf unterschiedliche Weise analysieren, spezifizieren und priorisieren. Beispielsweise werden Qualitätsattribute normalerweise mithilfe eines Qualitätsattributszenarios angegeben, während funktionale Anforderungen in Form von Storys, Anwendungsfällen, Soll-Aussagen oder einer anderen Anzahl von Formaten vorliegen können. Die meisten Systeme, an denen ich gearbeitet habe, hatten weniger als ein Dutzend Qualitätsattribute und viele, viele weitere funktionale Anforderungen.

Ich würde tatsächlich eine andere Art von Anforderungen einführen - technische Einschränkungen . Wenn Sie die Anforderungen erneut explizit in diese drei Bereiche unterteilen, erhalten Sie Hinweise, wie Sie die richtigen Kompromisse beim Aufbau des Systems eingehen können. Funktionale Anforderungen sind oft verhandelbar, Qualitätsmerkmale beeinflussen Ihre Architektur und die von Ihnen gewählten Strukturen stark, technische Einschränkungen sind nicht verhandelbar.

Wenn dies mein Team wäre, würde ich ihnen sagen, dass die Anforderungen eindeutig nach Typ kommentiert werden sollten, um sicherzustellen, dass wir nichts Wichtiges in der Architektur verpassen. Denken Sie an die architektonischen Treiber, nicht nur an die Funktionalität.

Anthony Lattanze in Architecting Software Intensive Systems: Ein Practitioners Guide gibt einen praktischen Überblick über architektonische Treiber und warum sie anders behandelt werden sollten, viel umfassender als meine Zusammenfassung hier.

Wenn jede Anforderung die gleiche Priorität / Gewichtung hat (insbesondere "Obligatorisch"), müssen Sie sich wahrscheinlich mehr Sorgen machen, als nur funktionale und nicht funktionale Anforderungen aufzuteilen.

Dennoch gibt es mehrere Gründe, die beiden Kategorien von Anforderungen zu trennen:

Verantwortung für die Implementierung Ich habe festgestellt, dass viele nicht-funktionale Anforderungen - insbesondere diejenigen, die sich auf die Leistung konzentrieren - nur mäßig auf den Entwickler zutreffen. Obwohl ein Design Skalierbarkeit und Geschwindigkeit unterstützen kann (und bestimmte Codeabschnitte optimiert werden können), hängt die Fähigkeit, alle Leistungsanforderungen zu erfüllen, im Allgemeinen von der Architektur und häufig vom Zeitpunkt der Hardwarekonfiguration ab.

Testverantwortung Wie gut ist der Benutzer oder das QA-Team in der Lage, die Einhaltung der Sicherheits-, Fehlertoleranz-, Sicherheits- und Zuverlässigkeitsanforderungen zu überprüfen?

Wiederholen Sie sich nicht Die Dokumentation sollte dem gleichen DRY-Prinzip wie der Code folgen. Allgemeine Anforderungen an das UI-Styling sollten zusammengefasst werden. Wenn die für die Anforderungen verantwortliche Person wirklich möchte, kann sie in den funktionalen Anforderungen auf nichtfunktionale Anforderungen (einzeln oder als Gruppe) verweisen.

Versionsverwaltung Wenn Sie sich in einer Unternehmensumgebung mit vielen "Standards" befinden, können Sie bestimmte Dokumente zu Benutzeroberflächen- oder Sicherheitsanforderungen (um nur einige zu nennen) erstellen, die versioniert werden können. Auf diese Weise können Sie in die anwendungsspezifischen Anforderungen (meistens funktionale Anforderungen) schreiben: "Die Anwendung muss V2.3 der in XYZ-Company-SecReq-DocumnentNamingStandard.docx definierten Sicherheitsanforderungen einhalten".

Warum sollte man zwischen funktionalen und nicht funktionalen Anforderungen unterscheiden?

Ein Grund für die Unterscheidung ist die Abstraktionsebene zwischen den beiden Typen. Nichtfunktionalisierte Anforderungen befinden sich auf Systemebene und geben an, wie sich das System insgesamt verhalten muss. Die funktionalen Anforderungen beziehen sich auf ein bestimmtes Merkmal und darauf, welche Merkmale und Funktionen den Kunden bereitgestellt werden müssen.

Nicht funktionierende Anforderungen schränken das System ebenfalls ein, während funktionierende Anforderungen angeben, was das System tun muss. Die nichtfunktionalen Anforderungen begrenzen, wie die funktionalen Anforderungen später entworfen und implementiert werden sollen. Durch die Trennung wird es möglich, die Merkmale eindeutig von den Einschränkungen und Beschränkungen zu unterscheiden.

Was ich fürchte, sind Anforderungen, die in einem Dokument zusammengefasst sind. Ich habe versucht, den Nutzen in praktischen Begriffen zu erklären, konnte ihn aber nicht verkaufen. Wie verkaufe ich den Vorteil, zu dokumentieren, welche Anforderungen funktionsfähig und welche nicht funktionsfähig sind?

Nach meinen Erfahrungen werden funktionale und nichtfunktionale Anforderungen tatsächlich in demselben Dokument zusammengefasst oder in demselben System nachverfolgt. Sie erhalten jedoch ihre eigenen, separaten Abschnitte des Dokuments sowie Erfolgskriterien für die Erfüllung der einzelnen Abschnitte.

Im Allgemeinen kategorisieren Sie Anforderungen, damit das Team gegen sie vorgehen kann. Wenn es eine Anforderung gibt, die speziell auf eine architektonische Anforderung zugeschnitten ist, sollte die Bezeichnung "Architektur" dem Team bei der Arbeit an der Architektur helfen.

Ein großes einzelnes Dokument mit allen Anforderungen ist nicht unbedingt eine schlechte Sache ... Es ist auch nicht schlecht, 2 Tage damit zu verbringen, es zu überprüfen. Das Problem besteht in der Regel darin, dass eine Person, die die Anforderungen überprüft hat, sie versteht. Es ist jedoch für andere nicht einfacher, dasselbe zu tun. Es kann eine große Hilfe sein, Kennzeichnungsanforderungen mit Metadaten zu beginnen, die den anderen Personen, die sich dem Projekt anschließen, helfen.

Vielleicht versuchen Sie es als Abstraktionsproblem zu beschreiben. Wenn Sie in einer älteren Codebasis arbeiten müssen, lesen Sie nicht einfach alle vorhandenen Codezeilen durch, sondern beginnen mit der Arbeit. Sie folgen der Struktur des Codes, um Ihnen zu helfen. Eine gewisse Struktur in den Anforderungen zu haben, hilft auf die gleiche Weise.

Die Trennung hat mehrere Vorteile.

1. Sparen Sie Zeit beim Testen (dh testen Sie nur die funktionalen Anforderungen)
2. Spart Zeit bei zukünftigen Änderungen an den Anforderungen (dh nicht-funktionale Anforderungen benötigen weniger Zeit zum Überprüfen / Genehmigen / Implementieren / Testen)
3. In einer regulierten Welt (dh FDA usw.) Erfordern nicht funktionale Anforderungen ein Zehntel der Menge an Papierkram, die für funktionale Anforderungen erforderlich ist.
4. Bietet dem Team die Möglichkeit, die Arbeit zwischen älteren (funktionalen) und jüngeren (nicht funktionalen) Teammitgliedern aufzuteilen.

Ich könnte weitermachen ...

Oberflächlich betrachtet scheinen zwei Tage eine lange Zeit zu sein, auf lange Sicht könnten Wochen oder sogar Monate an zukünftiger Arbeit gespart werden.