Hur genomför vi kravanalysen?

Hur ser planeringsprocessen ut?

Kravanalysen ingår i planeringsprocessen, som i sin tur bör se ut på följande sätt:

1. A projekt vision som beskriver den slutliga Produkt som ska skapas.
2. En allmän handlingsplan eller idé som anger vad som behöver göras för att nå våra mål.
3. Lista över grundläggande uppgifter som bestämmer stadierna i arbetet med projektet.
4. Tidsplanering, där vi definierar vad som ska levereras och när det ska ske.
5. Detaljplanering av enskilda uppgifter som skapats under steg tre.

Kravanalysen omfattar de tre första punkterna i planeringsprocessen.

Projektets vision

I det här skedet bör vi ställa oss några grundläggande frågor:

1. Vad vill vi göra?

Visst, vid det här laget är vi redan medvetna om vad vi strävar efter, och projektidén har länge presenterats och tänkts igenom, men det är värt att fundera djupare på den. Kanske kommer vi att upptäcka nya frågor som är värda att förklara. Följande frågor kan vara till hjälp här:

• Vilket problem ska det här projektet lösa?
• Vem kommer att vara dess slutanvändare?
• Håller vi på att skapa ett gränssnitt för användarna? Är skapandet av det planerat i framtiden? Har den typ av gränssnitt vi skapar (skrivbord eller mobil) bestämts? Bryr vi oss om RWD?
• Finns det några liknande applikationer? Vilka är deras för- och nackdelar?
• Har några inledande ritningar eller modeller för projektet skapats ännu?
• Kommer projektet att vara beroende av några externa applikationer? Har de, eller känner vi till, sina begränsningar?
• Vet vi något om den förväntade prestandan och säkerhetsnivån?

2. Vilka är kraven?

Nu är det dags att upprätta en lista över de krav som ställs på projektet. Förutom funktionella krav specificerar vi de krav som inte är relaterade till funktionaliteter: användbarhet, respons, hastighet, prestanda och säkerhet.

Låt oss kontrollera om vart och ett av kraven uppfyller följande kriterier:

• är komplett - vi har hela bilden av den,
• är korrekt - sanningsenlig och förväntad,
• är genomförbar - genomförbar och andra krav upphäver inte den,
• är nödvändig - den behövs för att systemet ska fungera eller krävs av kunden,
• är otvetydig - läsbar och omöjlig att misstolka,
• är verifierbar - efter implementering, genom observation och testning, är det möjligt att avgöra om detta krav har uppfyllts eller inte.

3. Vad är det slutliga målet?

Det är värt att skapa en enkel visualisering av projektets verksamhet här. Ingenting hjälper till att fullt ut förstå idén med projektet som att rita ett grundläggande flöde eller helt enkelt skriva på tavlan i punkter vad som ska hända i sin tur. När det gäller en applikation med ett användargränssnitt är den ideala situationen att ha till och med de enklaste mockupsna.

4. Vilka är prioriteringarna?

Precis som när man bygger ett hus bör man i IT-projekt börja från början och sedan vända sig till det man behöver mest. I början är det därför nödvändigt att på grundval av kravlistan specificera en lista över alla möjliga funktioner som ett visst projekt kommer att utföra och sedan komma överens om vilka av dem som har högsta prioritet och ska utföras så snart som möjligt och vilka som är av typen "trevligt att ha".

Resultatet av hela projektvisualiseringsfasen bör vara en allmän bild av hur projektet ska fungera, antingen genom modeller eller genom det ritade aktivitetsflödet. Vi bör också få en lista över alla möjliga funktioner som ett visst projekt ska uppfylla och även veta vilken prioritet var och en av dem har.

Projektvisualisering är ett viktigt moment under kravanalysen. Det hjälper till att grundligt förstå kärnan i problemet, och ju bättre material som illustrerar problemet, desto effektivare blir nästa steg i planeringen.

Åtgärdsplan

I det här skedet bestämmer vi redan hur vi föreställer oss att projektet som helhet ska fungera. Det är bra att ha några idéer för implementering, tänka och diskutera var och en av dem och lyfta fram deras svagheter och styrkor. Det är också värt att rita en vald idé i detalj här, om inte alla.

I det här skedet är det också dags att fundera över rent tekniska frågor, inte bara vilket språk eller ramverk som projektet ska skrivas på utan också vilka ytterligare verktyg vi behöver, till exempel om vi ska använda AWS-stacken eller kanske något annat. Om vi tvekar mellan vissa tekniker eller inte har en aning om vad vi ska använda, är det värt att flytta ett sådant beslut i tid och delegera till en forskningsuppgift. Vi kan naturligtvis bara göra detta om den fortsatta planeringen inte blockeras av sådan forskning. Annars kan vi tryggt koppla dem till uppgifterna i sprint.

Huvudsakliga arbetsuppgifter

När vi har fastställt projektplanen fortsätter vi med att definiera de viktigaste uppgifterna, som sedan kommer att diskuteras i detalj och brytas ned i mindre uppgifter av utvecklingsavdelningen. Team när du planerar en ny sprint. Det är viktigt att beskriva varje uppgift så exakt som möjligt.

Sammanfattning

Som tidigare nämnts kommer kravanalysprocessen att variera beroende på projektets komplexitet. Det finns enklare och svårare problem, och det finns också sådana som redan har lösts av någon och helt nya som du behöver stanna upp längre. Oavsett vilket finns det några viktiga tips att tänka på:

• Kommunikation. Detta är den viktigaste komponenten i varje projekts livscykel; allt ska vara tydligt definierat och förklarat.
• Förstå snabbt problemet. Det är bra att ha projektdokumentation skriven, men låt oss komma ihåg att den är så kortfattad som möjligt och inte tar tusen sidor. Varje medlem av utvecklingsteam bör ha tillgång till den och snabbt kunna förstå projektets vision.
• Enkelhet framför allt. Låt oss försöka göra det vi planerar så enkelt som möjligt, välja enklare lösningar som lätt kan utvecklas i framtiden, eller avstå från dem när behovet uppstår.
• Du kommer inte att behöva det. Med tanke på att vi i programmeringen styrs av YAGNI-principen, har vi den här i bakhuvudet och accelererar inte för mycket.
• Förändringar. Låt oss inte vara rädda för dem; förr eller senare behöver varje projekt dem. Dessutom ska vi inte lura oss själva att det vi planerar idag kommer att fungera för alltid. Samtidigt ska vi inte behandla förändringar som något dåligt och oönskat. Förändringar ska vara synonymt med förbättring, och det är det vi vill: att projektet ska bli bäst.
• Tid. Låt oss inte låta planeringen ta för lång tid och dra ut på tiden. Om vi har ett problem som blockerar oss, låt oss då leta efter lösningar utanför eller välja det enklaste alternativet.

Ovanstående aspekter är alltid värda att komma ihåg när man analyserar kraven, och då kommer det att gå smidigt och ligga till grund för ett välplanerat projekt.

Läs mer om detta:

• Vilken är den bästa projektledningsmetoden för mjukvaruutveckling?
• Codests goda praxis för att bygga programvara. Vår strategi för kundresan
• En snabbguide till hur du bygger och utvecklar din egen marknadsplats. Vad är värt att veta?