Problemet. Beställarkompetens och kravhantering. Användbarhetsboom Internet som motor. Beställarproblemet. Användarnytta = verksamhetsnytta.

Storlek: px

Starta visningen från sidan:

Download "Problemet. Beställarkompetens och kravhantering. Användbarhetsboom Internet som motor. Beställarproblemet. Användarnytta = verksamhetsnytta."

Gerd Lundgren
för 7 år sedan
Visningar:

1 Problemet Beställarkompetens och kravhantering Trots mycket kunskaper inom människadatorinteraktion så är användare missnöjda med systemen, eller klarar helt enkelt inte av att göra det de önskar eller är ålagda. Henrik Artman IPLab, KTH Beställarproblemet Vad behöver/vill man uppnå? Vad är man beredd att betala för? Hur formulerar man sina önskemål? Hur försäkrar man sig om att man får vad man önskar? Användbarhetsboom Internet som motor Internet ger användare valmöjlighet Internet har inga möjligheter till manualer Otåliga användare Motivationen att lära system är lägre Fokus på underhållning och e-handel Användbarhet lågt ner i prioriteringsordningen Beställare sällan användare Användarnytta = verksamhetsnytta Användaren är den slutgiltiga kvalitetssäkringen Användarens merarbete pga system Användbarhet centralt för hur verksamheten ska utvecklas Kvalitet ISO Alla sammantagna egenskaper hos ett objekt eller en företeelse som ger dess förmåga att tillfredställa uttalade och underförstådda behov Förträfflighet Överensstämmelse mot specifikation Värde Överträffa förväntningar Mätbar lämplighet 1

2 Användbarhet handlar om kvalitet Ändamålskvalitet Uppnår syfte, effektivitet, lärbarhet, kostnadseffektiv Funktionskvalitet Behov, enkelhet, korrekthet, tillförlitlighet Konstruktionskvalitet Genomtänkt It-arkitektur, prestanda, underhåll, återanvändbarhet, integrering Upplevelsekvaliteter Användarvänlighet, integritet, identifikation Argument och bakgrund Argument för ett krav / ståndpunkt Senaste teknik vs. tillgänglighet Snyggt vs. snabbt Ekonomiskt vs. användarnytta Uppmärksamhet vs. produktivitet Interaktion vs. form Användbarhetskrav - beställarfokus Användbart en självklarhet enkelhet och pedagogiskt om man inte beställer användbarhet så får man inte användbarhet Konsekvensen blir att man överlåter användbarhet till leverantören risken är då att man får acceptanstest och höga kostnader för ombyggnad eller att man leverantören ställer krav de kan hantera Användbarhet estetisering Användbarhet ett gränssnittproblem ytan Verksamhetsproblem produktivitet Användarproblem tillfredställelse Dataflödes överlämningsbarhet Infrastruktur - stabilitet Integrerad kravhantering Organisation Affärslogik Databas Krav Grafisk design Varumärkeshantering Användarnytta Traditionell beställarprocess Ser problem gör verksamhetsanalys Ledning beslutar om projektstart Projektledare intervjuar, specificerar dataflöden och ställer offertförfrågning Utvärdering och beslut Förstudie utvärdera leverantör Remiss genom offert till andra leverantörer Acceptans och viss revidering Utveckling och leverans 2

3 Beställarkompetens Planera Kommunicera Övervaka och leda Utvärdera från aktivitetsnivå Vara medveten om unik verksamhetsexpertis Vara medveten om tolkningsarbetet Färdighet och kunnande Verksamhetskunnande domänkunskap Organisations förståelse mål Aktivitetsförståelse användarens situation Designkunskap Teknikkunskap Utvärderingskunnande Kontraktskunskap Arkitektens roll Att förstå och specificera användarens behov och intressen utifrån flera olika perspektiv användning, estetik och konstruktion Oberoende av implementation Olika roller i olika länder Kan stödja sig på fastställda normer Nivåer av krav Strategisk förändring och utveckling Taktisk effektivitet Operativ anpassning Förändringsbenägenhet Förändringskurva Kostnad Analysenheter Organisation verksamhetsförflyttning Aktivitetsnivå användaraktivitet Dataflödesnivå informationsflöden Möjlighet Tid 3

4 Z-kurvan Ledning Problem Analys Mognad Medarbetare Problem Analys Mognad Beslut Användbarhet mer än produktegenskaper Process Dialog mellan beställare och producent Dialog mellan beställare och användare Dialog mellan användare och producent Dialog mellan olika producentkompetenser Produkt Egenskaper för enkelhet och nytta Användare Lärbarhet Motivation Utvärdera leverantör Perspektiv på beställare Arbetsmetoder för användbarhet Perspektiv på användbarhet Samordning av kompetenser Krav på beställarorganisation Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av detta fick våra konsulter göra. Kravhantering - leverantör Kravspecifikation Krav som styrning Fokusering och gemenskap; vilken precision? Samarbetsformer Hur förhåller sig olika krav? Hur finna en medelväg vid motstridiga krav? Hantering och uppföljning Hur kan krav dokumenteras och uppföljas? Relationer som påverkar? Ett sätt att sätta sig in i verksamheten Kan någon annan än leverantören läsa kravspecifikation? Är de överlämningsbara? Bör kravspecifikation skapas av beställaren? 4

5 Kravspecifikation nivå och syfte Hur något ska utföras? Vad som systemet ska utföra? Vad som ska stödjas? Hur systemutvecklingen ska bedrivas? Hur kan man integrera kravhantering? Användbarhet vs. Estetisk design Visuell navigation eller estetik Användbarhet vs. Affärsmodell Användare förståelse eller kostnader Användbarhet vs. Marknadskommunikation Tillfredställelse eller Uppmärksamhet Användbarhet vs. Teknik Användning eller Sofistikerad teknik Kravhantering Jämkning mellan olika perspektiv System för att man ska uppmärksamma förändring som påverkar andra Motstridiga krav Skapande av profil resp. lösning av problem Kravhantering specifikt exempel Låt säga att vi ska bygga ett administrativt system En av de vanligaste uppgifterna är att användaren ska bestämma olika parametrar Ett krav skulle uttryckas som att det ska vara enkelt att bestämma och lägga in uppgifter i systemet Kravet kan dock förvaltas olika i olika delar av kravspecifikationen Typ 1 det ska vara enkelt för användare av kategori U att bestämma parametrar av typen X i situation Y Detta är det verkliga målet/syftet och fokuserar interaktionen mellan människa och datorsystem Typ 2. Default värden ska ges för värden av typ X. Värden av typ X ska tydligt markeras. Användargränssnittet ska överensstämma med UI-standarder enligt dokument Y Något längre från huvudsyftet, fokuserar produkten Om vi designar enligt dokument Y blir det enkelt att använda 5

6 Typ 3. GUI-utvärdering ska göras varje vecka Fokuserar processen, samt låter en utvärdering snarare än förstudie och analys styra utvecklingen. Typ 4 Utvecklingsgruppen ska ha följande kompetens: GUI design, Human Factors, Java programmering Detta är långt från det huvudsakliga målet och handlar om man har rätt kompetens kommer man få en bra produkt. Design för flera - slutsats Det finns sällan bara en användare Det finns ofta flera användarroller Användare kan mycket väl vara administratören av systemet Användaren kan vara vidareutvecklare Sekundäranvändare är ofta viktiga utifrån verksamhetsperspektiv 6

Relevanta dokument

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman Design och krav Henrik Artman >>Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av