Citat:
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).