Enkelt och komplicerat kravarbete

Läste just Ken Schwabers definition av enkla respektive komplicerade krav. Det är den bästa beskrivningen av enkla krav som jag stött på…

Om enkla krav:
"It is possible to have simple requirements. A single customer who is the only person who will use the system can spend enough time with the developer that the two can agree exactly what to build. Assuming that this customer dies immediately after imparting his or her requirements, the requirements will remain constant, and there will be no changes, revisions or last minute modifications"

Om komplicerade krav:
"More commonly, there are many stakeholders (those with an interest in the software and how it works) who have different needs and whose needs frequently change, and are difficult to articulate. In most cases these customers only really start to understand what they want when they are provided with someone elses impression of what they want. Theirs are complex requirements, because their requirements are not only ambiguous, but also constantly changing"

Prestandakrav på användargränssnittet

Ramlade på en gammal undersökning om hur lång tid vi människor behöver för att skriva saker på tangentbord, flytta runt musen på skärmen och ta till oss information. Undersökningen gjordes av Card, Moran och Newell och resulterade i vad man kallar för ”keystroke level model”. Som kravansvarig kan den vara bra att känna till när man ska försöka specificera krav på användbarhet och kanske framförallt användargränssnittets prestanda.

T.ex. så skulle man utifrån denna modell definiera följande krav:
När man flyttar markören till ett nytt fält skall det vara möjligt att börja mata in data inom 0.2 sekunder, när man byter skärmbild skall det vara möjligt att börja mata in data inom 1.3 sekunder och presentera resultatet av rapporter får inte dröja mer än 20 sekunder.

Ovanstående krav gör att den genomsnittliga användaren inte kommer att uppleva att han/hon inte behöver vänta in systemet.

Jag har klippt in några data från undersökningen nedan. Informationen har jag hämtat på http://www.pitt.edu/~cmlewis/KSM.pdf.

K – Keystroke (.12 – 1.2 sec; .28 recommended for most users). This operator is pressing a key or button on the keyboard.
- Expert typist (90 wpm): .12 sec
- Average skilled typist (55 wpm): .20 sec
- Average nonsecretarial typist (40 wpm): .28 sec
- Worst typist (unfamiliar with keyboard): 1.2 sec
- The average nonsecretarial typist (.28 sec) is a good design point for characterizing the typical computer user
P – Point with mouse to a target on the display (1.1 sec). This operator represents the action of moving the mouse to point the cursor to a desired place on the screen.
B – Press or release mouse button (.1 sec).
H – Home hands to keyboard or mouse (.4 sec).
M – Mental act of routine thinking or perception (.6 – 1.35 sec; use 1.2 sec).

ModernAnalyst.com – community för kravhanterare

Link: http://ModernAnalyst.com

ModernAnalyst.com är en ganska livskraftig community med mycket bra information relaterad till kravanalys.

Med deras egna ord:
Modern Analyst – Community and resource portal for the Business Analyst and Systems Analyst. ModernAnalyst.com is the premier community and resource portal for business analysts, systems analysts, and other IT professionals involved in business systems analysis.

Find what you need, when you need it. The ModernAnalyst.com community provides Articles, Forums, Templates, Interview Questions, Career Advice, Profiles, a Resource Directory, and much more, to allow you to excel at your work.

From junior analysts to analysis managers, whether you integrate off-the-shelf products, perform systems analysis for custom software development, or re-engineer business processes, ModernAnalyst.com has what you need to take your career to the next level.

Tips för att kickstarta en ”död” modellering

Modellerade användningsfall i förra veckan… Det känns som att det är mer regel än undantag att modelleringen ”dör”. Så hände också nu. Vad det beror på varierar från fall till fall. Det kan vara dålig ventilation i modelleringsrummet, dåligt förberedda deltagare, oengagerade deltagare, trötta deltagare m.m. m.m. Igår tror jag det handlade om dålig ventilation.

Nedan hittar ni i alla fall några beprövade knep för att få liv i modelleringen igen.

  1. Ta en kaffepaus och hämta lite frisk luft
  2. Rita på whiteboarden
  3. Be de övriga deltagarna komma fram till whiteboarden och rita de också
  4. Tänk högt, så att övriga deltagare kan hjälpa dig
  5. Byt infallsvinkel, har ni fastnat på användningsfallen, gå tillbaka till aktörerna, och tvärtom om ni har fastnat på aktörerna.
  6. Konkretisera, för inte abstrakta resonemang om vad saker och ting skulle kunna tänkas heta. Utgå från det konkreta fallet och namnge det. Om ni sedan har två fall som är ganska lika kan ni generalisera genom att flytta ihop lapparna. Det är enklare att göra på det sättet än att försöka föra ett muntligt resonemang om olika fall. Hjärnan (åtminstone min) klarar inte av att hantera för mycket abstrakt information på en gång.
  7. Lyd minsta motståndets lag, fastna inte i diskussioner om namn m.m. Tag ett arbetsnamn (eller två) och gå vidare. Namnen kan ni gå tillbaka till senare
  8. Försök inte själv komma med svaren, släng ut frågor till övriga deltagare
  9. Skriv ned allt på lappar, så att deltagarna ser att modellen växer fram framför deras ögon. Då blir det också enklare att gå tillbaka och ställa kompletterande frågor senare. Dessutom ser deltagarna att deras input betyder något. Var inte rädd för att lägga till mer information än namn på aktörer och användningsfall. Dyker det upp ett alternativflöde så klottrar ni ner en mening om det också på lappen.
  10. Driv med dig själv och var inte rädd för att visa dig osäker. Skratt är kreativitetshöjande! Kundens verksamhet är dessutom komplex och det är naturligt att man inte har alla svaren.
  11. Samla in feedback. Rita två kolumner (t.ex. effektivitet och nytta) på whiteboarden och be folk att sätta en siffra (1-5) i varje innan de hämtar kaffe. 1=Väldigt ineffektivt arbete, vi kommer ingenstans resp 5=väldigt effektivt samt 1=meningslöst, vi kommer inte att ha någon användning för resultatet om vi fortsätter så här resp. 5=otroligt nyttigt, fortsätt så här. Efter rasten kan ni ha en diskussion om hur ni ska fortsätta modelleringen på bästa sätt.

Lycka till!

Alternativ- och felflöden i ett användningsfall

Jag tycker om att definiera felflöden i ett användningsfall. Alla mallar jag sett för användningsfallsbeskrivningar har rubrikerna huvudflöde och alternativflöden (eller förlopp), att de också har rubriken felflöde (på engelska, exceptional flows) är inte lika vanligt, även om det förekommer.

Fördelen med felflöden är att det är finns en enkel och intuitiv uppdelning mellan möjligheter som systemet erbjuder och fel som inte får/ska inträffa. Att definiera ett flöde som det ena eller det andra ger tydliga signaler till utvecklarna om att vara på sin vakt när vi pratar felflöden. Dessa måste nämligen hanteras innan vi kan gå i produktion. Alternativflöden däremot måste vi inte alltid implementera innan produktionssättning eftersom systemet fungerar även utan dessa. Man kanske inte drar full nytta av systemet men det går i alla fall att använda. Det är också enkelt att arbeta på detta sätt med beställaren. Först frågar man vad man vill erbjuda användaren och sedan vad som inte får inträffa.

Exempel på alternativflöde: Rabatter till vip-kunder.
Ovanstående alternativflöde implementeras inte i den första releasen utan levereras senare. Dvs systemet kan i dagsläget inte erbjuda rabatter till vip-kunder.

Nackdelen med felflöden är att den till en början så intuitiva uppdelningen i fel och alternativ blir allt annat än logisk och konsekvent när man börjar skärskåda den. Är det t.ex. ett felflöde när produkten kunden ska köpa är tillfälligt slut? Eller när han/hon anger fel pin-kod? Risken är att man hamnar i en oändlig och teoretisk diskussion kring vad som är ett fel och vad som är ett alternativ.

Trots detta är mitt råd ändå att försöka tänka i termer av felflöden och alternativflöden, men resulterar det i många diskussioner och stor förvirring i projektgruppen. Sluta genast upp med det…

Domain driven design, or no domain?

Link: http://domaindrivendesign.org/resources/what_is_ddd

Eric Evans har under de senaste 5 åren populariserat domänmodellering med sitt koncept – domain driven design. Som så många andra har han tagit angreppssätt som till stora delar är vedertagna, etablerade och beprövade, blandat ihop och döpt om dessa och sedan lanserat dem på nytt.

Fördelen med detta är att han lyckats skapa ett intresse för en enormt kraftfull kravteknik; informationsmodellering. En väl genomförd informationsmodellering ger nämligen otroligt tydliga strukturella krav på systemet och är dessutom ett väldigt bra underlag för design.

Det som stör mig lite är att man på svenska prompt måste kalla det för domänmodellering (domain modeling). Detta eftersom ordet domän inte säger något. Med risk för att visa min okunskap så tolkar jag ordet som att det betyder område. Några exempel;

  • problemdomänen = problemområdet
  • verksamhetsdomänen = verksamhetsområdet
  • systemdomänen = systemet och dess tillhörande områden
  • kunskapsdomänen = ung. det jag känner till om saken

Om man då pratar om en domänmodell, vad menar man egentligen? En modell som inte beskriver ett område finns väl inte. Eller gör det?

Mitt råd är att istället för domän prata om vad ni modellerar, datamodeller, informationsmodeller, begreppsmodeller, databasmodeller, verksamhetsmodeller, systemmodeller m.m. Att modellen tillhör en domän är så självklart att det förvirrar mer än förklarar om man säger det.

Missförstå mig rätt bara, jag är en stor fan av domain driven design, rätt applicerat hjälper det oss att bygga bättre, mer robusta och förändringsbara system.

Användningsfall – En agil kravteknik

På senare tid har jag allt oftare hört att användningsfall är hopplöst ute, en omodern kravteknik. Att arbeta med användningsfall är vattenfallorienterat och inte agilt. User stories däremot, det är minsann en agil kravteknik. Om jag får säga min mening kan agil systemutveckling, krav och användningsfall missförstås mer än så!

Vad som avgör om man arbetar agilt med kraven eller inte, är inte vilken form man dokumenterar kraven på (användningsfallsbeskrivningar och user stories är ju egentligen bara två olika sätt att dokumentera samma krav på). Det är istället syftet med dokumentet som avgör om man är agil eller inte. Skriver man krav för att som verksamhetsrepresentant slippa prata med utvecklarna, då arbetar man inte agilt.

Gör man däremot beskrivningen för att ha en utgångspunkt eller startpunkt för diskussion med utvecklarna. Då arbetar man agilt. Om man beskriver kraven som användningsfall, som user stories eller som traditionella kravlistor har inget med saken att göra.

Varför älskar utvecklare include och extend?

Grrr, include och extend tillför i mina ögon otroligt lite i ett användningsfallsdiagram. För utvecklare verkar det vara guds gåva till metodfascisten! Jag vet att det är bra med en semantiskt korrekt och konsekvent modell, men det är faktiskt så att man inte behöver visa allt i alla diagram!

Envisas man med att hela tiden vilja lägga till include och extend i användningsfallsdiagrammet är min erfarenhet att det ofta beror på att man väldigt gärna vill läsa in ett flöde mellan användningsfallen. Det är inte meningen!!!

SLATES – 6 grundläggande krav på ”framtidens” intranät

Våren 2006 sammanfattade Andrew P Macafee de grundläggande egenskaperna hos ”framtidens” intranät (enterprise 2.0) i en artikel i MIT Sloan Management Review. Läs hela artikeln på http://www.wikiservice.at/upload/ChristopheDucamp/McAfeeEntrepriseDeux.pdf

Akronymen SLATES står för:
S – Search
L – Links
A – Authoring
T – Tags
E – Extensions
S – Signals

Dvs för att fungera och skapa ett mervärde i företaget måste intranätet vara lätt att söka på (search), lätt att länka samman information på (links), lätt för användarna att bidra med egna texter på (authoring), informationen bör dessutom vara kategoriserad, och helst bli kategoriserad av användarna själva (tags). Målet är en ”folksonomi” istället för en taxonomi. Vidare skall systemet analysera användarens beteende och komma med rekommendationer (extensions). Tyckte du om det där? Då tycker du säkert om det här också! Ungefär så som Amazon gör. Slutligen bör systemet tala om för användaren när det finns ny information (signals), t.ex. via rss-flöden.