Hvernig framkvæmum við kröfu­greininguna?

Hvernig lítur áætlanagerðarferlið út?

Kröfunagreiningin er hluti af áætlunargerðinni, sem aftur á móti ætti að vera sem hér segir:

1. A verkefni sýn sem lýsir endanlegu vara til að vera búið til.
2. Almenn aðgerðaáætlun eða hugmynd sem lýsir því hvað þarf að gera til að ná markmiðum okkar.
3. Listi yfir grunnverkefni sem ákvarða áfanga vinnunnar við verkefnið.
4. Tímastjórnun, þar sem við skilgreinum hvað og hvenær skuli afhenda.
5. Nákvæm áætlun um einstök verkefni sem unnin voru á þriðja stigi.

Kröfunagreiningin nær yfir fyrstu þrjá liði áætlunarferlisins.

Sýn verkefnisins

Á þessu stigi ættum við að spyrja okkur nokkurra grunnspurninga:

1. Hvað viljum við gera?

Vissulega vitum við nú þegar hvað við stefnum að, og hugmyndin að verkefninu hefur lengi verið kynnt og vel ígrunduð, en það er þess virði að hugsa dýpra um hana. Kannski munum við uppgötva nýjar spurningar sem vert er að útskýra. Eftirfarandi atriði geta verið gagnleg hér:

• Hvaða vandamál ætti þetta verkefni að leysa?
• Hver verður endanlegur notandi þess?
• Erum við að búa til viðmót fyrir notendur? Er fyrirhugað að búa það til í framtíðinni? Hefur verið ákveðið hvaða tegund af viðmóti við búum til (borðtölvu- eða farsíma)? Sýnum við RWD athygli?
• Eru til nokkrar svipaðar forritanir? Hverjir eru kostir þeirra og gallar?
• Eru einhver upphafleg hönnun eða sýnishorn af verkefninu búin til ennþá?
• Mun verkefnið vera háð einhverjum ytri forritum? Eru takmarkanir þeirra þekktar eða vitum við um þær?
• Vitum við eitthvað um vænta frammistöðu og öryggisstigið?

2. Hvað eru kröfurnar?

Nú er kominn tími til að setja fram lista yfir kröfur verkefnisins. Auk virknikrafna tilgreinum við þær kröfur sem tengjast ekki virkni: notendavæni, móttækileika, hraða, afköst og öryggi.

Látið okkur Athugaðu hvort hver krafa uppfylli eftirfarandi skilyrði:

• er fullgerð — við höfum heildarmyndina af henni,
• er rétt — satt og væntanlegt,
• er framkvæmanlegt — framkvæmanleiki og aðrir skilmálar ógilda það ekki,
• er nauðsynlegt — það er þörf á því til að kerfið virki eða er krafist af viðskiptavininum,
• er ótvíræð — læsileg og ómöguleg til að misskilja,
• er staðfestanlegt — eftir innleiðingu, með athugun og prófunum, er hægt að ákvarða hvort þessu skilyrði hafi verið fullnægt eða ekki.

3. Hvert er endanlegt markmið?

Það er þess virði að búa til einfalda sjónræna framsetningu á starfsemi verkefnisins hér. Ekkert hjálpar til við að skilja hugmyndina að fullu betur en að teikna einfalt flæði eða einfaldlega skrifa á töflu í punktum hvað á að gerast í röð. Í tilviki forrits með notendaviðmóti er kjörið að hafa jafnvel einfaldustu sýnishorn.

4. Hvað eru forgangsröðin?

Rétt eins og þegar hús er byggt ættu upplýsingatækniverkefni að hefjast frá grunni og síðan beina athyglinni að því sem þú þarft mest. Í upphafi, á grundvelli kröfulista, er nauðsynlegt að tilgreina lista yfir allar mögulegar aðgerðir sem viðkomandi verkefni mun innhalda og síðan semja um hvaða þeirra hafa hæstu forgang og skulu framkvæmdar sem fyrst og hvaða teljast til “þægilegra aukaatriða”.

Niðurstaða alls verkefnisútfærslufasa ætti að vera almenn mynd af því hvernig verkefnið ætti að virka, hvort sem það er með sýnishornum eða teiknuðu flæði aðgerða. Við ættum einnig að fá lista yfir öll möguleg verkefni sem tiltekið verkefni á að uppfylla og vita hvaða forgang hvert þeirra hefur.

Sýnagervingur verkefnisins er lykilatriði í kröfu­greiningu. Hann hjálpar til við að skilja kjarna vandamálsins til hlítar, og því betri sem efnið sem sýnir vandamálið er, því skilvirkari verða næstu áætlunarstig.

Aðgerðaáætlun

Á þessu stigi ákvarðum við þegar hvernig við ímyndum okkur rekstur verkefnisins í heild. Gott er að hafa nokkrar hugmyndir um framkvæmdina, hugsa um og ræða hverja þeirra og benda á veikleika og styrkleika þeirra. Einnig er gott að teikna hér valda hugmynd í smáatriðum, ef ekki alla.

Þetta stig er einnig tími til að íhuga hreint tæknileg mál, ekki aðeins hvaða forritunarmáli eða ramma verkefnið verður skrifað í, heldur einnig hvaða viðbótartól við munum þurfa, til dæmis hvort við ákveðum að nota AWS stack eða kannski eitthvað annað. Ef við erum hikandi á milli nokkurra tæknilausna eða höfum enga hugmynd um hvað eigi að nota, þá er þess virði að fresta slíkri ákvörðun og færa hana yfir í rannsóknarverkefni. Auðvitað getum við aðeins gert þetta ef frekari áætlanagerð er ekki hindruð af slíkri rannsókn. Annars getum við örugglega bætt þeim við verkefnin í sprettur.

Aðalverkefni

Þegar við höfum komið á fót verkefnisáætluninni, förum við að skilgreina helstu verkefnin, sem síðan verða rædd í smáatriðum og sundurgreind í minni verkefni af þróun team Þegar verið er að skipuleggja nýjan sprett. Mikilvægt er að lýsa hverju verkefni eins nákvæmlega og mögulegt er.

Yfirlit

Eins og áður hefur komið fram mun ferlið við kröfu­greiningu breytast eftir flækjustigi verkefnisins. Það eru einfaldari og flóknari vandamál, og sum þeirra hafa þegar verið leyst af einhverjum, en önnur eru alveg ný og krefjast lengri stöðvunar. Sama hvað, eru nokkur mikilvæg ráð sem gott er að hafa í huga:

• Samskipti. Þetta er mikilvægasti þátturinn í lífsferli hvers verkefnis; allt skal vera skýrt skilgreint og útskýrt.
• Skilið vandamálið fljótt. Það er frábært að hafa verkefnisgögn skrifuð, en við skulum muna að þau séu eins hnitmiðuð og unnt er og taki ekki þúsund síður. Hver meðlimur þróunarteymisins lið Ætti að hafa aðgang að því og ætti að geta fljótt skilið sýn verkefnisins.
• Einfaldleiki umfram allt. Við skulum reyna að gera það sem við skipuleggjum eins einfalt og mögulegt er, velja einfaldari lausnir sem auðvelt er að þróa síðar eða hætta við þær þegar þörf krefur.
• Þú munt ekki þurfa það. Í ljósi þess að í forritun erum við leidd af YAGNI-reglunni, höldum við því í huga og flýtum okkur ekki of mikið.
• Breytingar. Látum okkur ekki óttast þær; fyrr eða síðar þarf hvert verkefni á þeim að halda. Auk þess skulum við ekki blekkja okkur sjálf með því að halda að það sem við skipuleggjum í dag muni virka að eilífu. Á sama tíma ættum við ekki að líta á breytingar sem eitthvað slæmt og óæskilegt. Breytingar ættu að vera samheiti við umbætur, og það er einmitt það sem við viljum: að verkefnið verði sem best.
• Tími. Látum okkur ekki eyða of miklum tíma í áætlanagerð sem dregst á langinn. Ef við rekumst á vandamál sem hindrar okkur, skulum við leita lausna utan frá eða velja auðveldustu lausnina.

Þessir þættir eru alltaf þess virði að hafa í huga þegar kröfurnar eru greindar, og þá mun allt ganga hnökralaust og verða grundvöllur vel skipulagðs verkefnis.

Lesa meira:

• Hvert er besta verkefnastjórnunarferlið við hugbúnaðarþróun?
• Bestu vinnubrögð Codest við hugbúnaðarþróun. Nálgun okkar á viðskiptavinjarferðalaginu
• Stutt leiðarvísir um að byggja og þróa þitt eigið markaðstorg. Hvað er gott að vita?