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.

Då kan vi vara överens om att ifall man som utvecklare även skall ta fram kravspec krävs det att man sätter sig in i (eller redan kan) verksamheten bra och att man jobbar mycket nära kunden!? Annars kan det bli hur illa som helst (som det verkar vara här)

Begreppen är lika relevanta oavsett hur stor organisation man är verksam i, du måste skilja på "roller" och "jobbtitlar" som jag skrev.

"Jobbtitlar" kan skilja sig mycket mellan stora respektive små organisationer men "rollerna" är per defintion närmast identiska.


i De minsta utvecklingsprojekten behövs:

Beställare (en person):
Kompetens: Beställare, Kravhanterare (ev annan inhyrd konsult om beställaren ej har denna kompetens)
Dokument/Leverabler: Kravspec (Gärna med verksamhetsbeskrivning)
Jobb: Kravhantering, Avtal, Acceptanstest (godkännande/eller ej av leverans)


Leverantör (en person):
Kompetens: Kundansvarig, Avtal, Systemutvecklare
Jobb: Avtal, Systemutveckling(Vid behov systemspec), Programtest/enhetstest, Systemtest, Installation, Utbildning av beställare
Dokument/Leverabler: Databas, Program, (ev källkod om kunden vill ha det), installation, övrig dokumentation


Avtal
Parterna förhandlar och kommer överens om en kravspec som ska ingå i ett avtal mellan parterna, Parterna kommer överens om en projektplan (Vad vardera parten lovar att bidra med och när saker ska finnas klara, samt pris).

I många fall finns det även drift och supportavtal som gör att leverantören har ett långtgående åtagande efter driftsättningen.

Har leverantören redan kunskap om verksamheten (kanske jobbat många år med detta som anställd eller haft uppfdrag mot samma kund förut) så blir startsträckan med att sätta sig in i beställarens verksamhet givetvis kortare. Det är många konsulter som lever just på att de har verksamhetskompetns i kombination med sin tekniska kompetens.

Förväxla inte det jag beskriver som utvecklingsprojekt med supportuppdrag, eller underhållsuppdrag.

I sak håller jag med dig, Conny, men i många mindre företag (mindre = få anställda = i princip alla svenska webbrelaterade företag) finns inte särskilt många jobbtitlar och inte sällan så är de mest för formalitetens skull :) De viktiga grunderna är givetvis att man måste veta vad man beställer, utvecklaren måste sköta sitt jobb och ett avtal bör finnas. Avtal är dock inte alltid så livsviktigt som du alltid framställer det :) Personligen har jag aldrig under hela min verksamma tid tvistat om ett avtal. Det handlar mer om vilka man arbetar tillsammans med.

@ConnyWesth
De beskrivningar av roller som du beskriver är generella och ingen absolut sanning.
Jag har tidigare jobbat med musikproduktion, och där har du även vissa roller som normalt existerar: producent, tekniker och musiker. Nuförtiden är det dock väldigt vanligt att rollerna övergår i varandra.

Som exempel kan jag nämna en kund som har en pokerträningssida och vill ha en handuppspelare med diverse träningsverktyg. Han skickar mig ett dokument som beskriver i mycket grova drag vad han vill ha för funktionalitet, men det är långt ifrån en acceptabel kravspec och omöjlig att göra en offert ifrån eftersom den är alldeles för odetaljerad och lämnar massor med frågetecken om vad som faktiskt skall göras.
Jag tar då och jobbar fram en specifikation tillsammans med en prototyp som visar exakt hur allt skall implementeras. Eftersom jag har erfarenhet av att utveckla sådana applikationer, kan UX-design och förstår verksamheten väl kan jag göra ett betydlig bättre jobb än beställaren med att ta fram specifika krav. Han går över mitt förslag till specifikation och vi gör ett par revisioner baserat på hans kommentarer.
Så i detta fall är jag leverantör, men gör kravhantering i samråd med beställaren. Det finns inget som säger att en kravhanterare inte också kan vara leverantör utan måste vara antingen beställaren själv eller en separat konsult.

I extrema fall vet faktiskt inte beställaren mycket mer att han exempelvis vill ha en hemsida och vad den har för mål, men saknar helt kunskap om vad för funktionalitet som är mest lämplig för att uppnå målet. Då kontaktar man vanligen en webbyrå eller en utvecklare och låter dem komma med förslag. Större webbyråer kommer involvera ett antal olika personer för att hitta det optimala sättet att uppnå målet, men med mindre webbyråer eller enskilda utvecklare faller det på utvecklarna själva.