[Dimme]

Originally posted by uffe_nordholm@Oct 14 2008, 12:50
Idealet är att du specificerar så långt att programeraren kan direkt översätta din spec till programkod, rad för rad. För dig är det nog orealistiskt att skriva så noga, men allt du kan göra för att underlätta för programeraren lär göra det jobbet billigare.

Nej, man ska aldrig skriva till en programmerare hur han ska koda. Det är programmerarens jobb.

[Ara]

Originally posted by Martin™@Oct 14 2008, 12:29
Jag känner att jag måste kolla upp lite mer hur en kravspec ser ut, för jag trodde det bara var en lista med olika funktioner som man vill ha med i sin hemsida.. och då tycker jag det borde gå lika bra att se på en redan färdig hemsida vilka funktioner som finns och hur de fungerar. Reverse engineering helt enkelt.

Kolla på http://www.upedu.org/upedu/

Där har du allt du behöver (sen kan såklart dokumentationen variera breoende på projektmodell)

[Dimme]

Här får du exempel på ett kravspec som jag skrev för ett år sedan i ett litet projekt på universitetsnivå.

http://files.dimme.net/Requirements_specif...tion_team26.pdf

[autosvar]

Originally posted by uffe_nordholm@Oct 14 2008, 12:50
Nu har jag inte gjort många webbsidor åt andra, men min erfarenhet hittills är att ju mer detaljerad din kravspec är desto lättare blir arbetet för den som gör jobbet.

Var noga med skall- och bör-krav. Fokusera på mål, syfte och slutresultat. Undvik för många skall-krav som kan fördyra och försvåra ett projekt helt i onödan.

[Conny Westh]

Originally posted by uffe_nordholm@Oct 14 2008, 12:50
Nu har jag inte gjort många webbsidor åt andra, men min erfarenhet hittills är att ju mer detaljerad din kravspec är desto lättare blir arbetet för den som gör jobbet. Och i detta sammanhang sätter jag likhetstecken mellan "lättare" och "billigare".

Idealet är att du specificerar så långt att programeraren kan direkt översätta din spec till programkod, rad för rad. För dig är det nog orealistiskt att skriva så noga, men allt du kan göra för att underlätta för programeraren lär göra det jobbet billigare.

Håller med om beskrivningen att ju mer relevant information som finns dokumenterat i kravspecen desto billigare blir utvecklingsarbetet.

Kodningsjobbet brukar normalt normalt vara 15-20% av hela projektkostnaden.

Kravspecen ska inte beskriva för programmeraren hur han ska programmera, men däremot ska den besriva vadbeställaren förväntar sig att få levererat. Det ska vara så detaljerat att det för en tredje part ska vara möjligt att testa verenda (verksamhets-)funktion med de angivna exempel på indata och att man vid testet får ut det förväntade resultatet.

Det går exempelvis inte att skriva som ett krav att:

Krav xyz: Applikationen ska kunna exportera till Excel.

Om beställaren egentligen menar att man vill kunna:

Krav xyz: Exportera vinst efter avskrivningar, bokslutsdispositioner och skatt samt nettoomsättning per år från markerade räkenskapsår och visa nyckeltalen för vinstmarginal per produktgrupp i ett cirkeldiagram i Excel med tydlig text med en bakgrund av olika färger i varje "tårtbit" i cirkeldiagrammet. Färgerna ska vara Grön, Gul, Brun, Orange. Maximalt 4 år behöver visas åt gången. Excel ska startas utan vidare handgrepp från användaren.

Ni fattar vad jag menar...

Det har visat sig att användningsfall är ett sätt att beskriva krav som lättast kan förstås av både beställare och leverantörens systemanalytiker. Enligt Agile metoden så använder man User-Stories men som är både funktionella och icke-funktionella krav. Bda dessa vägar är till för att undvika missförstånd mellan beställare och leverantör.

Det är bara ca 16% av alla IT-projekt som är framgångsrika i den bemärkelsen att de levereras i tid, med beställda funktioner och till avtalad budget. Övriga 84% är mao misslyckade. Till strsta delen beror detta på att parterna slarvat med kraven från början. Man har kastat sig in i ett projekt utan att ha vettiga krav eller med helt orelistiska förväntningar på vad leverantören kan åstadkomma, underfinansiering är ett annat av de viktigaste orsakerna till misslyckande.

Ett mycket bra sätt att skriva de första trevande kraven är att använda Användningsfall (AF). Ett AF är ett konkret och explicit rutin för hur beställaren har tänkt att systemet ska användas. Exempel på ett anvndningsfall i ett bokföringssystem kan vara "Registrera en verifikation" eller "skapa nytt bokföringsår" eller "gör ett bokslut".

Sen ska varje användningfall beskrivs i detalj ur beställarens/användarens synvinkel, det ska vara så detaljerat att en testledare ska kunna skriva ett konkret testfall för det aktuella användningsfallet.

Detta var de funktionella kraven. Sen ska man även ha med icke-funktionella krav som lagkrav, tekniska begränsningar, xml-format på överföringar till skattmasen, grossisten elelr vad det kan vara. Eventuella befintliga databaser eller data som inte enkelt kan omformas.

Sen ska den som är kravanalytiker ta sig an beställarens kravspec och översätta den till en systemdesign och i den vevan skriva en systemspecifikation, den ska sedan prgrammeraren kunna använda i sitt arbete för kodningen.

Paralellt ska någon med kompetensen testledare ta sig an att skriva en testspecifikation. Dvs göra ett testdokument som testaren sedan kan använda för att veta vad de ska testa.

I mycket små projekt kan givetvis dessa roller bemannas av samma fysiska personer, men resultatet brukar bli bäst om det är experter inom respektive område.

åtmindstonde tycker jag man ska skilja ut tre roller Beställare (kravspec+acceptanstest), Systemdesigner (kravanalys, systemdesign, databasschema, systemdokumentation), Programmerare (kodning+installation).

[Martin™]

Den här tråden var bra. Steg för steg vid idé, Vid idé, vilka steg ska man ta.

[Martin™]

Jag jobbar vidare med mitt lilla projekt. Nu undrar jag om det går att "slå ihop" flera olika forumdatabaser, från olika typer/versioner av forum, till en enda? Så man kan behålla alla trådar och svar.

[Conny Westh]

Originally posted by Martin™@Nov 15 2008, 15:24
Jag jobbar vidare med mitt lilla projekt. Nu undrar jag om det går att "slå ihop" flera olika forumdatabaser, från olika typer/versioner av forum, till en enda? Så man kan behålla alla trådar och svar.

Om informationen finns i en relationsdatabas för varje forum så kan det vara möjligt. Du bör dock betrakta själva migreringen från gamla system till det nya som ett eget projekt för varje gammalt system du migrerar. Ofta har de helt olika förutsättningar.

Det beror naturligtvis på hur mycket jobb det är för varje gammalt system om det ska vara ett eget projekt.

Jag kan tänka mig att varje gammalt forum måste ha helt avskiljda "konferenser" i det nya systemet.