Tarkvaranõuete spetsifikatsioon (SRS): näpunäited ja mall
Suhtlus on tarkvara arendamise edu võti. Ühe järgi õppima see uuris, miks tarkvaraarendusettevõtted näevad vaeva klientide ootustele vastavate tarkvaralahenduste pakkumisega, halb kommunikatsioon ja ebaselged nõuded on peamised põhjused, miks tarkvaraprojektid ebaõnnestuvad.
Selged ja hästi edastatud nõuded aitavad arendustiimidel luua õige toote, mis on eduka tootearenduse alus. Kuidas sellised nõuded tegelikult välja näevad ja kuidas neist tuleks teada anda? Vastus on lihtne: tarkvaranõuete spetsifikatsiooniga (SRS).
Mis on SRS?
SRS on dokument, mille eesmärk on anda arendatava tarkvaratoote põhjalik kirjeldus, sealhulgas selle eesmärk, peamised toetatavad äriprotsessid, funktsioonid, peamised jõudlusparameetrid ja käitumine. Sellisena toimib see sisuliselt kaardina, mis suunab arendusprotsessi ja hoiab kõiki õigel teel.
SRS sõlmitakse tavaliselt nõuete väljatöötamise etapi lõpus, mis on tarkvaraarenduse varaseim etapp. See sisaldab nii funktsionaalseid kui ka mittefunktsionaalseid nõudeid. Funktsionaalsed nõuded kirjeldavad tarkvarasüsteemi ja selle komponentide funktsiooni (näiteks raamatute eelbroneerimine kolledži raamatukogusüsteemi kirjeldamisel), mittefunktsionaalsed nõuded aga tarkvara süsteemi ja selle komponentide (näiteks turvalisus või teenus) toimivusnäitajaid. kättesaadavus).
IEEE (elektri- ja elektroonikainseneride instituut) spetsifikatsioon 830-1998 kirjeldab SRS-i määratlemise meetodeid ja soovitatavaid lähenemisviise, aidates tarkvaraklientidel täpselt kirjeldada, mida nad soovivad saada, pakkudes tarnijatele hõlpsamini aru, mida klient täpselt soovib.
SRS-dokumendi kirjutamise eelised
Lisaks eduka tootearenduse aluse loomisele, luues klientide ja tarnijate vahelise joonduse ja hoides kõiki asjaosalisi samal lehel, pakub SRS mitmeid muid eeliseid, mis muudavad selle kirjutamiseks vajaliku pingutuse väärt.
Kurosh Farsimadani sõnul, Rideau täisversiooniarendaja, "SRS-i kasutamine võib kõrvaldada ja vältida vigu projekteerimisetapis, kuna kõik vastuolulised nõuded ja funktsioonid, mis vajavad valideerimist, on siinkohal fikseeritud ja sidusrühmadega saab ümberhindamiseks ühendust võtta."
Tarkvaraarenduse varases staadiumis on muudatuste tegemine alati oluliselt odavam kui hiljem, kui juba on kulutatud lugematuid tunde ning palju energiat ja ressursse. Hästi kirjutatud SRS-i olemasolu aitab optimeerida arendusprotsessi, vältides ülesannete dubleerimist ja struktureerides probleeme viisil, mis muudab need hõlpsasti lahendatavaks.
Kogu muu dokumentatsioon - nii tehniline kui ka äriline - võib põhineda SRS-il, et tagada selle järjepidevus ja täpsus.
SRS-i komponendid
Kaks SRS-i dokumenti pole identsed, kuna kõik tarkvaraprojektid on erinevad, mõned kasutavad juga arendusmudelit ja teised harjutavad väledat arendust. Siiski on endiselt võimalik destilleerida SRS-i põhikomponente ja luua ligikaudne ülevaade selle väljanägemisest:
- Sissejuhatus
- Eesmärk
- publik
- Mõeldud kasutamiseks
- Ulatus
- Akronüümid ja mõisted
- Üldine kirjeldus
- Kasutaja vajadused
- Sõltuvused ja eeldus
- Nõuded ja süsteemi funktsioonid
- Funktsionaalsed nõuded
- Nõuded välisele liidesele
- Süsteemi funktsioonid
- Mittetoimivad nõuded
Esimeses osas kirjeldatakse arendatavat toodet, selle eesmärki, sihtrühma, kavandatud kasutust ja ulatust. Teises osas antakse lisateavet kasutajate vajaduste ja tegurite kohta, mis võivad takistada SRS-is esitatud nõuete täitmist. Viimane suurem osa on pühendatud nii funktsionaalsetele kui ka mittetoimivatele erinõuetele.
Kuidas kirjutada head SRS-i?
Hea SRS peaks vastama mitmele põhiomadusele. See peaks olema:
- Korrektne: On oluline tagada, et SRS kajastaks alati toote funktsionaalsust ja spetsifikatsioone.
- Ühemõtteline: Parem on olla liiga konkreetne kui mitmetähenduslik. SRS ei ole kirjanduslik meistriteos, nii et isegi kõige elementaarsemaid stiilireegleid võib selguse nimel ignoreerida.
- täielik: Pole kunagi hea mõte jätta kõrvale ühtegi kliendi soovitud funktsiooni.
- järjekindel: Kõiki lühendeid ja määratlusi tuleks kogu SRSis kasutada järjepidevalt.
- Järjekord tähtsuse ja / või stabiilsuse järgi: Aeg on arendusprotsessi ajal sageli napp ressurss, seega on nõuete järjestamine nende olulisuse ja stabiilsuse järgi hea mõte.
- Kontrollitav: Iga nõude jaoks peaks olema kontrollimeetod.
- Muudetav: Nõudeid tuleks muuta süstemaatiliselt ja nende muudatusi mõju teistele nõuetele tuleks arvestada.
- Jälgitav: Kõik nõuded peaksid olema päritolu järgi jälgitavad.
Kuidas RM tarkvara aitab SRS-dokumentide kirjutamisel
Hea SRS-dokumendi on täiesti võimalik kirjutada Microsoft Wordi, Google Docsi või mõnda muusse tekstitöötlusprogrammi. Selle lähenemisviisi probleem on see, et see võib olla piinavalt tüütu ja aeganõudev. Fakt on see, et isegi suhteliselt sirgjoonelised tarkvaraarendusprojektid võivad olla nõudlikud. Kui nõuded muutuvad, siis sõna piirid protsessorid, näiteks Microsoft Word, paljastatakse kiiresti.
Selle asemel, et hiljem arendusprotsessis takistusi tekitada, on palju parem mõte kohe alguses kasutada spetsiaalset nõuete haldamise tööriista nagu Visure. Pühendunud nõuete haldamise tööriist pakub täielikku nõuete täielikku protsessi, haldades kogu nõuetega seotud teavet ning nende suhteid ja suhtlust kasutajatega.
Visure on suurepärane näide kaasaegsest nõuete haldamise tööriistast, kuna see on spetsiaalselt välja töötatud tervikliku nõudeprotsessi, sealhulgas nõuete kogumise, analüüsi, spetsifikatsiooni, valideerimise ja kontrollimise, tervikliku toe pakkumiseks. jälgitavus, haldamine ja taaskasutamine. Visure on täielikult kohandatav ja see integreerub paljude kolmandate osapoolte tööriistadega.
Järeldus
Kõik need, kes on tarkvaraprojektiga tegelenud, teavad, kui kiiresti võivad nõuded kuhjuda ja kui keeruline võib neid hallata. Tarkvaranõuete spetsifikatsioon annab arendatava tarkvaratoote põhjaliku kirjelduse ja hoiab kõiki asjaosalisi samal lehel. Kaasaegsete nõuete haldamise tööriistade abil ei nõua tarkvaranõuete spetsifikatsiooni kirjutamine üldse palju pingutusi ja eeliseid on võimatu eirata.
