arc42 lēmuma ieraksta veidne

https://arc42.org/overview

1. Ievads un mērķi

Īss prasību, virzītājspēku apraksts, prasību izvilkums (vai kopsavilkums). Trīs (ne vairāk kā pieci) arhitektūras kvalitātes mērķi ar augstāko prioritāti galvenajām ieinteresētajām pusēm. Svarīgāko ieinteresēto pušu tabula ar viņu gaidām attiecībā uz arhitektūru.

1.1 Prasību pārskats

Saturs

Īss funkcionālo prasību, virzītājspēku apraksts, prasību izvilkums (vai kopsavilkums). Saites uz (cerams, esošajiem) prasību dokumentiem ar informāciju, kur tos atrast.

Motivācija

No gala lietotāju viedokļa sistēma tiek izveidota vai mainīta, lai uzlabotu biznesa darbības atbalstu un/vai uzlabotu kvalitāti.

Forma

Īss teksta apraksts, iespējams, tabulārā lietošanas gadījumu formātā. Ja prasību dokumenti pastāv, šim pārskatam jāatsaucas uz šiem dokumentiem.

Saglabājiet šos izvilkumus pēc iespējas īsus. Līdzsvarojiet šī dokumenta lasāmību ar iespējamo atkārtošanos attiecībā pret prasību dokumentiem.

1.2 Kvalitātes mērķi

Saturs

Trīs (ne vairāk kā pieci) arhitektūras kvalitātes mērķi, kuru izpilde ir vissvarīgākā galvenajām ieinteresētajām pusēm. Mēs tiešām domājam kvalitātes mērķus arhitektūrai. Nejauciet tos ar projekta mērķiem. Tie nav obligāti identiski. Standarts ISO 25010 sniedz labu pārskatu par iespējamām interesējošām tēmām.

Motivācija

Jums jāzina savu svarīgāko ieinteresēto pušu kvalitātes mērķi, jo tie ietekmēs fundamentālos arhitektūras lēmumus. Pārliecinieties, ka esat ļoti konkrēts attiecībā uz šīm kvalitātēm, izvairieties no modes vārdiem. Ja jūs kā arhitekts nezināt, kā tiks vērtēta jūsu darba kvalitāte …

Forma

Tabula ar svarīgākajiem kvalitātes mērķiem un konkrētiem scenārijiem, sakārtota pēc prioritātēm.

1.3 Ieinteresētās puses

Saturs

Skaidrs sistēmas ieinteresēto pušu pārskats, t. i., visas personas, lomas vai organizācijas, kurām

• jāzina arhitektūra

• jābūt pārliecinātām par arhitektūru

• jāstrādā ar arhitektūru vai ar kodu

• savam darbam nepieciešama arhitektūras dokumentācija

• jāpieņem lēmumi par sistēmu vai tās izstrādi

Motivācija

Jums jāzina visas puses, kas iesaistītas sistēmas izstrādē vai ko sistēma ietekmē. Pretējā gadījumā vēlāk izstrādes procesā varat piedzīvot nepatīkamus pārsteigumus. Šīs ieinteresētās puses nosaka jūsu darba un tā rezultātu apjomu un detalizācijas līmeni.

Forma

Tabula ar lomu nosaukumiem, personu vārdiem un viņu gaidām attiecībā uz arhitektūru un tās dokumentāciju.

2. Ierobežojumi

Viss, kas ierobežo komandas projektēšanas un īstenošanas lēmumos vai lēmumos par saistītiem procesiem. Dažkārt var iziet ārpus atsevišķām sistēmām un attiekties uz veselām organizācijām un uzņēmumiem.

Saturs

Jebkura prasība, kas ierobežo programmatūras arhitektus viņu projektēšanas un īstenošanas brīvībā vai lēmumos par izstrādes procesu. Šie ierobežojumi dažkārt iziet ārpus atsevišķām sistēmām un attiecas uz veselām organizācijām un uzņēmumiem.

Motivācija

Arhitektiem precīzi jāzina, kur viņi ir brīvi savos projektēšanas lēmumos un kur viņiem jāievēro ierobežojumi. Ar ierobežojumiem vienmēr jārīkojas; tomēr tie var būt apspriežami.

Forma

Vienkāršas ierobežojumu tabulas ar paskaidrojumiem. Ja nepieciešams, varat tos sadalīt tehniskajos ierobežojumos, organizatoriskos un politiskajos ierobežojumos un konvencijās (piem., programmēšanas vai versiju izveides vadlīnijas, dokumentācijas vai nosaukumu konvencijas)

3. Konteksts un apjoms

Norobežo jūsu sistēmu no tās (ārējiem) komunikācijas partneriem (blakus sistēmām un lietotājiem). Nosaka ārējās saskarnes. Parādīts no biznesa/domēna perspektīvas (vienmēr) vai tehniskās perspektīvas (pēc izvēles)

Saturs

Sistēmas apjoms un konteksts – kā liecina nosaukums – norobežo jūsu sistēmu (t. i., jūsu apjomu) no visiem tās komunikācijas partneriem (blakus sistēmām un lietotājiem, t. i., jūsu sistēmas konteksts). Tādējādi tiek noteiktas ārējās saskarnes.

Ja nepieciešams, nošķiriet biznesa kontekstu (domēnam specifiskas ievades un izvades) no tehniskā konteksta (kanāli, protokoli, aparatūra).

Motivācija

Domēna saskarnes un tehniskās saskarnes ar komunikācijas partneriem ir viens no jūsu sistēmas kritiskākajiem aspektiem. Pārliecinieties, ka tās pilnībā izprotat.

Forma

• Dažādas konteksta diagrammas

• Komunikācijas partneru un viņu saskarņu saraksti.

3.1 Biznesa konteksts

Saturs

Visu komunikācijas partneru (lietotāju, IT sistēmu, …) specifikācija ar domēnam specifisku ievadu un izvadu vai saskarņu paskaidrojumiem. Pēc izvēles varat pievienot domēnam specifiskus formātus vai komunikācijas protokolus.

Motivācija

Visām ieinteresētajām pusēm jāsaprot, kādi dati tiek apmainīti ar sistēmas vidi.

Forma

Visu veidu diagrammas, kas parāda sistēmu kā melno kasti un nosaka domēna saskarnes ar komunikācijas partneriem.

Alternatīvi (vai papildus) varat izmantot tabulu. Tabulas nosaukums ir jūsu sistēmas nosaukums, trīs kolonnās ir komunikācijas partnera nosaukums, ievades un izvades.

3.2 Tehniskais konteksts

Saturs

Tehniskās saskarnes (kanāli un pārraides vides), kas savieno jūsu sistēmu ar tās vidi. Turklāt domēnam specifisko ievadu/izvadu kartējums uz kanāliem, t. i., paskaidrojums, kurš I/O izmanto kuru kanālu.

Motivācija

Daudzas ieinteresētās puses pieņem arhitektūras lēmumus, pamatojoties uz tehniskajām saskarnēm starp sistēmu un tās kontekstu. Šīs tehniskās saskarnes īpaši nosaka infrastruktūras vai aparatūras projektētāji.

Forma

Piem., UML izvietošanas diagramma, kas apraksta kanālus uz blakus sistēmām, kopā ar kartēšanas tabulu, kas parāda attiecības starp kanāliem un ievadi/izvadi.

4. Risinājuma stratēģija

Fundamentālo lēmumu un risinājumu stratēģiju kopsavilkums, kas veido arhitektūru. Var ietvert tehnoloģiju, augstākā līmeņa dekompozīciju, pieejas galveno kvalitātes mērķu sasniegšanai un būtiskus organizatoriskos lēmumus.

Saturs

Īss fundamentālo lēmumu un risinājumu stratēģiju kopsavilkums un paskaidrojums, kas veido sistēmas arhitektūru. Tie ietver

• tehnoloģiju lēmumus

• lēmumus par sistēmas augstākā līmeņa dekompozīciju, piem., arhitektūras modeļa vai projektēšanas modeļa izmantošanu

• lēmumus par to, kā sasniegt galvenos kvalitātes mērķus

• būtiskus organizatoriskos lēmumus, piem., izstrādes procesa izvēli vai noteiktu uzdevumu deleģēšanu trešajām pusēm.

Motivācija

Šie lēmumi veido jūsu arhitektūras stūrakmeņus. Tie ir pamats daudziem citiem detalizētiem lēmumiem vai īstenošanas noteikumiem.

Forma

Saglabājiet šo galveno lēmumu paskaidrojumu īsu.

Motivējiet, ko esat izlēmis un kāpēc esat tā izlēmis, balstoties uz savu problēmas formulējumu, kvalitātes mērķiem un galvenajiem ierobežojumiem. Atsaucieties uz detaļām nākamajās sadaļās (5. sadaļa strukturālajām detaļām, 8. sadaļa šķērsgriezuma konceptiem).

Varat izmantot risinājumu pieeju sarakstu vai tabulu.

5. Būvbloku skats

Sistēmas statiska dekompozīcija, pirmkoda abstrakcijas, parādītas kā balto kastu (kas satur melnās kastes) hierarhija līdz atbilstošam detalizācijas līmenim.

Saturs

Būvbloku skats parāda sistēmas statisko dekompozīciju būvblokos (moduļos, komponentēs, apakšsistēmās, klasēs, saskarnēs, pakotnēs, bibliotēkās, ietvaros, slāņos, nodalījumos, līmeņos, funkcijās, makro, operācijās, datu struktūrās, …) kā arī to atkarībās (attiecībās, asociācijās, …)

Šis skats ir obligāts katrai arhitektūras dokumentācijai. Pēc analoģijas ar māju tas ir plānojums.

Motivācija

Uzturiet sava pirmkoda pārskatu, padarot tā struktūru saprotamu ar abstrakciju.

Tas ļauj jums sazināties ar savu ieinteresēto pusi abstraktā līmenī, neatklājot īstenošanas detaļas.

Forma

Būvbloku skats ir melno un balto kastu hierarhiska kolekcija (skatiet attēlu tālāk) un to apraksti.

5.1 Baltā kaste: visa sistēma

Šeit jūs aprakstāt visas sistēmas dekompozīciju, izmantojot šādu balto kastu veidni. Tā satur

• pārskata diagrammu

• dekompozīcijas motivāciju

• ietverto būvbloku melno kastu aprakstus. Šiem mēs piedāvājam alternatīvas:

  • izmantojiet vienu tabulu īsam un pragmatiskam visu ietverto būvbloku un to saskarņu pārskatam

  • izmantojiet būvbloku melno kastu aprakstu sarakstu saskaņā ar melnās kastes veidni (skatiet tālāk). Atkarībā no jūsu rīka izvēles šis saraksts var būt apakšnodaļas (teksta failos), apakšlapas (vikijā) vai ligzdoti elementi (modelēšanas rīkā).

  • (pēc izvēles:) svarīgas saskarnes, kas nav paskaidrotas būvbloka melnās kastes veidnēs, bet ir ļoti svarīgas baltās kastes izpratnei.

Tā kā ir tik daudz veidu, kā norādīt saskarnes, kāpēc nesniegt tām konkrētu veidni.

Labākajā gadījumā jūs iztiksiet ar piemēriem vai vienkāršiem parakstiem.

5.2 2. līmenis

Šeit varat norādīt (dažu) 1. līmeņa būvbloku iekšējo struktūru kā baltās kastes.

Jums jāizlemj, kuri jūsu sistēmas būvbloki ir pietiekami svarīgi, lai attaisnotu tik detalizētu aprakstu. Lūdzu, dodiet priekšroku būtiskumam, nevis pilnīgumam. Norādiet svarīgus, pārsteidzošus, riskantus, sarežģītus vai mainīgus būvblokus. Izlaidiet parastās, vienkāršās, garlaicīgās vai standartizētās sistēmas daļas

5.2.1 Baltā kaste būvblokam 1

Norāda būvbloka 1 iekšējo struktūru.

Izmantojiet balto kastu veidni (skatiet iepriekš).

6. Izpildlaika skats

Būvbloku uzvedība kā scenāriji, aptverot svarīgus lietošanas gadījumus vai funkcijas, mijiedarbības kritiskajās ārējās saskarnēs, ekspluatāciju un administrēšanu, kā arī kļūdu un izņēmumu uzvedību.

Saturs

Izpildlaika skats apraksta sistēmas būvbloku konkrētu uzvedību un mijiedarbību scenāriju veidā no šādām jomām:

• svarīgi lietošanas gadījumi vai funkcijas: kā būvbloki tos izpilda?

• mijiedarbības kritiskajās ārējās saskarnēs: kā būvbloki sadarbojas ar lietotājiem un blakus sistēmām?

• ekspluatācija un administrēšana: palaišana, startēšana, apturēšana

• kļūdu un izņēmumu scenāriji

Piezīme: galvenais kritērijs iespējamo scenāriju (secību, darbplūsmu) izvēlei ir to arhitektūras būtiskums. Nav svarīgi aprakstīt lielu skaitu scenāriju. Labāk dokumentējiet reprezentatīvu izlasi.

Motivācija

Jums jāsaprot, kā jūsu sistēmas būvbloki (to eksemplāri) veic savu darbu un sazinās izpildlaikā. Scenārijus jūs galvenokārt fiksēsiet savā dokumentācijā, lai paziņotu savu arhitektūru ieinteresētajām pusēm, kuras ir mazāk gatavas vai spējīgas lasīt un saprast statiskos modeļus (būvbloku skats, izvietošanas skats).

Forma

Ir daudz notāciju scenāriju aprakstīšanai, piem.

• numurēts soļu saraksts (dabiskā valodā)

• aktivitāšu diagrammas vai blokshēmas

• secību diagrammas

• BPMN vai EPC (event process chains, notikumu procesu ķēdes)

• stāvokļu automāti

• utt.

6.n Izpildlaika scenārijs n (1, 2, 3 utt.)

Ievietojiet izpildlaika diagrammu vai scenārija teksta aprakstu.

Ievietojiet šajā diagrammā attēloto būvbloku eksemplāru mijiedarbības ievērojamo aspektu aprakstu.

7. Izvietošanas skats

Tehniskā infrastruktūra ar vidēm, datoriem, procesoriem, topoloģijām. (Programmatūras) būvbloku kartēšana uz infrastruktūras elementiem.

Saturs

Izvietošanas skats apraksta:

• tehnisko infrastruktūru, kas izmantota jūsu sistēmas izpildei, ar infrastruktūras elementiem, piemēram, ģeogrāfiskajām atrašanās vietām, vidēm, datoriem, procesoriem, kanāliem un tīkla topoloģijām, kā arī citiem infrastruktūras elementiem, un

• (programmatūras) būvbloku kartēšanu uz šiem infrastruktūras elementiem.

Sistēmas bieži tiek izpildītas dažādās vidēs, piem., izstrādes vide, testa vide, ražošanas vide. Šādos gadījumos jums jādokumentē visas attiecīgās vides.

Īpaši dokumentējiet izvietošanas skatu, kad jūsu programmatūra tiek izpildīta kā sadalīta sistēma ar vairāk nekā vienu datoru, procesoru, serveri vai konteineru vai kad projektējat un veidojat savus aparatūras procesorus un mikroshēmas.

No programmatūras viedokļa pietiek fiksēt tos infrastruktūras elementus, kas nepieciešami jūsu būvbloku izvietošanas parādīšanai. Aparatūras arhitekti var iet tālāk un aprakstīt infrastruktūru līdz jebkuram detalizācijas līmenim, ko viņiem nepieciešams fiksēt.

Motivācija

Programmatūra nedarbojas bez aparatūras. Šī pamatā esošā infrastruktūra var un ietekmēs jūsu sistēmu un/vai dažus šķērsgriezuma konceptus. Tāpēc jums jāzina infrastruktūra.

Forma

Iespējams, augstākā līmeņa izvietošanas diagramma jau ir iekļauta 3.2. sadaļā kā tehniskais konteksts ar jūsu pašu infrastruktūru kā VIENU melno kasti. Šajā sadaļā jūs tuvināsiet šo melno kasti, izmantojot papildu izvietošanas diagrammas.

• UML piedāvā izvietošanas diagrammas šī skata izteikšanai. Izmantojiet to, iespējams, ar ligzdotām diagrammām, kad jūsu infrastruktūra ir sarežģītāka.

• Ja jūsu (aparatūras) ieinteresētās puses dod priekšroku citiem diagrammu veidiem, nevis UML izvietošanas diagrammai, ļaujiet viņiem izmantot jebkuru veidu, kas spēj parādīt infrastruktūras mezglus un kanālus.

7.1 Infrastruktūra, 1. līmenis

Aprakstiet (parasti diagrammu, tabulu un teksta kombinācijā):

• jūsu sistēmas sadalījumu uz vairākām atrašanās vietām, vidēm, datoriem, procesoriem, … kā arī fiziskos savienojumus starp tiem

• svarīgu pamatojumu vai motivāciju šai izvietošanas struktūrai

• infrastruktūras kvalitātes un/vai veiktspējas iezīmes

• programmatūras artefaktu (būvbloku) kartēšanu uz infrastruktūras elementiem

Vairākām vidēm vai alternatīvām izvietošanām, lūdzu, kopējiet šo arc42 sadaļu visām attiecīgajām vidēm. **

7.2 Infrastruktūra, 2. līmenis

Šeit varat iekļaut (dažu) infrastruktūras elementu iekšējo struktūru no infrastruktūras 1. līmeņa.

Lūdzu, kopējiet struktūru no 1. līmeņa katram izvēlētajam elementam.

8. Šķērsgriezuma koncepti

Vispārīgi, principiāli noteikumi un risinājumu pieejas, kas attiecas uz vairākām sistēmas daļām (→ šķērsgriezums). Koncepti bieži ir saistīti ar vairākiem būvblokiem. Iekļaujiet dažādas tēmas, piemēram, domēna modeļus, arhitektūras modeļus un stilus, noteikumus konkrētas tehnoloģijas izmantošanai un īstenošanas noteikumus.

Saturs

Šī sadaļa apraksta šķērsgriezuma konceptus (prakses, modeļus, noteikumus vai risinājumu idejas). Šādi koncepti bieži ir saistīti ar vairākiem būvblokiem. Tie var ietvert daudz dažādu tēmu.

Motivācija

Koncepti veido arhitektūras konceptuālās integritātes (konsekvences, viendabīguma) pamatu. Tādējādi tie ir svarīgs ieguldījums jūsu sistēmas iekšējo kvalitāšu sasniegšanā.

Šī ir vieta veidnē, ko mēs nodrošinājām šādu konceptu kohezīvai specifikācijai.

Daudzi no šiem konceptiem attiecas uz vairākiem jūsu būvblokiem vai tos ietekmē.

Forma

Forma var būt dažāda:

• koncepcijas dokumenti ar jebkāda veida struktūru

• īstenojumu piemēri, īpaši tehniskiem konceptiem

• šķērsgriezuma modeļu izvilkumi vai scenāriji, izmantojot arhitektūras skatu notācijas

Šīs sadaļas struktūra

Izvēlieties tikai visvairāk nepieciešamās tēmas savai sistēmai un katrai piešķiriet otrā līmeņa virsrakstu šajā sadaļā (piem., 8.1, 8.2 utt.).

• NEMĒĢINIET aptvert visas iepriekšminētās diagrammas tēmas.

Fons

Dažas sistēmu tēmas bieži skar vairākus būvblokus, aparatūras elementus vai izstrādes procesus. Šādas šķērsgriezuma tēmas var būt vieglāk paziņot vai dokumentēt centrālā vietā, nevis atkārtot tās skarto būvbloku, aparatūras elementu vai izstrādes procesu aprakstā.

Daži koncepti var attiekties uz visiem sistēmas elementiem, citi var būt būtiski tikai dažiem.

9. Arhitektūras lēmumi

Svarīgi, dārgi, kritiski, liela mēroga vai riskanti arhitektūras lēmumi ar pamatojumiem.

Saturs

Svarīgi, dārgi, liela mēroga vai riskanti arhitektūras lēmumi ar pamatojumiem. Ar „lēmumiem” mēs domājam vienas alternatīvas izvēli, balstoties uz dotajiem kritērijiem.

Lūdzu, izmantojiet savu spriedumu, lai izlemtu, vai arhitektūras lēmums jādokumentē šeit, šajā centrālajā sadaļā, vai arī labāk to dokumentēt lokāli (piem., viena būvbloka baltās kastes veidnē). Izvairieties no liekiem tekstiem. Atsaucieties uz 4. sadaļu, kur jūs jau fiksējāt savas arhitektūras svarīgākos lēmumus.

Motivācija

Jūsu sistēmas ieinteresētajām pusēm jāspēj saprast un izsekot jūsu lēmumiem.

Forma

• ADR (arhitektūras lēmuma ieraksts) katram svarīgam lēmumam

• saraksts vai tabula, sakārtota pēc svarīguma un sekām, vai

• detalizētāk atsevišķu sadaļu veidā katram lēmumam

Fons (par ADR)

Mazākus dokumentācijas gabalus ir vieglāk lasīt, veidot un uzturēt. Runājot par arhitektūras lēmumiem, izstrādes komandas bieži:

• zina par lēmumu, jo tas ir redzams, piem., pirmkodā, bet

• nezina motivāciju aiz šī lēmuma (skatiet Nygard 2011)

Tāpēc jums jādokumentē daži svarīgi lēmumi kopā ar to motivāciju un argumentāciju

Mūsu priekšlikums attiecībā uz lēmumiem

Uzturiet arhitektūriski nozīmīgu lēmumu kolekciju, tos lēmumus, kas ietekmē struktūru, kvalitātes raksturlielumus, svarīgas (īpaši ārējās) atkarības un saskarnes vai būvniecības paņēmienus (pateicība Michael Nygard par šo priekšlikumu).

10. Kvalitātes prasības

Kvalitātes prasības kā scenāriji ar kvalitātes koku augsta līmeņa pārskatam. Svarīgākie kvalitātes mērķi jau bija jāapraksta 1.2. sadaļā (kvalitātes mērķi).

Saturs

Šī sadaļa satur visas attiecīgās kvalitātes prasības.

Svarīgākās no šīm prasībām jau ir aprakstītas 1.2. sadaļā (kvalitātes mērķi), tāpēc šeit tām jāatsaucas tikai uz tām. Šajā 10. sadaļā jums jāfiksē arī mazāk svarīgas kvalitātes prasības, kas neradīs lielus riskus, ja tās netiks pilnībā sasniegtas (bet varētu būt vēlamas).

Motivācija

Tā kā kvalitātes prasībām būs liela ietekme uz arhitektūras lēmumiem, jums jāzina, kādas kvalitātes jūsu ieinteresētajām pusēm ir patiešām svarīgas, konkrētā un izmērāmā veidā.

Papildu informācija

Skatiet plašo Q42 kvalitātes modeli vietnē https://quality.arc42.org.

10.1 Kvalitātes prasību pārskats

Saturs

Kvalitātes prasību pārskats vai kopsavilkums.

Motivācija

Bieži sastopam desmitiem (vai pat simtiem) detalizētu kvalitātes prasību. Šajā pārskata sadaļā jums jācenšas apkopot, piem., aprakstot kategorijas vai tēmas (kā ieteikts ISO 25010:2023 vai Q42

Ja šie kopsavilkuma apraksti jau ir precīzi, pietiekami konkrēti un izmērāmi, varat izlaist 10.2. sadaļu.

Forma

Izmantojiet vienkāršu tabulu, kurā katra rinda satur kategoriju vai tēmu un īsu kvalitātes prasības aprakstu. Alternatīvi varat izmantot domu karti šo kvalitātes prasību strukturēšanai.

Literatūrā ir aprakstīta arī kvalitātes atribūtu koka ideja, kas par sakni izvirza vispārīgo terminu „kvalitāte” un izmanto koka veida termina „kvalitāte” precizēšanu. [Bass+21] šim nolūkam ieviesa terminu „Quality Attribute Utility Tree”.

10.2 Kvalitātes scenāriji

Saturs

Kvalitātes scenāriji konkretizē kvalitātes prasības un ļauj izlemt, vai tās ir izpildītas (pieņemšanas kritēriju nozīmē). Pārliecinieties, ka jūsu scenāriji ir konkrēti un izmērāmi.

Divi scenāriju veidi ir īpaši noderīgi:

• Lietošanas scenāriji (saukti arī par lietojumprogrammu scenārijiem vai lietošanas gadījumu scenārijiem) apraksta sistēmas izpildlaika reakciju uz noteiktu stimulu. Tas ietver arī scenārijus, kas apraksta sistēmas efektivitāti vai veiktspēju. Piemērs: sistēma reaģē uz lietotāja pieprasījumu vienas sekundes laikā.

• Izmaiņu scenāriji apraksta vēlamo sistēmas vai tās tiešās vides modifikācijas vai paplašinājuma ietekmi. Piemērs: tiek īstenota papildu funkcionalitāte vai mainās prasības kvalitātes atribūtam, un tiek mērītas izmaiņu pūles vai ilgums.

Forma

Tipiska informācija detalizētiem scenārijiem ietver šādus elementus:

Īsā formā (priekšroka Q42 modelī):

• Konteksts/fons: kāda veida sistēma vai komponente, kāda ir vide vai situācija?

• Avots/stimuls: kas vai kas ierosina vai izraisa uzvedību, reakciju vai darbību.

• Metrika/pieņemšanas kritēriji: atbilde, kas ietver mēru vai metriku

Scenāriju garā forma (priekšroka SEI un [Bass+21]) ir detalizētāka un ietver šādu informāciju:

• Scenārija ID: unikāls scenārija identifikators.

• Scenārija nosaukums: īss, aprakstošs scenārija nosaukums.

• Avots: entītija (lietotājs, sistēma vai notikums), kas ierosina scenāriju.

• Stimuls: izraisošais notikums vai nosacījums, ko sistēmai jāapstrādā.

• Vide: darbības konteksts vai nosacījums, kurā sistēma piedzīvo stimulu.

• Artefakts: būvbloki vai citi sistēmas elementi, ko stimuls ietekmē.

• Atbilde: iznākums vai uzvedība, ko sistēma uzrāda reaģējot uz stimulu.

• Atbildes mērs: kritēriji vai metrika, pēc kuras tiek vērtēta sistēmas atbilde.

Skatiet arī

Kopš 2023. gada janvāra arc42 nodrošina pragmatisku kvalitātes modeli, kas iesaka marķēt kvalitātes prasības ar mirkļbirkām vai etiķetēm, piemēram, #flexible, #efficient, #usable, #operable, #testable, #secure, #safe, #reliable.

11. Riski un tehniskais parāds

Zināmi tehniskie riski vai tehniskais parāds. Kādas potenciālas problēmas pastāv sistēmā vai ap to? Par ko izstrādes komanda jūtas nelaimīga?

Saturs

Apzināto tehnisko risku vai tehnisko parādu saraksts, sakārtots pēc prioritātes

Motivācija

„Risku pārvaldība ir projektu vadība pieaugušajiem” (Tim Lister, Atlantic Systems Guild.)

Tam jābūt jūsu devīzei sistemātiskai risku un tehnisko parādu atklāšanai un novērtēšanai arhitektūrā, ko pārvaldības ieinteresētajām pusēm (piem., projektu vadītājiem, produktu īpašniekiem) vajadzēs kā daļu no vispārējās risku analīzes un pasākumu plānošanas.

Forma

Risku un/vai tehnisko parādu saraksts, iespējams, ietverot ieteiktos pasākumus risku samazināšanai, mīkstināšanai vai novēršanai vai tehnisko parādu samazināšanai.