Requirements for Software Architects
Requirements for Software Architects
Mit Requirements Engineering zu den besten Anforderungen
Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas über die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.
Abbildungs 1: Wie Projekte wirklich funktionieren
Einführung und Überblick
Requirements Engineering und Softwarearchitektur sind in der Welt der Softwareentwicklung Tätigkeitsbereiche, die große Teilverantwortungen tragen, um Softwareentwicklungsprojekte erfolgreich abzuschließen. Letztlich geht es darum, die Kundenbedürfnisse zu erfüllen und den Kunden zufrieden zu stellen. Um dies zu erreichen, muss man den Kunden richtig verstehen und wissen, was er tatsächlich braucht.
In diesem Stadium sind Anforderungen und deren Management Hauptakteure im Softwareentwicklungsprozess .
Anforderungen sind in Softwareprojekten das Abbild der Kundenwünsche. Sie dienen als zentrale Briefings für fast alle weiteren Tätigkeiten. Die korrekte Erhebung, Erfassung, Überprüfung, Pflege und Verfeinerung von Anforderungen beeinflusst folglich den gesamten Software-Lebenszyklus und ist somit entscheidend für den Erfolg von Softwareentwicklungsprojekten.
Im Software-Lebenszyklus sind die Phasen der Anforderung und der Softwarearchitektur direkt aufeinander folgend und daher besonders stark miteinander verzahnt, fehlerhaftes Anforderungsmanagement hat dementsprechend direkte, schwerwiegende Folgen auf architektonische Entscheidungen.
Abbildung 2: Software-Lebenszyklus
In den folgenden Abschnitten geben wir einen Überblick über Anforderungsmanagement und Softwarearchitektur, bzw. wie sie sich einander ergänzen und gegenseitig beeinflussen. Dazu betrachten wir die beiden Rollen des Softwarearchitekten und eines Product Owners, sowie ihre Verantwortlichkeiten und Aufgaben in Softwareentwicklungsprojekten. Zuvor klären wir einige Grundbegriffe.
Anforderungen Definition und Grundbegriffe
„Requirement“ (englisch) bedeutet so viel, wie „Vorausgesetztes“ oder „verpflichtendes Erfordernis“, aber auch Erwartung. Wie bei vielen Begriffen aus der IT-Welt gibt es für den Begriff „Anforderung“ zahlreiche Definitionen.
Requirements Engineering Board (IREB) definiert Anforderung hingegen als:
• ein Bedürfnis, das von einem Stakeholder wahrgenommen wird.
• eine Fähigkeit oder Eigenschaft, die ein System haben soll.
• eine dokumentierte Darstellung eines Bedarfs, einer Fähigkeit oder eines Eigentums.
Für das International Institute of Business Analysis (IIBA) ist eine Anforderung eine brauchbare Darstellung eines Bedürfnisses, die in der Regel durch Dokumente beschrieben wird.
Daraus abgeleitet können Anforderungen als eine Aussage über den zu erreichenden Merkmalen oder die zu erbringenden Leistungen für eine Software oder System definiert werden.
Arten von Anforderungen
In der Literatur gibt es viele Unterteilungen oder Klassifizierungen von Anforderungen. Zum Zwecke dieses Inhalts betrachten wir nur zwei (bekannte) Hauptkategorien, funktionale (FR) und nicht-funktionale Anforderungen (NFR).
Nichtfunktionalen Anforderungen fallen wiederum in zwei Kategorien: Die Qualitätsanforderung oder Qualitätskriterien und die Einschränkungen (eng. constraints)
Abbildung 3: Gute vs. schlechte Anforderungen
Funktionale Anforderungen
Das „WAS“ legt die Funktionale Anforderungen fest, was das Produkt tun soll. Ein Beispiel:
„Das System soll die geleisteten Arbeitsstunden eines Mitarbeiters für einen bestimmten Zeitraum berechnen.“
Das bedeutet, dass sich die funktionalen Anforderungen lediglich auf die Verhaltensergebnisse beziehen, die die Funktionalität des Systems oder der Software liefern soll.
Nichtfunktionale Anforderungen (NFRs)
Die nicht-funktionalen Anforderungen (NFR) beschreiben, wie gut das System die Leistung erbringen soll und unter welchen Rahmenbedingungen und sind eine Herausforderung für jeden PO. Sie werden typischerweise in zwei Bereiche untergliedert:
• Qualitätskriterien
• Einschränkungen
Qualitätskriterien
… sind Anforderungen, die sich auf ein Qualitätsproblem beziehen, das nicht durch funktionale Anforderungen abgedeckt ist.
Diese werden (z.B. nach Volere) in Ausführungsqualität und Weiterentwicklungsqualität gegliedert.
Ausführungsqualität (während des Betriebs / zur Laufzeit)
- Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
- Aussehen und Handhabung (Look-and-feel)
- Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
- Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)
- Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)
- Korrektheit (Ergebnisse fehlerfrei)
Weiterentwicklungs- und Evolutionsqualität
- Betriebs- und Umgebungsbedingungen
- Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
- Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
- Flexibilität (Unterstützung von Standards)
- Skalierbarkeit (Änderungen des Problemumfangs bewältigen)
Eine andere Aufteilung von Nichtfunktionalen Anforderungen findet man in der ISO 25010. Hier werden die Qualitätsanforderungen anhand 8 Kriterien beschrieben.
Abbildung 7: Standard ISO/IEC 25010. Software product quality model
1. Funktionale Eignung
- Funktionelle Vollständigkeit
- Korrekte Funktionalität
- Angemessene Funktionalität
2. Verlässlichkeit
- Reife
- Verfügbarkeit
- Fehlertoleranz
- Wiederherstellbarkeit
3. Leistungseffizienz
- Zeitverhalten
- Ressourcennutzung
- Kapazitätsaufwand
4. Nutzbarkeit
- Angemessene Erkennbarkeit
- Erlernbarkeit
- Bedienbarkeit
- Schutz vor Fehlbedienung durch den Nutzer
- User-Interface Ästhetik
- Zugänglichkeit
5. Wartbarkeit
- Modularität
- Wiederverwendbarkeit
- Analysierbarkeit
- Modifizierbarkeit
- Testfähigkeit
6. Sicherheit
- Datenschutz
- Integrität
- Unmanipulierbarkeit
- Administrationsfähigkeit
- Authentifizierbarkeit
7. Kompatibilität
- Co-Existenz (zu weiterer Software)
- Interoperabilität
8. Portierbarkeit
- Anpassungsfähigkeit
- Installierbarkeit
- Austauschbarkeit
Einschränkungen
… sind Anforderungen, die den Lösungsraum über das hinaus beschränken, was zur Erfüllung spezifizierter funktionaler Anforderungen und Qualitätsanforderungen erforderlich ist.
Es gibt verschiedene Arten von Einschränkungen, z.B. zeitliche Terminplanbeschränkung, regulatorische oder gesetzliche Beschränkungen usw.
In Softwareprojekten spricht man von Einschränkungen, wenn Faktoren wie Zeit, Geld, Umfang (das sogenannte „Magische Dreieck“) oder Ressourcen, wie Ausrüstung oder Personalmangel das Projekt beeinflussen.
Abbildung 8: Das magische Dreieck
Die Einschränkungen hängen auch von dem Tätigkeitsbereich des Unternehmens sowie den Dienstleistungen ab, welches es anbietet.
Im Gesundheitswesen beispielsweise können bestimmte Vorschriften oder Gesetze die Qualität von Software oder sogar die Implementierung der gesamten Softwarearchitektur beeinträchtigen.
Aus allen diesen Gründen ist es wichtig, dass sich der Softwarearchitekt bereits zu Beginn des Projekts mit den verschiedenen Einschränkungen auseinandersetzt und mit den Key Rollen abklärt.
Wir freuen uns schon, Sie beim nächsten Artikel unserer Blog-Serie wieder begrüßen zu dürfen – dem Agile Requirements Engineering und seine Rollen.
Quellen
- Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
- Andreas Wintersteiger, Scrum Schnelleinstieg
- McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
- https://t2informatik.de/
- North, Introducing Behaviour Driven Development
- Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
- Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
- “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
- Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
- https://www.scrum.org/
- http://agilemanifesto.org/
- https://www.isaqb.org/
- https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/
Abbildungen
Abbildung 1: https://cdn-images-1.medium.com/max/1200/1*ApoaIZicyU0b7Jgg9MMJhw.jpeg
Abbildung 2: ITech Progress CPSA-Foundation Kurs (Präsentation) – Kapitel 1: Grundbegriffe – Einordnung der Softwarearchitektur in Software-Lebenszyklus
Abbildung 4: https://www.nasa.gov/images/content/549928main_jfk_speech_226.jpg
Abbildung 5: https://www.nasa.gov/sites/default/files/styles/side_image/public/62297main_neil_on_moon_full.jpg?itok=1c8GTfbJ
Abbildung 6: https://miro.medium.com/max/1762/0*ohypH8bVpf2O0uIc.png
Abbildung 8: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png