Tarkvara loomine ei koosne pelgalt arendusest. Enne tarkvara kallal töötamist peavad arendajad täpselt teadma, mida luua. Seetõttu algab arendus tavaliselt hunniku dokumentide koostamisega, mis kirjeldavad üksikasjalikult tulevast projekti. Dokumendid sisaldavad arvukalt uuringuid, analüüse ja spetsifikatsioone, millest üks on tarkvaranõuete spetsifikatsioon (SRS).
See artikkel on pühendatud SRS-ile, selle tähtsusele teie projekti jaoks ja sammudele kvaliteetse tarkvara spetsifikatsiooni loomiseks. Sukeldume teemasse, määratledes SRS-i.
tibu-fil-a pühapäevane avamine
Mis on tarkvaranõuete dokumentatsioon ja miks seda vaja on?
Tarkvaranõuete dokumentatsioon on dokument, mis kirjeldab tarkvara funktsionaalseid ja mittefunktsionaalseid spetsifikatsioone, selle väljatöötamise viisi ja kasutusjuhtumeid – viise, kuidas kasutajad tarkvaraga suhtlevad, kui see on valmis. SRS aruanne koostatakse tavaliselt ajal projekti avastamise etapp . Ettevõtete omanikud saavad kõik spetsifikatsioonid ise struktureerida või usaldada selle ülesande professionaalidele, kellel on tarkvaraarenduse ja spetsifikatsioonide määratlemise kogemus.
Mõned ettevõtte omanikud võivad soovida avastamisetapi, sealhulgas dokumentatsiooni ettevalmistamise, vahele jätta. Selle etapi tähelepanuta jätmine võib aga viia projekti ebaõnnestumiseni. Vastavalt PMI uuringule Pulse of the Profession, 35% projektidest ebaõnnestuvad ebatäpsete nõuete tõttu. Kas mõni ettevõtte omanik keelduks SRS-i kogumisest, kui ta teaks seda statistikat varem? Me kahtleme selles. Seega on teie meeskonnal kõik tarkvaranõuded ühes kohas kasulikud järgmised:
- Arendajad otsustada, millist tehnoloogiat nad vajavad tarkvara taga- ja esiosa loomiseks
- Disainerid saada aimu, kuidas need võivad tarkvaraliidese funktsioone kajastada
- Testijad saada aru testjuhtumitest, mida nad peavad ette valmistama, ja tagada, et tarkvara vastab ärinõuetele
- Ettevõtete omanikud saavad oma toote jaoks vajalike funktsioonide loendi ja saavad teha investeeringute kohta teadlikke otsuseid
Kokkuvõttes on tarkvaranõuete dokumentatsioon juhis, mis tagab, et kõigil tarkvaraarenduse protsessis osalejatel on protsessist selge nägemus ja samad ootused. Seega võimaldab SRS-i aruanne vältida arusaamatusi ja valesti suhtlemist meeskonnas.
Kui otsustate spetsifikatsioonide loomisega ise tegeleda, saate mõne tarkvara spetsifikatsiooni kasutamisest kasu näiteid leiate Internetist. Kui soovite selle ülesande delegeerida professionaalidele, siis veenduge, et leiate usaldusväärse ettevõtte, millel on tugev ärianalüütikutest, projektijuhtidest, arendajatest ja testijatest koosnev meeskond, kes suudab pakkuda kvaliteetseid spetsifikatsioone.
Asjad, mida peaksite teadma enne SRS-i aruande koostamist
Tarkvaranõuete õigeks tuvastamiseks on oluline teada, millist väärtust peaks tarkvara ettevõttele ja tarkvarakasutajatele tooma. Samuti on oluline teada kõrge kvaliteedi omadusi tarkvara spetsifikatsioonid .
Äri- ja kasutajanõuded
Äri- ja kasutajanõuded peegeldavad loodava tarkvara olemust. Ärinõuded kirjeldavad eesmärke, mida ettevõtete omanikud soovivad konkreetse tarkvaraga saavutada. Eesmärgid võivad olla erinevad: protsesside automatiseerimine, töötajate arvu ja riistvara minimeerimine jne. Kasutajate nõuded varieeruvad olenevalt tarkvara tüübist. Kuid enamikul juhtudel soovivad kasutajad rakendusi, mis töötavad kiiresti ja on intuitiivselt kasutatavad. Üksikasjalike spetsifikatsioonide koostamisel on oluline neid nõudeid arvesse võtta.
Kvaliteetse SRS-i omadused
Selleks, et tarkvaranõuete spetsifikatsiooni aruanne oleks projekti ja meeskonna jaoks maksimaalselt kasulik, on oluline koostada see:
- Täielik et iga projektiga seotud meeskonnaliige leiaks aruandest vajaliku teabe. Arendajad peaksid leidma sealt tehnilised nõuded, samas kui UI/UX disaineritel peaksid olema üldised disainijuhised. Testijad peaksid mõistma, kuidas tarkvara peab selle nõuetekohaseks testimiseks töötama. Tooteomanikud vajavad seda dokumenti, et neil oleks oma projektist selge nägemus.
- Mõõdetav et saaksite võrrelda valmistoodet nende tehniliste andmetega, mille koostasite kohe alguses. Pole mõtet öelda, et teie tarkvara peaks vastama kõigile nõuetele.
- Paindlik. SRS-i aruannet ei saa kirjutada üks kord ja seda ei saa muuta enne projekti lõppu. Vastupidi, nõuded võivad projekti kallal töötamise käigus muutuda. Seega peaks teie aruande vorming olema mugav kohandada, kui seda vajate.
- Selge ja täpne. Oluline on vältida üleliigseid fraase ja mitmetähenduslikkust. Iga protsessi tuleks kirjeldada lihtsate sõnadega koos tarkvara koostamiseks vajalike tehnoloogiate loeteluga.
Nüüd, kui teate, millised asjad on kvaliteetse tarkvaranõuete dokumentatsiooni jaoks üliolulised, on aeg näha, millest see koosneb.
kas loomaarstid peavad koerahammustustest teatama
Tarkvaranõuete spetsifikatsiooni komponendid
SRS-aruanne peaks olema järjepidev, seega on oluline järgida konkreetset struktuuri, mis aitab selle lugejatel teavet hõlpsasti tajuda. Allpool kirjeldame peamisi jaotisi, mida korralik SRS peaks sisaldama.
Sissejuhatus
Sissejuhatuses tuleks lühidalt selgitada, millist tarkvara hakatakse ehitama, et iga meeskonnaliige saaks projektist, mille kallal nad töötavad, üldise ülevaate.
Mõeldud publik
Selles jaotises mainivad aruande autorid kõiki meeskonnaliikmeid, kellel on dokumendile juurdepääs. Reeglina on need tarkvarainsenerid, testijad, disainerid ja projektijuhid. Sellesse loendisse peaks kuuluma ka tooteomanik, kes tellib tarkvaraarendust ja tal peab olema võimalus dokumenti igal ajal vaadata, et veenduda, et kõik läheb plaanipäraselt.
Üldine kirjeldus
Selles jaotises kirjeldatakse funktsioone, mida tarkvara peab täitma. Samuti leiate kasutajarollid ja kasutusjuhtumid. Selles osas on võimalik kirjeldada eeldusi ja sõltuvusi, et ennustada võimalikke väljakutseid ja viise nende ületamiseks. Sellesse jaotisse võib lisada ka disainipiirangud.
Nõuded välisele liidesele
See SRS-i aruande osa kirjeldab, kuidas kasutajad, riistvara ja tarkvara peaksid omavahel suhtlema. Sektsiooni saab jagada neljaks osaks:
- The kasutajaliidesed osas kirjeldatakse, kuidas kasutajad tarkvaraga suhtlevad.
- The riistvaraliidesed osa käsitleb riist- ja tarkvara koostoimet.
- The tarkvara liidesed osas selgitatakse, kuidas tarkvara korreleerub selle komponentidega, sealhulgas operatsioonisüsteemide, teekide, andmebaaside jne.
- The suhtlusliidesed osas kirjeldatakse tarkvara sees kasutatavaid suhtluskanaleid: e-kirjad, brauserid, serveriprotokollid jne.
Funktsionaalsed nõuded
See jaotis käsitleb tarkvara toimimist. See kirjeldab kõiki funktsioone, et kõik meeskonnaliikmed mõistaksid töö ulatust. Funktsionaalsed nõuded peaksid koosnema süsteemi töövoo kirjeldusest, kui/siis käitumisest, andmetöötlusloogikast ning andmesisenditest ja -väljunditest.
Mida üksikasjalikum on funktsionaalsuse kirjeldus, seda vähem on võimalusi tulevikus ümber töötada. Funktsionaalsete nõuete üksikasjalik kirjeldus võimaldab hinnata ka arenduse aega ja maksumust.
Mittefunktsionaalsed nõuded
See jaotis kirjeldab soovitud tarkvara jõudlust, mis on väljendatud selle omadustena. Põhilised mittefunktsionaalsed nõuded on reeglina turvalisus, kasutatavus, testitavus, skaleeritavus jne.
kuidas sigarette kohale toimetada
Lisad
Selles jaotises peaksite koguma teavet, mis aitab peamistest spetsifikatsioonidest paremini aru saada. See jaotis on koht lühendite, terminite ja nende määratluste, diagrammide, skeemide jms jaoks.
Ülaltoodud ülevaadet saab muuta olenevalt projektist, ehitatava rakenduse tüübist, rakenduse keerukusest jne. Konspekti saate muuta viisil, mis on teie meeskonnale mugavam, kuid peaksite sisaldama kõiki peamisi jaotisi, et saada täielikku teavet projekti kohta.
Tööriistad SRS-aruannete koostamiseks
Olenemata sellest, millise tööriista valite oma projekti jaoks tarkvaranõuete spetsifikatsioonide loomiseks, peaks dokumenti olema mugav kasutada ja jagada kõigile projektiga seotud liikmetele. Allpool on loetletud mitu populaarset viisi ja tööriista SRS-i aruande koostamiseks.
Google Docs
Paljud ärianalüütikud valivad Google'i teenused, nagu Google'i dokumendid või Google'i arvutustabelid, kuna neid on lihtne kasutada ja muuta. Lisaks saavad aruannete autorid katsetada dokumendivaadetega, et muuta need teistele loetavamaks. Kuna tegemist on pilveteenustega, on Google'i dokumente ja arvutustabeleid mugavam jagada, kui võrrelda Microsoft Docsi või muude võrguühenduseta tekstiredaktoritega.
Pärl
Pärl on nõuete haldamise tööriist, mis teeb kõigi spetsifikatsioonidega seotud ülesannete käsitlemise võimalikult lihtsaks. Kõik, mida pead tegema, on määratleda kasutusjuhtumid, kasutajarollid, tingimused ja vood. Kui olete selle teinud, saate luua aruande ühe klõpsuga. Teine hea asi Pearli tööriista juures on see, et see võimaldab mugavaks meeskonnatööks teateid ja kommentaare.
Helix RM
Helix RM on veel üks tööriist, mis muudab spetsifikatsioonidega töötamise lihtsamaks. Selle laiaulatuslik funktsionaalsus võimaldab meeskondadel maksimaalselt mugavalt töötada spetsifikatsioonidega. Eelkõige pakub Helix RM oma kasutajatele graafilisi tööriistu, nõuete jälgitavust, reaalajas koostööfunktsioone ja palju muud. Tööriista suureks eeliseks on selle integreerimine erinevate tarkvaradega, nagu Slack, Jira, GitHub jne.
Järeldus
Korralikult koostatud tarkvaranõuete dokumentatsioon tagab kolmandiku teie projekti edust, seega on oluline tarkvara arendamisel sellele osale tähelepanu pöörata. SRS-i aruande kallal on võimalik töötada iseseisvalt või koostööks valitud ettevõtte ärianalüütikute ja tarkvarainseneride meeskonnaga.
Olenemata sellest, kes kirjutab tehnilisi andmeid ja milliseid programme nad selleks kasutavad, peaksite veenduma, et teie tarkvaranõuete dokumentatsioon on selge, järjepidev, mõõdetav, paindlik ja täielik.
