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:
1.2 Qualitätsziele
(engl.: Quality Goals) Die Hitparade (Top-3 oder Top-5) 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:
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.
Die Details zu diesem Abschnitt stehen in Kapitel 10 (Bewertungsszenarien).
1.3 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)
(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?
- 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 Qualitätsziele
(engl.: Quality Goals) Die Hitparade (Top-3 oder Top-5) 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)
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.
Die Details zu diesem Abschnitt stehen in Kapitel 10 (Bewertungsszenarien).
1.3 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)