Tarkvara arenduse elutsüklis on olemas erinevaid tegevusi, nende tegevuste tulemuste tulemusel tekib hulk artifakte
mis dokumenteerib nendes tegevustest kas siis tehtavaid tegevusi või tehtud tegevusi ja nende tegijaid.
Dokumentatsioon tekib peaaegu igas tarkvaraarenduse elutsükli etapis ja põhimõtteliselt igas tarkvara-
arendus elutsükli tüübis. Need artefaktid kokku moodustavadki Tarkvara dokumentatsiooni
on olemas erinevaid tüüpe dokumentatsioone, aga tüüpiliselt esinevad vähemalt järgnevad:
Kujutab endast erinevates arendustsüklites oleva Analüüsietapi väljundit, kus pannakse paika
arendatava süsteemi erinevad nõuded koostöös lõppkasutajatega ning kliendiga. Arvestatakse mõlemi vajadusi
ning selgitatakse välja erinevad tõkendid.
Dokumendi eesmärk on anda arendajaile Arhitektuurse disaini dokumeni loomise jaoks täpne sisend selle kohta
mida üldse arendama peab, selle abil kirjeldatakse juba süsteemselt arendajaile vajalik info.
Kirjaldab ära dokumendi eesmärgi (Milleks ja kellele), Projekti ulatuse (Mida arendatakse, mida mitte),
Terminite sõnastik, Viiteid teistele Dokumentidele.
Kirjeldab arendustööd ennast mida dokumendi abil arendama hakatakse/arendatakse
Kirjeldatakse ära, mida tahab kasutaja teha, mida klient sellest saab, mis on nende erinevad vajadused
kas neil on eelnevaid kogemusi sarnaste toodetega samast tootekategooriast. Näiteks rollipõhine tabel sotsiaalmeedia
äpi jaoks:
| Roll | Tegevused |
| Külaline |
|
| Registreerida kasutaja | Kõik mis külaline |
| Admin | Kõik mis registreerunud kasutaja |
| Süsteemi administratoor | Hoolitseb veebiäpi toimimise eest, haldab andmebaase, teeb korrastustöid vajadusel konfigureerib, ja jälgib muud statistikat et tagada kliendi ja kasutajate rahulolu. |
Kirjeldatakse ära erinevad piirangud või tõkestavad aspektid, mis võivad arendusel ette tulla, kasutajatel endal olla,
Keskkonnast kus toode toimima peab, arendusvahenditest tulnevad piirangud ja seaduslikud piirangud
Toote loomist võib tingida mingisugune eelnev tingimus - viiakse sisse riigisüsteemis mingisugune muudatus, digitaalne
vahend selle jaoks puudub, ning leitakse et on vaja arendada vastav töörist et tagada riigisüsteemi muudatuse ülalhoid.
Kirjeldab ära keskkonna riistvaraliselt millel arendatud tarkvara toode toimima peab. See võib endas sisaldada erinevaid:
Kirjeldab ära erinevaid funktsionaalsed nõued kasutajalugudena ning muud tehnilised
nõuded arenduskekkonnas. Sisaldab ka endas erinevaid URL skeeme.
Dokumendi eesmärk on anda arendajaile Arhitektuurse disaini loomise jaoks sisend selle kohta
mida üldse arendama peab, selle abil kirjeldatakse juba süsteemselt arendajaile vajalik info.
Kujutab endast arendatava toote või steemi sisemist ülesehitus.Kirjeldab ära ka selles süüsteemis esinevaid erinevaid
mooduleid, komponente ning muid sõltuvusi. Pannakse kirja ka kuidas need komponendid/moodulid omavahel suhtlevad ning süsteem
ise tervikuna suhtleb süsteemiväliste elementidega. Ära kirjeldatakseka Arhitektuur keskonnale kus ka kuidas valminud toode.
Dokumendi eesmärk on tekitada arendajaile struktuur mida nad arendama hakkavad, see struktuur tuletatakse tarkvara
nõuete dokumendist.
Kirjeldatakse ära dokumendi eesmärk viidatakse muudele dokumentidele ning omab sisukorda.
Kirjutatakse välja milliseid arendusvahendeid on otsutatud arendustööks rakendada. Kirjeldatakse ära ka nende seadistus
ja põhjendatakse ära miks justneed arendusvahendid valitud on. Kirjeldatakse samamoodi ära ka peale arendusvahendid
arenduskeskkond
On kokkuleppelised konventsioonid mida kogu arendusmeeskond jälgima peab, nendeks on:
Kirjeldatakse ära teised, välised süsteemid ja kuidas nendega tarkvaratooe suhtlema peaks.
Sealhulgas ka mis kujul ja mis viisil need välised süsteemide infot vastu võtavad, ja tagasi annavad
Siin tuuakse välja, miks miski arhitektuuriotsus langetati, ehk miks just nii mitte naa. Pakutakse välja
ika olemasolevatele otsustele alternatiive juhuks kui esialgne plaan ei sobi või on tõkestatud.
Tuuakse välja ka nõuded mille põhjal erinevad otsused langetati, ehk mida see otsus lahendama peaks.
Pannakse kirja tarkvaratootele kliendi poolt esitatud Jõudlusnõuded, näiteks: kui palju kasutajaid suudab
sotsiaalmeedia platvorm karraga hallata. Testimise käigus üritataksegi tetida arendusjärgus olevat toodet
simuleeritud koormusega. Kõik muud jõudlusnõuded peaksid olema ka testitavad sellisel viisil.
Kuidas programm väljendab oma funktsionaalsust lõppkasutajale, ning millisel viisil esitakse programmis
tekkinud vigu kasutajsle. Ehk teisisõnu on siin ka kasutajaliidese disain. Kasutajaliidese diasin võib olla
ka eraldi oma dokument
Kirjeldab ära kui palju vajab arendatav toode erinevaid süsteemi raudvara ressursse nagu:
Kui klient otsustab, et nüüd on tarkvara dokumendis nõue vaja ringi teha, siis tuleb vastavad muudatused sisse
viia ka arhitektuurse disaini dokumenti. Sellel eesmärgil on mõlemas dokumendis nõuete ja arhitektuurielementide vahel ristviited
Kui on vaja näiteks sisselogimisfunktsiooni muuta, et nüüd klient tahab ka saada telefoninumbrit 2FA läbiviimiseks, siis on seal
nõude juures ka ristvaiide vastavalt programmi moodulile, mis haldab kasutaja sisselogimist. Sellele kasutajaloole lisatakse juurde
telefoninumbri küsimine
On dokument mis aitab lõppkasutajal kasutada ning navigeerida valminud tootes. Ta kirjeldab ära kidas erinevaid tegevusi sooritada,
milleks seda programmi kasutada saab, kuidas lahendada Korduma Kippuvaid Küsimusi ja muid võimalikke kasutaja tegevusi tagajärjel
tekkinud veaolekuid. Kasutajajuhend on kirjutatud selle põhjal mis on kasutajale näha ning saadaval, aga mitte käsitledes programmi.
siseseid detaile. Näiteks Monteerimisprogramm kirjeldab kasutajale kuidas muuta tööriist nähtavaks läbi "View > Window" menüü aga mitte
seda millest muutujat muuta vaja et kuvada see aken koodis.
haldusjuhend on dokument mille koostavad arendajad oma arendatava toote kohta potensiaalselt arendusega mittetegelevale isikule, aga
kes on kliendi palgal valminud süsteemi hoidamas. Dokument käsitleb: