[Conny Westh]

Det verkar vara en förvirring av begrepp här, låt mig klargöra hur jag ser på begreppen:

Verksamhet: Om kunden är ett Dagis så är verksamheten dagisets verksamhet.

Krav: Användningsfall eller UserStories, ofta punktlistor med önskemål om vad systemet ska göra för verksamheten, men ett verksamhetskrav/funktionellt krav är aldrig en teknisk beskrivning.

Kravspec: Det är den verksamhetsmässiga bekrivningen av vad verksamheten vill åstadkomma, inet en beskrivning av hur man bygger ett IT-system. En kravspec innehåller inga tekniska beskrivningar. Om man inte har en kravspec att utgå ifrån så är det nästan en garanti att projektet kommer att hamna i kris (med mycket få undantag). En Kravspec är den kompletta sammanställningen av alla krav som ett projekt ska leverera till verksamheten. Ofta kompletteras det med konkreta "Testfall". En kravspec kan vara från en A4 till miljoner A4 beroende på projektstorlek och finansiering. Men även en kravspec på en A4 kan ta någon vecka att utföra och leverera.

Systemspec: Detta är en en teknisk beskrivning hur IT-sidan har tänkt bygga systemet, innehåller mycket tekniska beskrivningar. Har man en befintlig arkitektur och en bra kravspec så minskar kravet att ha en utförlig systemspec. Systemspecen brukar även inkludera en arkitekturspec, ibland har man en separat arkitekturspec. Vid riktigt små webbprojekt kan man ibland klara sig med en bra kravspec, utan systemspec.

Acceptanstest: Ett test som utförs av kunden/beställaren/verksamheten (ej ev leverantören) för att verkligen testa att det levererade IT-systemet, inklusive rutiner och dokumentation fungerar som man specifierat i den verksamhetsmässiga kravspecen. När acceptanstesten är klar så tar kunden över ansvaret för systemet (kan i sig outsourcas till en driftleverantör om den tekniska kunskapen inte finns i verksamheten).

Systemtest: Utförs av tekniskt kunnig personal, kan vara både inom verksamheten och hos leverantören (i större företag utförs det flera tester på olika nivåer hos leverantören, Siemens hade senast jag hörde det 17 olika nivåer, men de tillverkar ju Pacemakers och liknande så det är väl lite extremt exempel kanske).

ROLLER (OBS!!!! En fysisk person kan ha flera roller, i små projekt är det snarare regel än undantag att en person har flera roller, viktigt att prata om "ROLLER" i diskussionen, inte "befatttningar" / "Jobbtitlar").

Beställare: Den som har de befogenheter som behövs för att fatta bestllarbeslut, skriver avtal med Leverantören. Har oftast hjälp av en kravhanterare för att först ta fram ordentliga krav innan beställning görs hos IT-leverantör. Beställare har sällan personlig teknisk kompetens.

Kravhanterare: Verksamhtsperson som kan vara inhyrd konsult som är specialist på att beskriva verksamhetens krav, en helt oteknisk roll. Bakgrunden för en kravhanterare är sällan från den tekniska sidan utan dessa personer kommer oftast från mångårigt arbete inom verksamheten.

Acceptanstestare: Person hos beställaren som har kunskap om hur systemet förväntas fungera i verksamheten och den som fysiskt utför tester av det levererade systemet.

Systemdesigner: Gör mest arbete med design och en hel del kravanalys (analys av kravspec). Ibland programmering men i större företag ingen programmering då är detta mer en arkitektroll, men det finns en hel uppsjö av egna arkitektroller som jag inte tänktte dra här.

Systemutvecklare: En Systemutvecklare gör en del systemdesign som modellering och justering av systemspecifikationer. Ibland en del programmering. Roller är ganska flytande och en systemutvecklare har oftast många års erfarenhet.

Programmerare: En programmerare gör ALDRIG specifikationsarbete eller systemdesign. Enbart programmering och programtester. En programmerare har ofta betydligt kortare erfarenhet än en systemutvecklare och brukar därför inte ha lika stort eller brett ansvarsområde.

Givetvis finns det många fler roller, men det här är ett kort axplock av de viktigaste som vi resonerat om i denna tråd.