Visure lahendused


Toetus
Registreeri
Logi sisse
Alusta tasuta prooviversiooni

Kuidas kirjutada suuri nõudeid

Kuidas kirjutada suuri nõudeid

Sisukord

Iga tarkvaraarendusprojekti üks olulisemaid osi on üksikasjalike ja täpsete nõuete loomine. Ilma selge arusaamata sellest, mida tuleb ehitada, on võimatu luua kvaliteetset lõpptoodet. Kahjuks on heade nõuete kirjutamist sageli lihtsam öelda kui teha. Peamine põhjus, miks inimesed kehvad nõuded kirjutavad, on see, et neil pole heade nõuete kirjutamise koolitust ega kogemust. Kui teil või teie töötajatel on probleeme heade nõuete kirjutamisega, võib teile kasu olla heade nõuete koostamise juhistest. Kui võtate aega paremate nõuete kirjutamise õppimiseks, saate parandada oma tarkvaraarendusprojektide üldist kvaliteeti – ja säästa end paljudest peavaludest.

Mis on nõuete spetsifikatsioon?

Nõuete spetsifikatsioon on protsess, mille käigus määratletakse, dokumenteeritakse ja analüüsitakse nõudeid. See on tarkvaraarenduse oluline osa, kuna tagab, et kõik sidusrühmad lepivad enne arenduse algust tarkvara funktsionaalsuses kokku. Seda tehes väheneb arusaamatuste ja hilisemate ümbertegemiste tõenäosus.

Nõuete spetsifikatsioon, tuntud ka kui dokumentatsioon, on protsess, mille käigus märgitakse üles või kirjutatakse kõik süsteemi- ja kasutajanõuded dokumendi vormis. Need nõuded peavad olema selged, täielikud, kõikehõlmavad ja järjepidevad.

Miks on oluline kirjutada häid nõudeid?

Heade nõuete spetsifikatsioonide olemasolul on palju eeliseid. Mõned neist on loetletud allpool:

  • Aitab tagada, et kõigil sidusrühmadel oleks ühtne arusaam arendatavast süsteemist. See väldib arusaamatusi hilisemates arenguetappides.
  • Toimib kõigi sidusrühmade jaoks arendusprotsessi ajal võrdluspunktina.
  • Aitab varakult tuvastada nõuete lüngad.
  • Vähendab üldkulusid ja arendusaega, kuna väldib nõuete muutumisest tingitud ümbertegemist.

Mida me saavutame suurte nõuete kirjutamisega?

On palju asju, mida suured nõuded aitavad saavutada. Mõned neist on loetletud allpool:

  • Suured nõuded aitavad tagada, et arendatav süsteem vastaks kasutajate vajadustele.
  • Need on aluseks süsteemi testimisel, et tagada selle ootuspärane toimimine.
  • Need aitavad vähendada üldkulusid ja arendusaega, vältides nõuete muutumisest tingitud ümbertegemist.
  • Suured nõuded aitavad arendusprotsessi tõhusamaks ja tulemuslikumaks muuta.

Väljakutsed nõuete kirjutamisel

Nõudeid kirjutades seisavad inimesed silmitsi erinevate väljakutsetega.

Kehv paberimajandus – Mõnes organisatsioonis protsesside dokumenteerimine kas puudub või ei ole tasemel. Sel juhul saab nõuete kogumisest kaheetapiline protsess: esmalt pöördprojekteerige olemasolevat protsessi ja seejärel tehke kindlaks valdkonnad, mis vajavad täiustamist ja optimeerimist. Kinnitamaks, et nõuded on sisustatud ja täpsed, on oluline tuvastada peamised sidusrühmad ja valdkonna eksperdid, tehes nendega otsest koostööd. Äriprotsesside kaartide joonistamine ja töövoogude visualiseerimine on selleks kaks suurepärast viisi. See aitab kõrvaldada ebaõiged eeldused, pakkudes samas ka täielikku pilti. Protsessikaartide joonistamine ja protsesside kuvamine on sel eesmärgil kaks kasulikku lähenemisviisi.

Vastuolulised nõuded – Kui sidusrühmadel on oma ärieesmärkidel erinevad prioriteedid, toob see kaasa nõuded, mis on üksteisega vastuolus. Sellistel juhtudel on ärianalüütiku kohustus dokumenteerida üksikasjalikult kõik nõuded, teha kindlaks, millised taotlused on üksteisele vastandlikud, ja anda sidusrühmadele võimalus otsustada, mis on prioriteetne.

Te ei saa teha otsuseid sidusrühmade panust kuulamata ja ärianalüütikuna võib teil olla ideid selle kohta, mida tuleks eelistada. Sidusrühmade vaatenurga kuulamine on endiselt ülioluline. Küsitluse korraldamine võib olla üks viise, kuidas saada selgust selles, mis on enamiku sidusrühmade jaoks kõige olulisem.

Kasutajasisendi kättesaamatus – Lõppkasutajate kättesaamatust võivad põhjustada mõned põhjused ja igaüks neist nõuab oma lahendust. Näiteks mõnikord on lõppkasutajad oma igapäevatööga nii hõivatud, et ei taha nõuete kogumise tegevustes osaleda.

Sellistel juhtudel on ärianalüütikul parim, mida teha saab, piirata kaasamiste arvu ja kestust. Enne kohtumist võimalikult suure uurimistöö tegemine aitab arutelu organiseeritumaks ja informatiivsemaks muuta. See on peaaegu nagu nõuete kogumise muutmine nõuete valideerimise seanssideks. fookusrühmade määratlemine ja iga rühma jaoks sobivamate lõppkasutajate väljaselgitamine

Keskendumine kogemuse asemel liidesele – Paljudel sidusrühmadel ja lõppkasutajatel on selge nägemus sellest, kuidas uus lahendus peaks välja nägema, kuid nad ei tea, mida see peaks saavutama. Mis tahes süsteemi kasutajaliides on ülioluline, kuid see ei tohiks funktsionaalsust määratleda ega häirida.

Ärianalüütikud peaksid alati meeles pidama, et disaini- ja funktsionaalsed nõuded peavad oma dokumentatsioonis lahus olema. Kasutades üldisemaid tööriistu, nagu diagrammid, kasutajalood või madala jõudlusega prototüübid, mitte kujunduskavandite, saavad nad keskenduda nõuete kogumise funktsionaalsetele aspektidele.

Sidusrühmade sisendid – Kui sidusrühmad või lõppkasutajad püüavad disaineritele öelda, kuidas süsteem peaks töötama, mitte seda, mida süsteem peaks tegema, võib see viia ebaoptimaalsete kujundusteni. Selle vältimiseks kinnitage iga võimalik "valenõue", küsides "miks?" kuni jõuate tegeliku probleemini, mis vajab lahendamist.

Suhtluse probleemid – Probleemide hulgas, mis võivad ärianalüütiku ja teiste osapoolte vahel valesti suhelda, on keelebarjäärid, valed oletused, ebapiisavalt selgitatud sõnavara ja tehniliste terminite liigne kasutamine.

Ideaalne lähenemisviis selle probleemi vältimiseks on sagedane suhtlemine ja kahepoolsete vestluste arendamine. Dokumenteerige avastatud vajadused ja esitage need eksperdihinnanguks ja kriitikaks erinevatele teemaspetsialistidele, looge žargooni sõnastik ja kontrollige ruume üle.

Õigete nõuete kogumi reeglid

Nõuded peavad järgima teatud reegleid, et neid saaks nimetada õigeks.

  • täielik – Nõuete dokument peaks sisaldama piisavalt teavet, et teie arendusmeeskond ja testijad saaksid toote lõpule viia ja tagada, et see vastab kasutaja nõuetele ilma vigadeta.
  • järjepidevus – Säilitage ühtlane üksikasjalikkuse tase. Näiteks kasutajate nõuete puhul peaks iga lause teemaks olema lõppkasutaja. Samamoodi peaks süsteeminõuete puhul süsteem olema iga lause teema.
  • Muudetavus – Nõuded võivad projekti elutsükli jooksul muutuda. Nõudelogi tuleb säilitada ning selles tehtud muudatuste mõju teistele nõuetele ja projekti elementidele peab olema võimalik analüüsida.
  • Prioriteetide seadmine – Nõuded tuleb klassifitseerida tähtsuse seisukohalt. Kõik süsteemile soovitud omadused ei ole võrdselt olulised. Selleks oleks kasulik kehtestada reegel nõuete prioriteedid määratlemiseks organisatsiooni tasandil ja kohandada seda iga projekti jaoks. Ja töötage koos kasutajatega, et nad saaksid nõudeid tähtsuse järjekorda seada.

20 nõuannet paremate nõuete kirjutamiseks

Igal organisatsioonil on erinev töömeetod, seega ka erinevad nõuded. Seetõttu võib ka nõuete haldamise protsess olla erinev. Kuid üks asi, mis jääb järjepidevaks, on kirjutamisnõuete põhialused. Allpool on 20 näpunäidet paremate nõuete kirjutamiseks.

  1. Ühekaupa – Iga nõuet tuleks käsitleda kui eraldiseisvat testjuhtumit. Sidendeid nagu ja, või jne ei tohiks kasutada, kuna need võivad viia nõuetest ilmajäämiseni. See on eriti oluline, kuna sellised terminid võivad tarkvaraarendajatel ja testijatel nõudeid tähelepanuta jätta. Üks võimalus selle vältimiseks on keerukate vajaduste jagamine väiksemateks osadeks, kuni neid saab eraldi testida.

  1. Rääkige "mida", mitte "kuidas" – Keskenduda tuleks sellele, mida süsteem teeb, mitte sellele, kuidas ta seda teeb. Lisaks vältige liiga sügavat süvenemist kujundusteemadesse, nagu väljade nimed, programmeerimiskeele objektid ja tarkvaraobjektid. Kui leiate end nõuete spetsifikatsiooni dokumendis nendel teemadel arutlemas, astuge samm tagasi – see tähendab tõenäoliselt, et muutute liiga konkreetseks.

  1. Kontrollitav – Veel üks asi, mida nõuete korraldamisel meeles pidada, on see, et need peaksid olema alati testitavad. See tähendab, et peab olema võimalik kontrollida, kas süsteem vastab kõnealusele nõudele. See on seotud ka meie järgmise punktiga – jälgitavusega. Kui nõue on täis ebamääraseid termineid, siis on seda raskem analüüsida ja kontrollida, kas süsteem vastab nendele standarditele jõudluse mõttes. Seetõttu püüdke oma keeles võimalikult palju selgust ja täpsust, et nõuete kogumine ei oleks mitmetähenduslik protsess.

  1. Jälgitavus – Projektijuhtimise jälgitavus tähendab nõuete seotust projekti teiste komponentidega. See võimaldab projektijuhtidel, arendajatel ja sidusrühmadel jälgida nõude kogu elutsüklit algusest lõpuni nii kõikides suundades kui ka süsteemi teistes osades. Kui haldate jälgitavust õigesti, saate vältida koodi, mis ei vasta ühelegi nõudele ("tray" kood), ja tagada, et iga testjuhtum katab vähemalt ühe nõude. Saate muuta nõuded jälgitavaks, märgistades need kordumatu identifikaatoriga ja esitades teabe nende allika kohta keskses hoidlas, mis on juurdepääsetav kõigile meeskonnaliikmetele.

  1. Võimalik – Tagada, et projekti eelarve ja ajakava koos olemasolevate ressurssidega oleksid teostatavad. Kui need tingimused suudavad nõuet toetada, siis on võimalik plaaniga edasi liikuda.

  1. järjepidevus – Säilitage ühtlane üksikasjalikkuse tase. Näiteks kasutajate nõuete puhul peaks iga lause teemaks olema lõppkasutaja. Samamoodi peaks süsteeminõuete puhul süsteem olema iga lause teema.

  1. Erandeid – Nõudel ei tohiks olla vabastusklauslit. Näiteks "Süsteem määrab sisselogimiskatsete arvu, välja arvatud juhul, kui kasutaja on selgelt sisestanud vale kasutajanime".

  1. Aktiivne hääl – Kirjutage alati aktiivse häälega, veendudes, et iga lause teemaks on üks näitlejatest.

  1. Öelge "väljalaskmise" klauslitele ei – Püüdke hoida eemale väljaütlevatest fraasidest nagu aga, välja arvatud ja ainult vajadusel.

  1. Lühendeid pole – Iga nõue peaks olema täislause ilma akronüümide või žargoonita.

  1. Teema ja predikaat – Iga nõude jaoks peavad olema subjekt (kasutaja/süsteem) ja predikaat (eesmärgitud tulemus, toiming või tingimus). 

  1. selgus - Vältige mitmetähenduslikkust, mis on põhjustatud selliste akronüümide kasutamisest nagu jne, u. jms.

  1. Kasutage õigeid tingimusi – Tundmatud terminid, nagu kasutajasõbralik, mitmekülgne ja vastupidav, võivad katsejuhtumite määratlemisel raskusi tekitada. Nendel sõnadel on erinevate inimeste jaoks sageli erinev tähendus.

  1. Spekulatsioonid võivad tekitada kahju – ära arva; ärge koostage loendeid funktsioonidest, mis ei tule kõne allagi. Öelda, et soovite, et süsteem lahendaks kõik ootamatud tõrked, on puhas fantaasia, sest ükski süsteem ei ole kunagi 100 protsenti selline, nagu soovite. Vältige dubleerimist ja vastuolulisi väiteid.

  1. Vältige valikuid – Ära paku ideid ega võimalusi. Saate neid märgata igas avalduses, mis sisaldab fraase võib, võiks, võiks või peaks.

  1. Korraldatud paberimajandus teeb imet – Hoidke nõuded ühes kohas korraldatuna, et parandada oma dokumendi loetavust ja vältida ajaraiskamist mitmele allikale ristviitamisele.

  1. Rääkige sellest, mis meil on – Ärge viidake veel määratlemata nõudele. Teie eesmärk on muuta dokument võimalikult meeldivaks lugemiseks.

  1. Mida tuleks kasutada ja kus? – „Shall“ tuleks kasutada nõuete esitamisel, sõna „tahe“ tuleks kasutada faktiväidete esitamiseks; & "Peaks" tähistama saavutatavat eesmärki.

  1. Korrektne – Veenduge, et iga lause oleks täielik ja grammatiliselt õige koos õige subjekti, verbi ja predikaadiga.

  1. Keskenduma – Määrake fookus, kõrvaldades segased, liiga pikad fraasid ja viited aegunud paberitele.

Visure Requirements ALM platvorm

Visure Requirements ALM platvorm on üks usaldusväärsemaid rakenduste elutsükli haldusplatvorme, mis on spetsialiseerunud nõuete haldamisele igas suuruses organisatsioonidele üle kogu maailma. Visure suuremate partnerite hulka kuuluvad äri- ja ohutuskriitilised ettevõtted. Ettevõte integreerub läbi kogu rakenduse elutsükli halduse protsesside, sealhulgas riskijuhtimise, probleemide ja defektide jälgimise, jälgitavuse haldamise, muudatuste haldamise ja mitmed muud valdkonnad, nagu kvaliteedianalüüs, nõuete versioonide koostamine ja võimas aruandlus.

Kui otsite nõuete haldamise tööriista, mis aitab teil täita nii funktsionaalseid kui ka mittefunktsionaalseid nõudeid, vaadake jaotist Visure nõuded. Selle platvormi abil saate hõlpsalt luua, hallata ja jälgida kõiki oma projekti nõudeid ühes kohas.

Järeldus

Suurepärase tarkvara tootmiseks on oluline omada hästi kirjutatud nõuete spetsifikatsiooni. See dokument kirjeldab kliendi vajadusi ja seda, mida süsteem peab tegema, et täita tema ootusi. Heade nõuete kirjutamine võib aga olla keeruline. On palju standardeid ja juhiseid, mida tuleb järgida ning nende kirjutamiseks on palju erinevaid viise, olenevalt kasutatavast keelest ja tööriistadest. Visure Requirements ALM Platform pakub kursust, mis õpetab koostama tõhusaid nõuete spetsifikatsioone, kasutades parimaid tavasid ja tööstusstandardeid. Kursusel käsitletakse kõiki nõuete dokumendi olulisi komponente, alates struktuurist kuni vorminguni, aga ka seda, kuidas kasutada erinevaid keeli nõuete kirjutamisel. Samuti tõstab see esile suurte nõuete omadused, et saaksite luua dokumente, millega teie meeskonnale meeldib töötada. Kui soovite tõhusate nõuete kirjutamise kohta lisateavet, proovige Nõuete täpsustamise kursus Visure Requirements ALM Platform täna!

Ärge unustage seda postitust jagada!

top