Virlag fir Decisiounsopzeechnung vun arc42

1. Aféierung a Ziler

Kuerz Beschreiwung vun den Ufuerderungen, den Treiwerkräften, Auszug (oder Abstract) vun den Ufuerderungen. Déi wichtegst dräi (maximal fënnef) Qualitéitsziler fir d'Architektur, déi d'héchste Prioritéit fir déi wichtegst Stakeholder hunn. Eng Tabell vun de wichtege Stakeholder mat hiren Erwaardungen un d'Architektur.

1.1 Iwwerbléck iwwer d'Ufuerderungen

Inhalt

Kuerz Beschreiwung vun den funktionellen Ufuerderungen, den Treiwerkräften, Auszug (oder Abstract) vun den Ufuerderungen. Links op déi (hoffentlech bestoend) Ufuerderungsdokumenter, mat Informatioun, wou een se fënnt.

Motivatioun

Aus der Siicht vun den Endbenotzer gëtt e System erstallt oder geännert, fir d'Ënnerstëtzung vun enger Geschäftsaktivitéit ze verbesseren an/oder d'Qualitéit ze verbesseren.

Form

Kuerz textuell Beschreiwung, wahrscheinlech am Tabellenformat vun Use Cases. Wann Ufuerderungsdokumenter existéieren, soll dësen Iwwerbléck op dës Dokumenter verweisen.

Haalt dës Auszich sou kuerz wéi méiglech. Wiegt d'Liesbarkeet vun dësem Dokument géint potenziell Redundanz par rapport zu Ufuerderungsdokumenter of.

1.2 Qualitéitsziler

Inhalt

Déi wichtegst dräi (maximal fënnef) Qualitéitsziler fir d'Architektur, deenen hir Erfëllung fir déi wichtegst Stakeholder vun héchster Wichtegkeet ass. Mir mengen wierklech Qualitéitsziler fir d'Architektur. Verwiesselt se net mat Projetszieler. Si sinn net onbedéngt identesch. D'ISO-25010-Norm bitt e schéinen Iwwerbléck iwwer potenziell interessant Themen.

Motivatioun

Dir sollt d'Qualitéitsziler vun Äre wichtegste Stakeholder kennen, well si fundamental Architekturdecisiounen beaflosse wäerten. Sidd ganz konkret iwwer dës Qualitéiten, vermeit Buzzwords. Wann Dir als Architekt net wësst, wéi d'Qualitéit vun Ärer Aarbecht beuerteilt gëtt …

Form

Eng Tabell mat de wichtegste Qualitéitszieler a konkrete Szenarien, no Prioritéit zortéiert.

1.3 Stakeholder

Inhalt

Explizit Iwwersiicht vun de Stakeholder vum System, dat heescht, all Persoune, Rolle oder Organisatiounen, déi

d'Architektur kennen sollen
vun der Architektur iwwerzeegt musse ginn
mat der Architektur oder mam Code musse schaffen
d'Dokumentatioun vun der Architektur fir hir Aarbecht brauchen
Decisiounen iwwer de System oder seng Entwécklung musse treffen

Motivatioun

Dir sollt all Parteien kennen, déi an der Entwécklung vum System involvéiert sinn oder vum System betraff sinn. Soss kënnt Dir méi spéit am Entwécklungsprozess onagreabel Iwwerraschunge erliewen. Dës Stakeholder bestëmmen den Ëmfang an den Detailléierungsgrad vun Ärer Aarbecht a vun hire Resultater.

Form

Tabell mat Rollennimm, Persounennimm an hiren Erwaardungen par rapport zu der Architektur a senger Dokumentatioun.

2. Restriktiounen

All, wat Teams bei Design- an Ëmsetzungsdecisiounen oder Decisiounen iwwer verwandte Prozesser aschränkt. Kann heiansdo iwwer eenzel Systemer erausgoen a fir ganz Organisatiounen a Firme gëltig sinn.

Inhalt

All Ufuerderung, déi Softwarearchitekten an hirer Fräiheet bei Design- an Ëmsetzungsdecisiounen oder Decisiounen iwwer de Entwécklungsprozess aschränkt. Dës Restriktioune ginn heiansdo iwwer eenzel Systemer eraus a si fir ganz Organisatiounen a Firme gëltig.

Motivatioun

Architekten sollen genau wëssen, wou si bei hiren Designdecisiounen fräi sinn a wou si sech u Restriktioune halen mussen. Mat Restriktiounen muss ëmmer ëmgaange ginn; si kënne se awer verhandelbar sinn.

Form

Einfach Tabelle vu Restriktiounen mat Erklärungen. Wann néideg, kënnt Dir se ennerdeelen a technesch Restriktiounen, organisatoresch a politesch Restriktiounen a Konventiounen (z.B. Programméier- oder Versiounsrichtlinnen, Dokumentatiouns- oder Nummkonventiounen)

3. Kontext an Ëmfang

Grenzt Äre System vu senge (externe) Kommunikatiounspartner of (Nopeschsystemer a Benotzer). Spezifizéiert d'extern Schnëttstellen. Gewisen aus enger Geschäfts-/Domäneperspektiv (ëmmer) oder enger technescher Perspektiv (optional)

Inhalt

Systemëmfang a -kontext — wéi den Numm et seet — grenzt Äre System (dat heescht Äre Scope) vun alle senge Kommunikatiounspartner of (Nopeschsystemer a Benotzer, dat heescht dem Kontext vun Ärem System). Domat spezifizéiert et d'extern Schnëttstellen.

Wann néideg, ënnerscheed tëscht dem Geschäftskontext (domänespezifesch Inputs an Outputs) an dem technesche Kontext (Kanäl, Protokoller, Hardware).

Motivatioun

D'Domäneschnëttstellen an d'technesch Schnëttstelle zu de Kommunikatiounspartner sinn ënnert de kritesche Aspekter vun Ärem System. Stellt sécher, datt Dir se komplett versteet.

Form

Verschidde Kontextdiagrammer
Lëschte vu Kommunikatiounspartner an hire Schnëttstellen.

3.1 Geschäftskontext

Inhalt

Spezifikatioun vun alle Kommunikatiounspartner (Benotzer, IT-Systemer, …) mat Erklärunge vun domänespezifeschen Inputs an Outputs oder Schnëttstellen. Optional kënnt Dir domänespezifesch Formater oder Kommunikatiounsprotokoller derbäifügen.

Motivatioun

All Stakeholder sollen verstoen, wéi eng Daten mam Ëmfeld vum System ausgetosch ginn.

Form

All Zort vun Diagrammer, déi de System als Black Box weisen an d'Domäneschnëttstelle zu de Kommunikatiounspartner spezifizéieren.

Alternativ (oder zousätzlech) kënnt Dir eng Tabell benotzen. Den Titel vun der Tabell ass den Numm vun Ärem System, déi dräi Spalte enthalen den Numm vum Kommunikatiouns- partner, d'Inputs an d'Outputs.

3.2 Technesche Kontext

Inhalt

Technesch Schnëttstellen (Kanäl an Iwwerdroungsmedien), déi Äre System mat sengem Ëmfeld verbannen. Zousätzlech eng Zouuerdnung vun domänespezifeschem Input/Output zu de Kanäl, dat heescht eng Erklärung, wéi eng I/O wéi ee Kanal benotzt.

Motivatioun

Vill Stakeholder treffen Architekturdecisiounen op Basis vun den technesche Schnëttstellen tëscht dem System a sengem Kontext. Besonnesch Infrastruktur- oder Hardware- Designer decidéieren dës technesch Schnëttstellen.

Form

Z.B. UML-Deployment-Diagramm, dat d'Kanäl zu Nopeschsystemer beschreift, zesumme mat enger Mapping-Tabell, déi d'Bezéiunge tëscht Kanäl an Input/Output weist.

4. Léisungsstrategie

Zesummefaassung vun de fundamentalen Decisiounen a Léisungsstrategien, déi d'Architektur formen. Kann Technologie, Top-Level-Zerleeung, Usätz, fir déi wichtegst Qualitéitsziler z'erreechen, a relevant organisatoresch Decisiounen enthalen.

Inhalt

Eng kuerz Zesummefaassung an Erklärung vun de fundamentalen Decisiounen a Léisungsstrategien, déi d'Architektur vum System formen. Dozou gehéieren

Technologiedecisiounen
Decisiounen iwwer d'Top-Level-Zerleeung vum System, z.B. d'Notzung vun engem Architekturmuster oder Designmuster
Decisiounen, wéi wichtegt Qualitéitsziler erreecht ginn
relevant organisatoresch Decisiounen, z.B. d'Wiel vun engem Entwécklungsprozess oder d'Delegatioun vu bestëmmten Aufgaben u Drëttpartnere.

Motivatioun

Dës Decisioune bilden d'Eckpfeiler fir Är Architektur. Si sinn d'Basis fir vill aner detailléiert Decisiounen oder Ëmsetzungsreegelen.

Form

Haalt d'Erklärung vun dëse Schlësseldecisiounen kuerz.

Begrënnt, wat Dir decidéiert hutt a firwat Dir sou decidéiert hutt, baséierend op Är Problemstellung, d'Qualitéitsziler a wichteg Restriktiounen. Verweist op Detailer an den nächste Rubriken (Rubrik 5 fir strukturell Detailer, Rubrik 8 fir funktiounsiwwergräifend Konzepter).

Dir kënnt eng Lëscht vu Léisungsusätz oder eng Tabell benotzen.

5. Bausteen-Siicht

Statesch Zerleeung vum System, Abstraktioune vum Quellcode, gewisen als Hierarchie vu White Boxes (déi Black Boxes enthalen), bis zum passenden Niveau vun Detail.

Inhalt

D'Bausteen-Siicht weist déi statesch Zerleeung vum System a Bausteen (Moduler, Komponenten, Subsystemer, Klassen, Schnëttstellen, Packagen, Bibliothéiken, Frameworks, Layeren, Partitiounen, Tiers, Funktiounen, Makroen, Operatiounen, Datestrukturen, …) souwéi hir Ofhängegkeeten (Bezéiungen, Associatiounen, …)

Dës Siicht ass obligatoresch fir all Architekturdokumentatioun. Analog zu engem Haus ass dat de Grondrëss.

Motivatioun

Haalt en Iwwerbléck iwwer Äre Quellcode, andeems Dir seng Struktur duerch Abstraktioun verständlech maacht.

Dat erlaabt Iech, mat Äre Stakeholder op engem abstrakten Niveau ze kommunizéieren, ouni Ëmsetzungsdetailer ze verroden.

Form

D'Bausteen-Siicht ass eng hierarchesch Sammlung vu Black Boxes a White Boxes (kuckt d'Figur ënnen) an hir Beschreiwungen.

5.1 Whitebox vum Gesamtsystem

Hei beschreift Dir d'Zerleeung vum Gesamtsystem mat dem folgende White-Box-Virlag. Hien enthält

en Iwwerbléckdiagramm
eng Motivatioun fir d'Zerleeung
Black-Box-Beschreiwunge vun den enthaltene Bausteen. Dofir bidde mir Iech Alternativen:
- benotzt eng Tabell fir en kuerzen a pragmatesche Iwwerbléck vun alle enthaltene Bausteen an hire Schnëttstellen
- benotzt eng Lëscht vu Black-Box-Beschreiwunge vun de Bausteen no dem Black-Box-Virlag (kuckt ënnen). Jee no Är Tool-Wiel kann dës Lëscht Ënnerkapitelen (a Textdateien), Ënnersäiten (an engem Wiki) oder verschachtelt Elementer (an engem Modelléierungstool) sinn.
- (optional:) wichteg Schnëttstellen, déi net an de Black-Box-Virlage vun engem Baustee erkläert ginn, awer ganz wichteg sinn, fir d'White Box ze verstoen.

Well et sou vill Weeër gëtt, Schnëttstellen ze spezifizéieren, bidde mir kee spezifesche Virlag dofir un.

Am beschte Fall kommt Dir mat Beispiller oder einfache Signaturen duer.

5.2 Niveau 2

Hei kënnt Dir d'intern Struktur vun (e puer) Bausteen aus dem Niveau 1 als White Boxes spezifizéieren.

Dir musst decidéieren, wéi eng Bausteen vun Ärem System wichteg genuch sinn, fir esou eng detailléiert Beschreiwung ze rechtfäerdegen. Bevirzugt w.e.g. Relevanz virun Vollständegkeet. Spezifizéiert wichteg, iwwerraschend, riskant, komplex oder volatil Bausteen. Léisst normal, einfach, langweileg oder standardiséiert Deeler vun Ärem System eraus

5.2.1 White Box fir Baustee 1

Spezifizéiert déi intern Struktur vum Baustee 1.

Benotzt de White-Box-Virlag (kuckt uewen).

6. Laufzäit-Siicht

Verhalen vun de Bausteen als Szenarien, déi wichteg Use Cases oder Features, Interaktiounen un kritesche externe Schnëttstellen, Betrib an Administratioun plus Feeler- an Ausnamverhalen ofdecken.

Inhalt

D'Laufzäit-Siicht beschreift konkret Verhalen an Interaktioune vun de Bausteen vum System a Form vu Szenarien aus de folgende Beräicher:

wichteg Use Cases oder Features: wéi féieren d'Bausteen se aus?
Interaktiounen un kritesche externe Schnëttstellen: wéi kooperéiere d'Bausteen mat Benotzer a Nopeschsystemer?
Betrib an Administratioun: Start, Opstart, Stopp
Feeler- an Ausnamszenarien

Bemierkung: Dat Haaptcritère fir d'Wiel vu méigleche Szenarien (Sequenzen, Workflows) ass hir architekturrelevant Bedeitung. Et ass net wichteg, eng grouss Zuel vu Szenarien ze beschreiwen. Dir sollt éischter eng representativ Auswiel dokumentéieren.

Motivatioun

Dir sollt verstoen, wéi (Instanzen vun) Bausteen vun Ärem System hir Aarbecht maachen a wärend der Laufzäit kommunizéieren. Dir wäert haaptsächlech Szenarien an Ärer Dokumentatioun erfaassen, fir Är Architektur u Stakeholder ze kommunizéieren, déi manner gewëllt oder fäeg sinn, déi statesch Modeller (Bausteen-Siicht, Verdeelungssiicht) ze liesen a ze verstoen.

Form

Et gëtt vill Notatioune fir Szenarien ze beschreiwen, z.B.

nummeréiert Lëscht vu Schrëtt (a natierlecher Sprooch)
Aktivitéitsdiagrammer oder Flowcharts
Sequenzdiagrammer
BPMN oder EPCs (Event Process Chains)
Zoustandsmaschinnen
asw.

6.n Laufzäit-Szenario n (1, 2, 3, asw.)

Setzt en Laufzäitdiagramm oder eng textuell Beschreiwung vum Szenario an.

Setzt eng Beschreiwung vun den notabelen Aspekter vun den Interaktioune tëscht de Baustee-Instanzen an, déi an dësem Diagramm gewise ginn.

7. Verdeelungssiicht

Technesch Infrastruktur mat Ëmfelder, Computeren, Prozessoren, Topologien. Zouuerdnung vun (Software-)Bausteen zu Infrastrukturelementer.

Inhalt

D'Verdeelungssiicht beschreift:

déi technesch Infrastruktur, déi benotzt gëtt, fir Äre System auszeféieren, mat Infrastrukturelementer wéi geographesche Standuerter, Ëmfelder, Computeren, Prozessoren, Kanäl an Netztopologien souwéi aner Infrastrukturelementer a
d'Zouuerdnung vun (Software-)Bausteen zu deenen Infrastrukturelementer.

Dacks ginn Systemer a verschiddenen Ëmfelder ausgeféiert, z.B. Entwécklungsëmfeld, Testëmfeld, Produktiounsëmfeld. An esou Fäll sollt Dir all relevant Ëmfelder dokumentéieren.

Dokumentéiert d'Verdeelungssiicht besonnesch, wann Är Software als verdeelt System mat méi wéi engem Computer, Prozessor, Server oder Container ausgeféiert gëtt oder wann Dir är eege Hardwareprozessoren a Chips entwëerft a baut.

Aus enger Softwareperspektiv geet et duer, déi Elementer vun der Infrastruktur z'erfaassen, déi néideg sinn, fir d'Verdeelung vun Äre Bausteen ze weisen. Hardware-Architekte kënne doriwwer erausgoen an d'Infrastruktur op all Detailniveau beschreiwen, deen si brauchen.

Motivatioun

Software leeft net ouni Hardware. Dës zougrondeliegend Infrastruktur kann an wäert Äre System an/oder e puer funktiounsiwwergräifend Konzepter beaflossen. Dofir musst Dir d'Infrastruktur kennen.

Form

Vläicht ass dat héchstniveau Verdeelungsdiagramm schonn an der Rubrik 3.2. als technesche Kontext mat Ärer eegener Infrastruktur als EENER Black Box enthalen. An dëser Rubrik zoomt Dir mat zousätzlechen Verdeelungsdiagrammer an dës Black Box.

UML bitt Verdeelungsdiagrammer un, fir dës Siicht auszedrécken. Benotzt se, wahrscheinlech mat verschachtelte Diagrammer, wann Är Infrastruktur méi komplex ass.
Wann Är (Hardware-)Stakeholder aner Zorte vun Diagrammer amplaz UML-Verdeelungsdiagrammer bevirzugen, loosst si all Zort benotzen, déi Knäpp a Kanäl vun der Infrastruktur weise kann.

7.1 Infrastruktur Niveau 1

Beschreift (normalerweis an enger Kombinatioun vun Diagrammer, Tabellen an Text):

d'Verdeelung vun Ärem System op verschidde Standuerter, Ëmfelder, Computeren, Prozessoren, .. souwéi déi physesch Verbindungen tëscht hinnen
wichteg Rechtfäerdegung oder Motivatioun fir dës Verdeelungsstruktur
Qualitéits- an/oder Performance-Eegeschafte vun der Infrastruktur
d'Zouuerdnung vu Softwareartefakten (Bausteen) zu Elementer vun der Infrastruktur

Fir méi Ëmfelder oder alternativ Verdeelunge kopéiert w.e.g. dës Rubrik vun arc42 fir all relevant Ëmfelder. **

7.2 Infrastruktur Niveau 2

Hei kënnt Dir d'intern Struktur vun (e puer) Infrastrukturelementer vum Infrastruktur-Niveau 1 abannen.

Kopéiert w.e.g. d'Struktur vum Niveau 1 fir all gewielt Element.

8. Funktiounsiwwergräifend Konzepter

Allgemeng, prinzipiell Reegelungen a Léisungsusätz, déi a verschiddenen Deeler (→ funktiounsiwwergräifend) vum System relevant sinn. Konzepter si dacks mat méi Bausteen verbonnen. Bezitt verschidde Themen wéi Domänemodeller, Architektur- muster a -stiler, Reegele fir d'Notzung vu spezifescher Technologie an Ëmsetzungs- reegelen mat.

Inhalt

Dës Rubrik beschreift funktiounsiwwergräifend Konzepter (Praktiken, Muster, Reegelungen oder Léisungsiddien). Esou Konzepter si dacks mat méi Bausteen verbonnen. Si kënnen vill verschidden Themen enthalen.

Motivatioun

Konzepter bilden d'Basis fir konzeptionell Integritéit (Konsistenz, Homogenitéit) vun der Architektur. Dofir sinn si e wichtege Bäitrag, fir bannenzeg Qualitéite vun Ärem System z'erreechen.

Dëst ass d'Plaz am Virlag, déi mir fir eng kohäsiv Spezifikatioun vun esou Konzepter virgesinn hunn.

Vill vun dëse Konzepter bezéien sech op verschidde vun Äre Bausteen oder beaflosse se.

Form

D'Form kann variéieren:

Konzeptpabeieren mat all Zort vu Struktur
Beispillëmsetzungen, besonnesch fir technesch Konzepter
funktiounsiwwergräifend Modellauszich oder Szenarien mat Notatioune vun den Architektursiichten

Struktur vun dëser Rubrik

Wielt nëmmen déi am meeschte gebrauchte Themen fir Äre System aus a weist all eng Iwwerschrëft vum Niveau 2 an dëser Rubrik zou (z.B. 8.1, 8.2 asw).

VERSICHT NET, all Themen vum uewe genannten Diagramm ofzedecken.

Hannergrond

E puer Themen an Systemer betreffen dacks verschidde Bausteen, Hardwareelementer oder Entwécklungsprozesser. Et ka méi einfach sinn, esou funktiounsiwwergräifend Themen un enger zentraler Plaz ze kommunizéieren oder ze dokumentéieren, amplaz se an der Beschreiwung vun de betraffene Bausteen, Hardwareelementer oder Entwécklungsprozesser ze widderhuelen.

Verschidde Konzepter kënne all Elementer vun engem System betreffen, anerer sinn nëmme fir e puer relevant.

9. Architekturdecisiounen

Wichteg, deier, kritesch, grouss oder riskant Architekturdecisiounen inklusiv Begrënnungen.

Inhalt

Wichteg, deier, grouss oder riskant Architekturdecisiounen inklusiv Begrënnungen. Mat "Decisiounen" mengen mir d'Wiel vun enger Alternativ op Basis vu gegebene Critèren.

Benotzt w.e.g. Äert Uerteel, fir ze decidéieren, ob eng Architekturdecisioun hei an dëser zentraler Rubrik dokumentéiert soll ginn oder ob Dir se besser lokal dokumentéiert (z.B. am White-Box-Virlag vun engem Baustee). Vermeit redundant Texter. Verweist op d'Rubrik 4, wou Dir déi wichtegst Decisiounen vun Ärer Architektur schonn erfaasst hutt.

Motivatioun

Stakeholder vun Ärem System solle fäeg sinn, Är Decisiounen ze verstoen an nozevollzéien.

Form

ADR (Architektur-Decisiounsopzeechnung) fir all wichteg Decisioun
Lëscht oder Tabell, no Wichtegkeet a Konsequenzen zortéiert oder
méi detailléiert a Form vu separate Rubriken pro Decisioun

Hannergrond (zu ADR)

Méi kleng Dokumentatiounsstécker si méi einfach ze liesen, ze erstellen an ze erhalen. Wann et em Architekturdecisiounen geet, wëssen Entwécklungsteams dacks:

iwwer d'Decisioun Bescheed, well se z.B. am Quellcode siichtbar ass, awer
et feelt hinnen d'Motivatioun hannert där Decisioun (kuckt Nygard 2011)

Dofir sollt Dir e puer wichteg Decisiounen zesumme mat hirer Motivatioun, Begrënnung dokumentéieren

Eise Virschlag zu Decisiounen

Haalt eng Sammlung vun architekturrelevante Decisiounen, déi Decisiounen, déi d'Struktur, d'Qualitéitseegeschaften, wichteg (besonnesch extern) Ofhängegkeeten a Schnëttstellen oder Konstruktiounstechniken beaflossen (merci dem Michael Nygard fir dëse Virschlag).

10. Qualitéitsufuerderungen

Qualitéitsufuerderungen als Szenarien, mat Qualitéitsbam fir en Iwwerbléck op héijem Niveau. Déi wichtegst Qualitéitsziler sollten an der Rubrik 1.2. (Qualitéitsziler) beschriwwe gi sinn.

Inhalt

Dës Rubrik enthält all relevant Qualitéitsufuerderungen.

Déi wichtegst vun dësen Ufuerderunge si schonn an der Rubrik 1.2. (Qualitéitsziler) beschriwwe ginn, dofir sollen se hei just referenzéiert ginn. An dëser Rubrik 10 sollt Dir och Qualitéitsufuerderungen vu manner Wichtegkeet erfaassen, déi keng grouss Risike schafen, wa se net komplett erreecht ginn (awer eventuell wënschenswäert wieren).

Motivatioun

Well Qualitéitsufuerderunge vill Afloss op Architekturdecisiounen hunn, sollt Dir wëssen, wéi eng Qualitéite fir Är Stakeholder wierklech wichteg sinn, op eng spezifesch a messbar Aart a Weis.

Weider Informatiounen

Kuckt dat ëmfangräicht Q42-Qualitéitsmodell op https://quality.arc42.org.

10.1 Iwwerbléck iwwer d'Qualitéitsufuerderungen

Inhalt

En Iwwerbléck oder eng Zesummefaassung vun de Qualitéitsufuerderungen.

Motivatioun

Dacks begéine mir Dosende (oder souguer Honnerte) vun detailléierte Qualitéitsufuerderungen. An dëser Iwwerbléckrubrik sollt Dir probéieren, zesummenzefaassen, z.B. andeems Dir Kategorien oder Themen beschreift (wéi se vun der ISO 25010:2023 oder Q42 virgeschloe ginn

Wann dës zesummegefaasste Beschreiwungen schonn präzis, spezifesch genuch a messbar sinn, kënnt Dir d'Rubrik 10.2 iwwersprangen.

Form

Benotzt eng einfach Tabell, an där all Zeil eng Kategorie oder e Thema an eng kuerz Beschreiwung vun der Qualitéitsufuerderung enthält. Alternativ kënnt Dir eng Mindmap benotzen, fir dës Qualitéitsufuerderungen ze strukturéieren.

An der Literatur gouf och d'Iddi vun engem Qualitéitsattributbam beschriwwen, dee de generesche Begrëff "Qualitéit" als Wuerzel setzt an eng baumähnlech Verfeinerung vum Begrëff "Qualitéit" benotzt. [Bass+21] huet fir dëse Zweck den Begrëff "Quality Attribute Utility Tree" agefouert.

10.2 Qualitéitsszenarien

Inhalt

Qualitéitsszenarie maachen Qualitéitsufuerderunge konkret a erlaben ze entscheeden, ob si erfëllt sinn (am Sënn vun Akzeptanzcritèren). Stellt sécher, datt Är Szenarie spezifesch a messbar sinn.

Zwou Zorte vu Szenarie sinn besonnesch nëtzlech:

Notzungsszenarien (och Applikatiounsszenarien oder Use-Case-Szenarien genannt) beschreiwen d'Laufzäitreaktioun vum System op e bestëmmte Stimulus. Dozou gehéieren och Szenarien, déi d'Effizienz oder d'Performance vum System beschreiwen. Beispill: De System reagéiert bannent enger Sekonn op eng Ufro vun engem Benotzer.
Ännerungsszenarien beschreiwen den erwënschten Effekt vun enger Ännerung oder Erweiderung vum System oder vu sengem direkte Ëmfeld. Beispill: Zousätzlech Funktionalitéit gëtt ëmgesat oder Ufuerderunge fir en Qualitéitsattribut änneren sech, an den Opwand oder d'Dauer vun der Ännerung gëtt gemooss.

Form

Typesch Informatioun fir detailléiert Szenarie enthält folgendes:

An der kuerzer Form (bevirzugt am Q42-Modell):

Kontext/Hannergrond: Wéi eng Zort System oder Komponent, wat ass d'Ëmfeld oder d'Situatioun?
Quell/Stimulus: Wien oder wat initiéiert oder léist e Verhalen, eng Reaktioun oder Aktioun aus.
Metrik/Akzeptanzcritèren: Eng Äntwert inklusiv enger Mooss oder Metrik

Déi laang Form vu Szenarien (bevirzugt vum SEI a [Bass+21]) ass detailléierter an enthält folgend Informatiounen:

Szenario-ID: En eenzegaartegen Identifikator fir d'Szenario.
Szenario-Numm: E kuerzen, beschreibenden Numm fir d'Szenario.
Quell: Déi Entitéit (Benotzer, System oder Evenement), déi d'Szenario initiéiert.
Stimulus: Dat auslösend Evenement oder déi Bedingung, déi de System muss adresséieren.
Ëmfeld: De Betribskontext oder d'Bedingung, ënner där de System de Stimulus erliewt.
Artefakt: D'Bausteen oder aner Elementer vum System, déi vum Stimulus betraff sinn.
Äntwert: D'Resultat oder d'Verhale, dat de System als Reaktioun op de Stimulus weist.
Äntwertmooss: D'Critèren oder d'Metrik, mat där d'Äntwert vum System evaluéiert gëtt.

Kuckt och

Zënter Januar 2023 bitt arc42 e pragmatescht Qualitéitsmodell un, dat virschléit, Qualitéitsufuerderungen mat Hashtags oder Labelen wéi #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable ze markéieren.

11. Risiken an technesch Schold

Bekannt technesch Risiken oder technesch Schold. Wéi eng potenziell Problemer existéiere bannent oder ronderëm de System? Mat wat ass d'Entwécklungsteam onzefridden?

Inhalt

Eng Lëscht vun identifizéierten technesche Risiken oder technesche Scholden, no Prioritéit zortéiert

Motivatioun

"Risikomanagement ass Projetmanagement fir Erwuessen" (Tim Lister, Atlantic Systems Guild.)

Dat sollt Äre Motto sinn fir d'systematesch Erkennung an Evaluatioun vu Risiken a technesche Scholden an der Architektur, déi vu Management-Stakeholder (z.B. Projetmanager, Product Owners) als Deel vun der Gesamt- Risikoanalyse a Moossnamenplanung gebraucht ginn.

Form

Lëscht vu Risiken an/oder technesche Scholden, wahrscheinlech inklusiv virgeschloene Moossname, fir Risiken ze minimiséieren, ofzeschwächen oder ze vermeiden oder technesch Scholden ze reduzéieren.