Anforderungen strukturieren – 3. Die Spezifikation

Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?

Doch zuerst einmal die Frage:

Was verstehe ich unter einer „Spezifikation“?

Eine Spezifikation ist eine Menge von Anforderungen mit gemeinsamem Scope. Allgemeiner gesagt: Eine Spezifikation ist ein Entwicklungsartefakt, das ein bestimmtes System umfassend beschreibt, bestehend aus einer Sammlung von Anforderungen und ergänzenden Informationen. Die Spezifikation sollte „rund“ und „umfassend“ sein, d.h. verständlich, abgestimmt und frei von Widersprüchen, Redundanzen und nicht-notwendigen Anforderungen.

Welcher Detaillierungsgrad?

Eine Spezifikation beschreibt das System auf einer bestimmten Abstraktionsebene, und zwar auf eine Weise, so dass alles beschrieben ist, „was“ das System können oder besitzen muss. Die Detailierung geht idealerweise genau so weit, bis das „Wie“ für den jeweiligen Scope der Spezifikation „egal“ und unerheblich ist. Voraussetzung dafür ist, dass Sie bzw. die Stakeholder der Spezifikation genau wissen, was das “System” und dessen “Grenzen” sind.

Dann können folgende Kapitel eine gute Ausgangsbasis für Ihre Spezifikation sein:

Kapitel  1: Systembeschreibung

Hier sollten Sie kurz beschreiben, was Ihr System überhaupt darstellt, sodass der Leser einen schnellen Einstieg und eine gute Übersicht bekommt.

Kapitel 2: Systemkontext

Hier sollten Sie kurz beschreiben, in welchem Kontext sich Ihr System befindet: Was befindet sich außerhalb Ihres Systems, und mit welchen anderen Systemen spielt Ihr System zusammen? In welchem Umfeld wird Ihr System betrieben?

Hier könnten Sie auch das aktuelle Projekt erwähnen und auf zugehörige Dokumente verweisen (Projekthandbuch, Projektplan, Systems Engineering Plan,..).

Kapitel 3: Definitionen

Hier beschreiben sie Begriffe und Definitionen, die innerhalb der Spezifikation häufig gebraucht werden. Manche Begriffe müssten Sie sonst bei jeder Anforderung immer wieder genau beschreiben. Begriffe wie z.B. „normaler Betriebszustand“, „Ruhezustand des Systems“, „Nutzerszenario 2“, „Standardbelastung“, „Sondereinsatzbereich“, usw. können hier einmal erklärt und definiert werden. Diese können Sie später, in den Anforderungen selbst, als vordefinierten Begriff referenzieren (z.B. angezeigt durch kursive oder fette Schreibweise). Damit vereinfachen Sie sich die Formulierungsarbeit bei den einzelnen Anforderungen.

Definitionen, Formeln und weiterführende Beschreibungen und zugehörige Informationen können Sie hier gut platzieren. Hier verweisen Sie auch auf das projektweite Glossar, das die übergreifenden Begriffe, Abkürzungen und Definitionen enthält.

Kapitel 4: Blackbox Anforderungen

Hier stehen die Anforderungen an Ihr System. „Blackbox“-Anforderungen betrachten das System von außen, ohne das „Wie“ oder das „Innere“ des Systems zu beschreiben.

Sichten

Generell liegen Sie richtig, wenn sie vor allem nach den Kriterien Nr. 1 –  3 aus Teil 1 untergliedern, die da waren: „Stakeholder“, „Organisationsstruktur“ und „Lebenszyklusphasen“. Unterschiedliche Sichten auf das System eignen sich gut zur Strukturierung. Sichten ergeben sich auch indirekt aus dem Vorgehen bei der Stakeholder-Analyse und der Anforderungserhebung.

Allerdings sollten Sie berücksichtigen, dass Sichten als Gliederung die Gefahr von Redundanzen, oder auch Widersprüchen in der Spezifikation bergen, da viele Anforderungen aus mehreren Sichten gleichzeitig relevant sein können. Bei einer “Kunden”-Spezifikation, bei der alle Kunden- und Stakeholdersichten gesammelt werden sollen, könnte das noch in Ordnung sein. Jedoch spätestens in einer (daruntergeordneten) System-Spezifikation sollten alle Anforderungen konsolidiert vorliegen.

Sichten der Stakeholder

Stellen Sie viele „W“-Fragen um viele verschiedene Sichten zu bekommen: Wer zahlt das System, wer nutzt es, wer ist für Sicherheit, Entwicklung, Test, usw. verantwortlich, …? Daraus ergeben sich Sichten bzw. Kapitel wie z.B.: Nutzeranforderungen, Entwickleranforderungen, Sicherheitsanforderungen, Anforderungen abgeleitet aus Normen und Gesetzen, Service-Anforderungen, Software-Anforderungen, physikalische Sicht, logische Sichten.

Funktionale Sichten

Es hat sich häufig bewährt, als primäre Strukurierung die funktionalen Sichten zu wählen: Welche Hauptfunktionen muss das System erfüllen, welche Funktionsbereiche hat es? Nutzerfunktionen, Service-Funktionen, Sicherheitsfunktionen, Diagnosefunktionen, Wartungsfunktionen etc.

Tipp:

Funktionale Sichten lassen sich sehr gut mit  SysML/UML Use-Cases oder auch mit User Storys erstellen. Sie können solche direkt an dieser Stelle erstellen, oder separat in einem anderen Entwicklungsartefakt. Oder sie leiten hier Anforderungen von den zuvor erstellten Use Cases/User Storys ab, und referenzieren dann von hier darauf.

Funktionale Anforderungen beschreiben übrigens eine Funktion des Systems, wie der Name schon sagt:  Es gibt einen Input, das System macht etwas, und dann entsteht ein Output. Das bedeutet, funktionale Anforderungen lassen sich in der Regel gut direkt testen. Für die Erstellung von Anforderung bedeutet das, dass eine große Detaillierung von funktionalen Anforderungen voraussichtlich nicht nötig sein wird – im Gegensatz zu der folgenden Kategorie:

Nicht-funktionale Sichten

… sind Qualitätsanforderungen. Das sind vor allem „-keits/-heits“-Anforderungen (engl.: „-ility“-requirements), wie Anforderungen an Benutzbarkeit, Bedienbarkeit, Betriebssicherheit, Datensicherheit, Zuverlässigkeit, Wartbarkeit, Wiederverwertbarkeit, Übertragbarkeit, Transportierfähigkeit.

Ich rate in aller Regel davon ab, die nicht-funktionalen Anforderungen in ein separates Kapitel auszulagern. Für das Verständnis des Zusammenhangs ist es meines Erachtens nach besser, die nicht-funktionalen Aspekte im Kontext der Funktion zu beschreiben, für die sie relevant sind. Also z.B. “die maximale Ausführungszeit” und “Verfügbarkeit” einer Funktion im Kontext der Funktion, für die sie gelten. Nur übergreifend gültige Aspekte, die keinen direkten Bezug zu einer konkreten Funktion haben, sollten in einem separaten Kapitel beschrieben werden.

Als Checkliste, um nicht-funktionale Anforderungen zu identifizieren, helfen Kategorie-Vorlagen, von denen es einige gibt, wie zum Beispiel …

… nach ISO 9126:

• Functionality (Accuracy, Security, Interoperability, Suitability)
• Reliability (Maturity, Fault Tolerance, Recoverability)
• Usability (Understandability, Learnability, Operability, Attractiveness)
• Efficiency (Time Behaviour, Resource Utilisation)
• Maintainability (Analyzability, Changeability, Stability, Testability)
• Portability (Adaptability, Installability, Co-Existence, Replaceability)

 

…nach RUP/Robert Grady:

„FURPS+“, heißt: Functionality, Usability, Reliability, Portability, Supportability,
“+” = Design Constraints, Implementation Requirements, Interface Requirement,  Physical Requirement

…nach Volere:

Look and Feel, Usability and Humanity, Performance, Operational and Environmental, Maintainability and Support, Security, Cultural and Political, Legal. Siehe auch http://www.volere.co.uk/template.htm

Welche Qualitätsdimensionen Sie wirklich für Ihr System und Projekt brauchen, ist auch ein Ergebnis aus der zuvor durchgeführten Stakeholderanalyse und Anforderungserhebung.

Bei Qualitätsanforderungen treten noch ein paar interessante Aspekte auf:

Viel Arbeit für den Anforderungsmanager

Nicht-funktionale Anforderungen ziehen üblicherweise viel Spezifikations- und Entwicklungsaufwand hinter sich. Nicht-funktionale Anforderungen müssen meist weiter detailliert und durch viele weitere, auch funktionale Anforderungen detailliert und erfüllt werden. Das passiert dann in Spezifikationen der darunter liegenden Abstraktionsebenen.

Ein Beispiel:

„Das System muss sicher bedienbar sein“

endet in vielen Detail-Anforderungen, u.a.

„Das System darf keine scharfen Kanten besitzen“,

„Das System muss bei einer Temperatur über  80 °C automatisch abschalten“,

„Das System muss Vorrichtungen haben, dass die Wahrscheinlichkeit einer Verletzung des Nutzers für die 10 häufigsten Unfallursachen des Vorgängersystems um 95% verringert.“

usw., usf., …

Am Beispiel sehen Sie, dass die ursprüngliche Anforderung schon mit  3 detaillierteren Anforderungen verfeinert wurde. Jedoch sind vermutlich noch weitere zu detaillieren. Viele enden dann in funktionalen Anforderungen wie

„Das System muss bei Erkennen einer Temperatur von über 80 °C innerhalb von 0,5 Sekunden die Stromversorgung abschalten.“, usw.

Performance-Anforderungen

„Performance-Anforderungen“ sind formal nicht-funktionale Anforderungen:

Beispiel: „Das Auto muss in 4 Sekunden von 0 auf 100 km/h beschleunigen können.“

Da jedoch Performance Anforderungen oft essentielle Eigenschaften des Systems darstellen, werden sie gerne separat in einem extra Abschnitt behandelt.

Kapitel 5: Schnittstellenbeschreibung

Auch die Beschreibung der “Schnittstellen des Systems nach außen” gehört hierher, wenn Sie diese nicht in eine oder mehrere separate Spezifikationen auslagern möchten.

Es gibt viele Gründe, die Spezifikation der Schnittstellen in einer eigenen Schnittstellenspezifikation zu halten und hier, an dieser Stelle nur darauf zu referenzieren:

• Schnittstellenbeschreibungen sind sehr umfangreich
• Schnittstellen haben mehrere Ebenen wie mechanisch (Verbindungen),  physikalisch ( Steckertyp etc.), elektrisch (Strom, Spannung, Signalformen etc.), logisch (Bits und ihre Bedeutung, Protokolle,…), etc.
• Schnittstellen haben meist einen anderen Entwicklungs-Lebenszyklus wie die Systemanforderungen. Details werden möglicherweise sehr spät in der Entwicklung festgelegt.

Kapitel 6: Whitebox-Anforderungen

Sie haben die Möglichkeit, in einem weiteren Abschnitt die „Whitebox“-Eigenschaften des Systems zu sammeln. Ein System besteht aus Subsystemen, die normalerweise wieder ihre eigenen Blackbox-Anforderungen und ihre eigenen Spezifikationen haben.

Whitebox Anforderungen sind nicht für eine Kundenspezifikation oder ein Lastenheft geeignet. Jedoch in einer System-Spezifikation oder einem Pflichtenheft können Sie hier das Zusammenspiel der Subsysteme beschreiben. Damit ist man eigentlich schon eine Abstraktionsebene tiefer, jedoch bei kleinen Spezifikationen ist hier ein guter Platz dafür.

Um solche Anforderungen zu erstellen, ist allerdings Entwicklungsarbeit notwendig. Fachexperten, Architekten und Designer müssen entscheiden, wie das System auf Subsysteme heruntergebrochen wird. Architekturen sind eigentlich kein Bestandteil einer Systemspezifikation, sondern werden parallel oder nach den Anforderungen entwickelt, im Übergang auf die nächste Anforderungs-Detailebene. Diese Architektur- und Entwurfs-Beschreibungen werden oft in anderen Artefakten wie Architekturdokumenten, Designspezifikationen, etc. festgehalten.

In größeren Systemen sind Whitebox- und Blackbox-Anforderungen keine Kapitel einer Spezifikation, sondern Spezifikationen auf zwei unterschiedlichen Abstraktiosebenen, entsprechend einer Problem- und einer Lösungsdomain.

Kapitel 7: Subsysteme

Als weiteres Kapitel könnten Sie hier, aber nur bei recht kleinen Systemen, die Sub-System-Anforderungen in ein Unterkapitel einer Gesamtspezifikation mit aufnehmen. Dies eignet sich dann, wenn Sie Ihr System z.B. nur noch auf sehr wenige Subsysteme herunterbrechen wollen, z.B. Mechanik-Subsystem, Elektrik-Subsystem und die Software-Anforderungen.
Idealerweise erstellen Sie jedoch für jedes Subsystem eine weitere Spezifikation auf der nächsttieferen Abstraktionsebene.

Zusammenfassung

Ich hoffe, sie haben genügend Anregungen bekommen, um nun eine gut strukturierte Spezifikation zu erstellen. Nehmen sie die vorgeschlagenen Kapitel, Elemente und Tipps als Anregung, und bauen sie sich daraus die zu Ihnen passende Spezifikation. HOOD kann Ihnen gerne dabei helfen, Ihre individuelle Spezifikationslösung zu kreieren. Ihre Anmerkungen oder Fragen schreiben Sie mir gerne hier als Kommentar oder als Email.

Im nächsten Blog dieser Serie (Teil 4) geht es dann um die Strukturierung von Anforderungen in mehreren Anforderungsdokumenten und Entwicklungsartefakten. Ich freue mich schon auf Sie!

Verwandte Blogbeiträge:

Systemanforderungen, wozu der Aufwand?

Anforderungen langfristig dokumentieren, im agilen Umfeld

Anforderungsdokumentation ist nicht generell sinnvoll

Möchten Sie mehr zum Thema “Anforderungen”bzw. “Spezifikation” erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Trainings zum Requirements Engineering zu besuchen. Ob der Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung, CPRE Advanced Level, oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei. 

 

Series Navigation

<< Anforderungen strukturieren – 2. TechnikenAnforderungen strukturieren – 4. Das Informationsmodell >>