Jeg i en forrige uge fået læst bogen Software Requirements, og det har vist sig at være en ganske stor fornøjelse og samtidigt en ganske lærerig fornøjelse. Jeg vil i denne boganmeldelse komme ind på en række af de koncepter som anvendes i bogen. Jeg har købt bogen på Amazon.com i Kindle udgaven, og generelt kan det siges om bogen at den er en del af Microsofts serie om software udvikling og den kommer ind på mange af de problemstillinger som softwareudviklere og organisationer oplever, når nye it-løsninger skal udvikles. I forhold til prisen så er bogen pengene værd, og jeg kan klart anbefale jer som har interesse inden for enterprisearkitektur, løsningsarkitektur og softwareudvikling at købe bogen.

Om bogen

Jeg synes bogen er velskrevet og forfatteren har arbejdet med sine synspunkter og de teknikker som bruges i forhold til at kunne identificere og prioritere krav. Selvom bogen er velskrevet virker den også meget lang, men forfatteren har forsøgt at dele bogen op i små kapitler, hvilket på sin vis virker fuldstændig modsat.

Bogen introducerer en række koncepter og begrebet og i den kontekst får forfatteren beskrevet koncepterne på en hensigtsmæssig måde som gør det muligt for læseren at sætte sig ind i en struktureret tilgangsvinkel til kravspecifikation.

Set i forhold til at anvende budskaberne som beskrives i bogen til sin egen udviklingsproces så introducerer bogen en række skabeloner som virker lige til at anvende. Ligeledes er det muligt at implementere en række af skabelonerne nærmest som de er.

Forfatteren kom ind på, hvorfor det er vigtigt at arbejde med indsamling og prioritering af krav i nedenstående citat:

”Errors made during the requirements stage account for 40 to 60 percent of all defects found in a software project (Davis 1993; Leffingwell 1997)” – Karl E. Wiegers

Dermed sagt, hvis det er muligt for software udviklerne eller arkitekterne at få indsamlet kravene, få dem verificeret og prioriteret og implementeret i løsningen, så vil det være muligt at mindske omkostningerne som ellers ville have været realiseret.

“User requirements describe user goals or tasks that the users must be able to perform with the product” – Karl E. Wiegers

Set i forhold til at udarbejde en kravspecifikation så handler det om at få beskrevet de målsætninger som slutbrugerne har ved at anvende softwaren. Disse mål er nødvendige at få identificeret før de funktionelle krav til softwaren udarbejdes.

“Functional requirements specify the software functionality that the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.” – Karl E. Wiegers

De funktionelle krav som softwaren skal understøtte skal understøtte de forretningsmæssige behov som organisationen har ved at anvende softwaren. De funktionelle krav specificere, hvordan softwaren skal understøtte behovene. Fokus er på hvad softwaren skal kunne. De funktionelle krav skal samles i en samlet dokument kaldet en kravspecifikation. Kravspecifikationen indeholder også de non-funktionelle krav. De non-funktionelle krav omhandler hvordan løsningen skal fungere i sin kontekst fx hvad kvalitet er og hvor høj en oppetid som løsningen skal have.

“In addition to the functional requirements, the SRS contains non-functional requirements.” – Karl E. Wiegers

Kravspecifikation indeholder blandt andet de tekniske begrænsninger. Ifølge forfatteren så vil en kravspecifikation også indeholde de tekniske begrænsninger som har til formål at give udviklerne nogle klare rammer for, hvilke teknologier som løsningen skal kunne. 

“Constraints impose restrictions on the choices available to the developer for design and construction of the product” – Karl E. Wiegers

Håndtering af krav

De forskellige krav skal organiseres så det er muligt at kunne genfinde dem i set i forhold, hvilken interessent som har udtrykt behov for at få kravet opfyldt og i hvilken version af kravet som skal opfyldes. Det er ligeledes vigtigt at få sat styr på hvilke krav som er nødvendige at få sat styr på først, altså det som kaldes for prioritering. Det skal også være muligt at få undersøgt i hvilket materiale som kravene findes i og af hvilke interessenter som får deres behov opfyldt ved at kravene bliver implementeret.

Wiegers anbefaler at kravene bliver samlet i et kravhåndteringsværktøj, hvor det er muligt at arkivere metadata om dem.

Fælder

Wiegers kommer også ind på at der findes en række fælder omkring formuleringen af en kravspecifikation, krav og ikke mindst interessenterne. Krav skal i udgangspunktet være formuleret entydigt og de skal være til at finde på skrift for at de kan kommunikes ud til de rigtige interessenter.

Wiegers kommer herudover ind på nedenstående fælder som man kan falde i:

• Ikke at dokumentere krav.
• Ikke at prioritere krav.
• Ikke at involverer interessenterne.
• Ikke at have en change proces for kravstillingen.

Konklusion

Bogen er velskrevet, og bogen er ganske relevant i forhold til softwareudvikling. Ligeledes er bogen ganske god i forhold til prisen, og bogen indeholder tilmed en masse ressourcer i form af skabeloner som let kan anvendes i læsernes organisationer, hvis de mangler inspiration til styring af software håndtering.

Kilder

Wiegers, Karl Eugene. Software Requirements Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. Redmond, Wash.: Microsoft Press, 2003.