Under dag 4 i utbildningen i praktisk kravställning fick deltagarna öva på att modellera upp krav på funktionalitet och information för de tjänster som Boverket tillhandahåller till bygglovssökande och behöriga personer på www.boverket.se.
Fyra olika vyer användes där kravmappningen hade genomförts redan under Dag 3.
Kravmappningen är en visuell vy som syftar till att strukturera krav mot funktionsförmågor som i sin tur kopplas till användningsfall.
Det är en stark metod för att se mönster i kraven från användarna och för att identifiera dubbletter eller motsägelser i användarberättelserna.
Förmågeflödesmodellen på nivå 3 skapades utifrån tre givna processer.
Metoden att gå från processer (som är fulla av aktivitet) till verksamhetsfunktioner (som är en logisk gruppering av uppgifter) bygger på att "passivisera" processerna:
Från processnamn med aktivt verb + substantiv bildas passivformen (som rent grammatiskt heter verbalsubstantiv):
- Producera bil --> Bilproduktion
- Fakturera kund --> Kundfakturering
Deltagarna identifierade verksamhetsfunktionerna och de informationsobjekt som ska skapas och som behövs som input.
Genom att frilägga respektive verksamhetsfunktion skapades två beskrivningar på nivå 3. Notera att kravställningen är förenklad då den enbart fokuserar på behovet av behöriga personer för att skapa en bygglovsansökan. Det krävs lite mer, som t ex en nybyggnadskarta, husritningar/byggnadsmodell etc.
Många upplever förmågeflödet på nivå 3 som något grovkalibrigt - vilket är just själva poängen med nivå 3!
Genom att zooma in på en verksamhetsfunktion på nivå 4 är det möjligt att identifiera fler förmågor som man kanske hade missat i dialogen med användarna (användarberättelserna).
När man ställer krav på applikationer är det viktigt att få rätt fokus. Nyckelordet i den logiska applikationsarkitekturen är "borde".
De logiska applikationerna får inte som de fysiska ha namn på verkliga applikationer. De ska ha namn som betecknar typ av funktionalitet. Exempel:
"Microsoft Office" är en fysisk applikation, d v s tillverkad av Microsoft och implementerad i en viss version.
Den logiska applikationen blir "Kontorsprogram".
På samma sätt blir applikationsmodulen "Powerpoint" logiskt en "Presentationsmodul".
Genom att modellera verksamhetsfunktioner kan man identifiera vilka applikationsmoduler som man bör ha.
Samma modellering går att göra på nivå 4. Notera att funktionsförmågan placeras i både verksamehtsfunktionen och den logiska applikationsmodulen.
Med hjälp av förmågeflödet på nivå 4 och kravmodellen som tagits fram (ej redovisad i denna artikel) var det dags att identifiera krav på funktionalitet och information för applikationsgränssnitten (GUI) "Mina sidor" och "Kontakt behöriga personer".
Varje applikationsgränssnitt försågs med två funktionsförmågor, som i sin tur har funktionella krav kopplade till sig (men de behöver inte läggas in här då de finns i EA-repositoryt och i en annan modell).
Även informationsflödet mellan applikationsmoduler och applikationsgränssnitt med krav på information i form av "picknickkorgar" beskrevs:
Det var ett utpumpat gäng modellerare som avslutade dag 4. Bra jobbat!