1. Einführung und Zielsetzung
(engl.: Introduction and Goals)
Als Einführung in das Architekturdokument gehören
hierher die treibenden Kräfte, die Software-Architekten
bei Ihren Entscheidungen berücksichtigen müssen:
Einerseits die Erfüllung bestimmter fachlicher
Aufgabenstellungen der Stakeholder, darüber hinaus aber
die Erfüllung oder Einhaltung der vorgegebenen
Randbedingungen (required constraints) unter
Berücksichtigung der Architekturziele.
1.1 Aufgabenstellung
(engl.: Requirements Overview)
Kurzbeschreibung der fachlichen Aufgabenstellung,
Extrakt (oder Abstract) der Anforderungsdokumente.
Verweis auf ausführliche Anforderungsdokumente (mit
Versionsbezeichnungen und Ablageorten). Eine kompakte
Zusammenfassung des fachlichen Umfelds des Systems.
Beantwortet (etwa) folgende Fragen:
- Was geschieht im Umfeld des Systems?
- Warum soll es das System geben? Was macht das System wertvoll oder wichtig? Welche Probleme löst das System?
Aus Sicht der späteren Nutzer ist die Unterstützung einer fachlichen Aufgaben der eigentliche Beweggrund, ein neues (oder modifiziertes) System zu schaffen. Obwohl die Qualität der Architektur oft eher an der Erfüllung von nicht-funktionalen Anforderungen hängt, darf diese wesentliche Architekturtreiber nicht vernachlässigt werden. Kurze textuelle Beschreibung, eventuell in tabellarischer Use-Case Form. In jedem Fall sollte der fachliche Kontext Verweise auf die entsprechenden Anforderungsdokumente enthalten. Kurzbeschreibung der wichtigsten:
- Geschäftsprozessen,
- funktionalen Anforderungen,
- nichtfunktionalen Anforderungen und andere Randbedingungen (die wesentlichen müssen bereits als Architekturziele formuliert sein oder tauchen als Randbedingungen auf) oder
- Mengengerüste.
- Hintergründe Hier können Sie aus den Anforderungsdokumenten wiederverwenden - halten Sie diese Auszüge so knapp wie möglich und wägen Sie Lesbarkeit und Redundanzfreiheit gegeneinander ab.
1.2 Stakeholder
Eine Liste der wichtigsten Personen oder Organisationen, die von der Architektur betroffen sind oder zur Gestaltung beitragen können. Sie sollten die Projektbeteiligten und -betroffenen kennen, sonst erleben Sie später im Entwicklungsprozess Überraschungen. EInfache Tabelle mit Rollennamen, Personennamen, deren Kenntnisse, die für die Architektur relevant sind, deren Verfügbarkeit, etc. siehe z.B. VOLERE-Stakeholdertabelle in den Downloads oder lesen Sie Kapitel 5.2 in dem Buch "Requirements- Engineering und -Management" von Chris Rupp (siehe Literaturempfehlungen: Software-Engineering und verwandte Themen)
1.3 Architekturziele
(engl.: Goals for the Architecture)
Die Hitparade (Top-10) der Architekturziele und/oder
Randbedingungen, deren Erfüllung oder Einhaltung den
maßgeblichen Stakeholdern besonders wichtig sind.
Gemeint sind hier wirklich Architekturziele, nicht die
Ziele des Projekts. Beachten Sie den Unterschied.
Qualitätsziele könnten sein:
- Verfügbarkeit (availability)
- Änderbarkeit (modifiability)
- Performanz (performance)
- Sicherheit (security)
- Testbarkeit (testability)
- Bedienbarkeit (usability)
Wenn Sie als Architekt nicht wissen, woran Ihre Arbeit gemessen wird, können Sie während der Entwicklung kaum bestimmen, ob Ihre Lösung bereits gut genug ist oder nicht...
Mittel: Einfache tabellarische Darstellung, geordnet nach Prioritäten
Beginnen Sie NIEMALS mit einer Architekturentwicklung,
wenn diese Ziele nicht schriftlich festgelegt und von den
maßgeblichen Stakeholdern akzeptiert sind.
Quellen: Im DIN/ISO 9126 Standard finden Sie eine umfangreiche Sammlung möglicher Qualitätsziele. Für alle, die es nicht so genau wissen wollen: ein lesbarer Auszug davon ist im Buch "Agile Software- Entwicklung für Embedded Real-Time Systems mit der UML" (Hruschka, Rupp, Carl- Hanser-Verlag, 2002 auf Seite 9 zu finden (PH).