Requirements for Software Architects

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.

An dieser Stelle geht es nicht nur darum, dass der Requirements Engineer oder der Product Owner die richtigen Anforderungen (von den Kunden) aufgenommen hat, vielmehr geht es darum, dass der Softwarearchitekt den Product Owner richtig versteht und die von ihm bereitgestellten Anforderungen überprüft und analysiert, um darauf aufbauend seine architektonische Entscheidung treffen zu können.
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.

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)

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.

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.

 

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 3: https://www.softwareone.com/-/media/global/social-media-and-blog/content/requirements-engineering-4-graph1.png?mw=1024&rev=bc1dea2cb4d145c79f1f5b544e3a10cd&sc_lang=de-at&hash=43114D2C3FE79F36503891506BDBA9FA

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 7: https://www.researchgate.net/profile/Lina-Garces/publication/326584873/figure/fig2/AS:652083346808834@1532480193500/Standard-ISO-IEC-25010-Software-product-quality-model-and-system-quality-in-use-model.png

Abbildung 8: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png