Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning av krav. Grundläggande testprocess från utvecklarens till beställarens tester. Hur man kan uppnå effektiv kommunikation inom ett systemutvecklingsprojekt och med leverantörer/externa parter Kravhanteringsmetoder Intervjumetoden och V-modellen Krav man ofta missar Viktiga fält i kravspecifikationer

Kravhantering - Faktorer som påverkar systemets kvalitet

Kravhantering

Sammanfa/ning

Det om kraven det nu vidare till Test Följande slides visar hur jag redan under Kravhanteringen tänker på Testfasen för att få en så bra bild om uppdraget som möjligt.

Testprocessen

Testprocessen och Kommunikation

Testprocessen

Test och kvalitetssäkring

Sammanfa/ning

Vilka hjälpmedel använder jag? Hur skall jag lyckas med att ställa rätt krav? Jag har på följande slides försökt ta med några tips som jag använder mig av.

Lyckas med intervjuer i kravhanteringsarbetet Många som arbetar med kravhantering använder intervjuer för att samla in krav. Det är en teknik som ger väldigt mycket samtidigt som den är enkel att lära sig, En nackdel med intervjuer är att det är lätt att missa viktiga områden som man bör ställa frågor om På följande slides har jag försökt kartlägga bakgrunden, problemet, användarna och såväl funktionella som icke-funktionella krav.

Fakta om intressenten Namn Företag/avdelning Titel/arbetsuppgifter Huvudsakligt ansvarsområde Vilka är dina uppgifter Åt vem utför du dessa uppgifter Vilka problem hindrar dig från att utföra dina uppgifter

Identifiera problem Vilka problem upplever du idag där du saknar fungerande lösningar? Varför finns detta problem? Hur löser du problemet idag? Hur skulle du vilja lösa problemet? Ställ följfrågan upplever du några andra problem så länge den intervjuade upplever fler problem

Användarmiljön Vilka är användarna Vilken utbildningsnivå har användarna Vilken datorvana har användarna Är användarna vana vid den här typen av ITsystem Vilka tekniska plattformar används idag Vilka planer finns för framtida plattformar Vilka andra IT-system används idag som systemet behöver ha kopplingar till Vad har du för förväntningar på systemets användarbarhet Vad har du för förväntningar på utbildningsbehov för det kommande systemet Vilket slags dokumentation förväntar du dig

Sammanfa/ning av problemet Jag har uppfattat att du upplever följande problem/behov (Använd egna ord) Är detta de problem du upplever med den nuvarande lösningen? Upplever du några ytterligare problem? I så fall vilka?

Kravhanterarens komple/ering av intressentens problem Exempel / Upplever du att XX är ett problem för dig idag? För varje problem ställer du följande följdfrågor: Är detta ett problem? Varför finns det här problemet? Hur löser du problemet idag? Vad tycker du skulle vara en optimal lösning på problemet? Hur stort är det här problemet i förhållande till de problem du nämnt tidigare?

Identifiera lösning på problemen Om det är möjligt kan du här föreslå lösningar på problemen. Hur skulle du se på en lösning som skulle kunna se ut så här?... Hur skulle du prioritera de föreslagna lösningarna?

Identifiera icke- funktionella krav Vilka förväntningar har du på systemets tillgänglighet? Vilka förväntningar har du på systemets prestanda? Vem kommer att sköta support för systemet? Vad finns det för krav på support? Vad finns det för krav på underhåll/förvaltning av systemet? Vad finns det för krav på säkerhet? Vad finns det för krav på installation och konfiguration? Hur kommer systemet att distrubieras? Finns det några legala/regelkrav krav som måste uppfyllas?

Avslutning Finns det några andra frågor som jag borde ta upp? Får jag ta kontakt med dig igen om jag behöver ställa några följdfrågor? Kan du tänka dig delta i en granskning av kraven?

Sammanfa/ning av intervjun Summera de tre-fyra högst prioriterade problemen för den här intressenten.

Krav man ofta missar Det är svårt att få med alla krav. Beställare och användare vet sällan till fullo vad de behöver, behoven ändras ofta under utvecklingstiden och det är svårt att beskriva kraven så att det finns så få tolkningsmöjligheter som möjligt. Även om alla system är komplexa finns det några krav som nästan alltid behöver ställas, men som är lätta att glömma bort.

Krav man ofta missar - Funktionalitet Du kommer att behöva ta ner applikationen för både akuta och planerade avbrott. Hur skall det göras? Det bör finnas ett enkelt val för systemadministratören för att minimera felkällor. Vilken information skall visas för användaren när systemet är nere?

Krav man ofta missar - Behörigheter Vem skall se vad? Vad händer när en användare försöker använda funktioner som denna inte har behörighet till? Ska funktioner som man inte har behörighet till vara synliga eller döljas?

Krav man ofta missar - Felmeddelanden Var och hur skall felmeddelandena visas? En ruta skall det stå [odbc error] eller skall det vara en förklaring som man förstår? Skall det gå att exportera till Exel? För en sammanställning?

Krav man ofta missar - Larm När ett fel inträffas skall det loggas och skickas ett mail till någon ansvarig?

Krav man ofta missar - Lista alla ställen i systemet som ändringen berör Ta fram en Req Matrix (en enkel exel fil) så att alla krav blir lätta att följa upp

Krav man ofta missar - Undantag Finns det något undantag från normal hantering?

Krav man ofta missar - Ändringar Vilka ändringar är troliga efter driftsättning? Småfel i texter..

Krav man ofta missar - Övrigt Skall det gå att logga systemet? Vad händer vid överbelastning? Ska transaktioner ångras? Ska felmeddelande visas? Ska sytemet stängas av automatiskt? Påverkar ändringen datavolymer? Påverkar ändringen teknik? (ny server?)

Viktiga fält i kravspecifikationer Rubrik En kort beskrivning av kravet. Bör tydligt visa vad kravet handlar om, utan att läsaren ska behöva läsa hela kravet för att förstå vad det handlar om. Exempel: Möjlighet att spara kund, Avisering via e-post. Kravets rubrik är ofta det som syns i olika listor och sammanställningar när ett verktyg för kravhantering används. Om kraven samlas i ett Word-dokument är rubriken ofta det som syns i innehållsförteckningen. Rubriken är ofta några få ord, upp till någon mening lång.

Viktiga fält i kravspecifikationer Beskrivning Fullständig beskrivning av kravet, ofta flera rader som beskriver vem som är tänkt att använda funktionen. Beskrivningen är olika detaljerad beroende på vilken fas kravet befinner sig i. I början av kravformuleringsarbetet är kraven på en övergripande nivå som t ex Användare med säljarbehörighet ska ha möjlighet att spara, ändra och ta bort kunder. När kraven bearbetas, tillkommer fler detaljer och en beskrivning kan då innehålla tekniska detaljer för implementation såsom vilka tabeller som används i databasen och vilka komponenter

Viktiga fält i kravspecifikationer Identitet/ID Unik identitet som gör att det inte går att sammanblanda kravet med andra krav. Identitet är ofta ett löpnummer, där kraven numreras från 1 och uppåt, men det kan också vara en kombination av inledande bokstav och därefter siffror, t ex K10 för det första kravet inom kundmodulen. Ett ID-nummer får bara förekomma en gång, det får alltså inte finnas flera krav som har samma ID.

Viktiga fält i kravspecifikationer Ändringslogg Varje gång ett krav ändras bör datum och orsak till ändringen noteras i kravet. Vi rekommenderar inte att endast dokumentera en sammanställning av ändringarna i dokumentets historik. Namnet på den som ansvarar för ändringen bör också framgå.

kravspecifikationer Källa Vem kommer kravet från, t ex namnet på en kund eller den person inom organisationen som är upphov till att kravet existerar. Motivering En förklaring till varför kravet finns med. Detta saknas ofta i kravspecifikationer som vi möter i vårt arbete som konsulter. Varför finns kravet? Vad ska företaget tjäna på att införa ändringen? Status Status visar vad som händer med kravet för tillfället. Exempel på status är föreslaget, godkänt, under utveckling, under testning, implementerat och avvecklat. Det kan även gå att ange att kravet är ett kommande krav som inte är aktuellt för den nuvarande versionen men kommer att bli aktuellt senare. Detta minskar risken att utvecklarna målar in sig i ett hörn som gör att stora delar av systemet måste byggas om till kommande version. Om ett kommande krav är enkelt att implementera, kan utvecklarna ge feedback om att kravet kan införas redan nu.

Viktiga fält i kravspecifikationer Prioritet Kravets prioritet, exempelvis baserat på en skala som hög, medel, låg, 1-5 eller liknande. Prioriteten bör baseras både på värde för användarna (eller kunderna) och utvecklingskostnad. Länkar Referenser till andra dokument av intresse för att förstå kravet. Kan även vara en webbsida, exempelvis en hänvisning till en standard eller till en konkurrents produkt. Beroenden Relationer med andra krav. Ett krav är normalt beroende av andra krav. Systemversion I vilken version av det kommande systemet kravet planeras införas. Kommentarer Övrig information som kan vara av intresse.

Viktiga fält i kravspecifikationer Utöver dessa fält kan det vara lämpligt att ha information om granskning i kravet. Informationen kan vara vem som ansvarar för granskning och information om kravet är granskat eller ej. Det är också vanligt att bifoga filer, exempelvis skärmdumpar, utdrag ur användningsfallsmodeller etc. När kraven detaljeras kan de kompletteras med information om fältlängder, obligatoriska fält, tabeller i databasen och komponenter. Den mesta av informationen som bör finnas för varje krav går att upprätthålla med hjälp av enkla verktyg som Word och Excel. Nackdelen med verktyg som Word och Excel är att de saknar specialiserade funktioner för kravhantering och koppling till testfall och

Tack En ppt presentation av Stephen Barkár