Hvordan gjennomfører vi kravanalysen?

Hvordan ser planleggingsprosessen ut?

Kravanalysen inngår i planleggingsprosessen, som i sin tur bør være som følger:

1. A prosjekt visjon som beskriver den endelige produkt som skal opprettes.
2. En generell handlingsplan eller idé som beskriver hva som må gjøres for å nå målene våre.
3. Liste over grunnleggende oppgaver som bestemmer fasene i arbeidet med prosjektet.
4. Tidsplanlegging, der vi definerer hva som skal leveres og når det skal leveres.
5. Detaljert planlegging av de enkelte oppgavene som ble opprettet i fase tre.

Kravanalysen dekker de tre første punktene i planleggingsprosessen.

Prosjektets visjon

På dette stadiet bør vi stille oss selv noen grunnleggende spørsmål:

1. Hva ønsker vi å gjøre?

På dette tidspunktet er vi sikkert allerede klar over hva vi streber etter, og prosjektideen er for lengst presentert og gjennomtenkt, men det er verdt å tenke dypere over den. Kanskje vil vi oppdage nye problemstillinger som er verdt å forklare. Følgende spørsmål kan være til hjelp her:

• Hvilket problem skal dette prosjektet løse?
• Hvem blir sluttbrukeren?
• Skal vi lage et grensesnitt for brukerne? Er det planlagt å opprette det i fremtiden? Er det bestemt hvilken type grensesnitt vi skal lage (desktop eller mobil)? Bryr vi oss om RWD?
• Finnes det noen lignende applikasjoner? Hva er fordelene og ulempene med dem?
• Er det laget noen innledende design eller mockups om prosjektet ennå?
• Vil prosjektet være avhengig av eksterne applikasjoner? Har de, eller kjenner vi, begrensningene deres?
• Vet vi noe om forventet ytelse og sikkerhetsnivå?

2. Hva er kravene?

Nå er tiden inne for å etablere en liste over krav som stilles til prosjektet. I tillegg til funksjonelle krav spesifiserer vi krav som ikke er relatert til funksjonalitet: brukervennlighet, responstid, hastighet, ytelse og sikkerhet.

La oss sjekke om hvert av kravene oppfyller følgende kriterier:

• er komplett - vi har hele bildet,
• er korrekt - sannferdig og forventet,
• er gjennomførbart - gjennomførbart og andre krav opphever det ikke,
• er nødvendig - det er nødvendig for at systemet skal fungere eller kreves av kunden,
• er entydig - leselig og umulig å feiltolke,
• er verifiserbar - etter implementering, gjennom observasjon og testing, er det mulig å avgjøre om dette kravet er oppfylt eller ikke.

3. Hva er det endelige målet?

Det er verdt å lage en enkel visualisering av prosjektets drift her. Ingenting hjelper til med å forstå ideen om prosjektet fullt ut som å tegne en grunnleggende flyt eller bare skrive på tavlen i punkter hva som skal skje i sin tur. Når det gjelder en applikasjon med et brukergrensesnitt, er den ideelle situasjonen å ha til og med de enkleste mockups.

4. Hva er prioriteringene?

Akkurat som når man bygger et hus, bør IT-prosjekter starte fra bunnen av og deretter vende seg til det man har mest behov for. I begynnelsen er det derfor nødvendig å spesifisere en liste over alle mulige funksjoner som et gitt prosjekt skal utføre, på grunnlag av kravlisten, og deretter bli enige om hvilke av dem som har høyest prioritet og skal utføres så snart som mulig, og hvilke som er av typen "nice-to-have".

Resultatet av hele prosjektvisualiseringsfasen bør være et generelt bilde av hvordan prosjektet skal fungere, enten det er gjennom mockups eller tegnet flyt av aktiviteter. Vi bør også få en liste over alle mulige funksjoner som et gitt prosjekt skal oppfylle, og også vite hvilken prioritet hver av dem har.

Prosjektvisualisering er et viktig moment under behovsanalysen. Den bidrar til en grundig forståelse av problemets kjerne, og jo bedre materialet som illustrerer problemet er, desto mer effektivt blir de neste trinnene i planleggingen.

Handlingsplan

På dette stadiet bestemmer vi allerede hvordan vi ser for oss driften av prosjektet som helhet. Det er bra å ha noen ideer for implementering, tenke og diskutere hver av dem, og fremheve deres svakheter og styrker. Det er også verdt å tegne en valgt idé i detalj her, om ikke alle.

På dette stadiet er det også på tide å vurdere rent teknologiske spørsmål, ikke bare hvilket språk eller rammeverk prosjektet skal skrives på, men også hvilke tilleggsverktøy vi trenger, for eksempel om vi skal bruke AWS-stakken eller kanskje noe annet. Hvis vi nøler mellom noen teknologier eller ikke aner hva vi skal bruke, er det verdt å flytte en slik beslutning i tid og delegere til en forskningsoppgave. Dette kan vi selvfølgelig bare gjøre hvis videre planlegging ikke er blokkert av slik forskning. Ellers kan vi trygt knytte dem til oppgavene i sprint.

Hovedoppgaver

Når vi har etablert prosjektplanen, fortsetter vi med å definere hovedoppgavene, som deretter vil bli diskutert i detalj og brutt ned i mindre oppgaver av utviklingsavdelingen. team når du planlegger en ny sprint. Det er viktig å beskrive hver oppgave så nøyaktig som mulig.

Sammendrag

Som nevnt tidligere vil kravanalyseprosessen variere avhengig av prosjektets kompleksitet. Det finnes enklere og vanskeligere problemer, og det finnes også problemer som allerede er løst av noen, og helt nye problemer som du må vente litt lenger med. Uansett er det noen viktige tips å huske på:

• Kommunikasjon. Dette er den viktigste komponenten i ethvert prosjekts livssyklus; alt skal være klart definert og forklart.
• Forstå problemet raskt. Det er flott å ha skrevet prosjektdokumentasjon, men la oss huske at den er så kortfattet som mulig og ikke tar tusen sider. Hvert medlem av utviklingsteam bør ha tilgang til den og raskt kunne forstå prosjektets visjon.
• Enkelhet fremfor alt. La oss forsøke å gjøre det vi planlegger så enkelt som mulig, velge enklere løsninger som lett kan utvikles i fremtiden, eller gi avkall på dem når behovet oppstår.
• Du kommer ikke til å trenge det. Med tanke på at vi i programmeringen styres av YAGNI-prinsippet, har vi det her i bakhodet og akselererer ikke for mye.
• Endringer. La oss ikke være redde for dem; før eller siden trenger alle prosjekter dem. I tillegg må vi ikke innbille oss at det vi planlegger i dag, vil fungere for alltid. Samtidig bør vi ikke behandle endringer som noe dårlig og uønsket. Endringer bør være synonymt med forbedring, og det er det vi ønsker: at prosjektet skal bli best mulig.
• Tid. La oss ikke la planleggingen ta for lang tid og trekke ut i det uendelige. Hvis vi har et problem som blokkerer oss, så la oss lete etter løsninger utenfor eller velge det enkleste alternativet.

De ovennevnte aspektene er alltid verdt å huske på når du analyserer kravene, og da vil det gå greit og være grunnlaget for et godt planlagt prosjekt.

Les mer om dette:

• Hva er den beste prosjektledelsesmetoden for programvareutvikling?
• Codests gode praksis for å bygge programvare. Vår tilnærming til kundereisen
• En rask guide til hvordan du bygger og utvikler din egen markedsplass. Hva er verdt å vite?