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 detta fick våra konsulter göra. >> Leverantörens projektledare för stort statlig projekt (Dagens nyheter) Design Definition enkelt Det ska vara möjligt att formgiva, utpekande, märka design is the successive application of constraints until only a unique product is left Norman, s158 Facilitate and support the decision-makers ability to take appropriate actions dependent on conceived situation [Persson, M.] att skapa handlingsutrymme för människors handlingar genom någon form av artefakt Skillnad på oövertänkt konsekvens 1
Gränssnittutfomning Naturlighet begrepp, procedur Konsekvent samma utseende för liknande funktionalitet Relevans information ska vara relevant Stödjande ge stöd för navigation Flexibelt ej låsa användaren i en specifik funktion, skapa flyktvägar 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 Interaktionsstilar Fråge-svar begära ett svar från användaren Menu erbjuda möjligheter, organisation viktig Formulär viktigt att det kopplat till extern blankett om finnes, annars till en konventionell ordning Kommando lägger stor vikt på minnet Traditionell systemutvecklingsmodell 2
Vad är ett krav? >>Vi gör upp en plan så har vi något att ändra i.>> the purpose of a requirement is to reproduce in the mind of the reader the intellectual content which was in the mind of the write [Harwell et al. 2000] H. Söderström, journalist 1) A condition or capability needed by a user to solve or achieve an objective 2) A condition or capability that must be met or possessed to satisfy a contract, standard specification or other formally imposed deocument 3) A documented representation of a conditionor capability as in 1 or 2 [IEEE 830-1998] Requirement engineering Syftar till att skapa en kravspecifikation som: Är otvetydig Är komplett Är korrekt Är koncis Är designoberoende Är spårbar Är verifierbar Inte innehåller konflikter Inte är redundant Aktiviteter Elicitering Analys och förhandling Dokumentering Validering 3
Usability engineering och socio-teknisk design Användarcentrerad systemutveckling Design av system vs. Design av arbetsmiljö Problemlösning utifrån givna premisser vs. Att undersöka premisserna Del-helhet vs. Helhet-del Top-down vs. Bottom-up Vad är användarcentrering? Tidig fokusering på användare Empiriska mätningar Iterativ design Integrerad design Kravkategorier Normala/förväntade/sensationella Funktionella vad systemet skall kunna göra Icke funktionella med vilken kvalitet: prestanda, säkerhet, tillförlitlighet, användbarhet Kostnadskrav resursberoende Randvillkor leveransvillkor, lagar, processkrav 4
Kravegenskaper Alla krav är verifierbara i sin implementation Krav återspeglar någons värderingar och förväntningar Ett krav har oftast ett eller fler outtalade eller uttalade krav som beskriver situationen lika väl Alla krav står i konflikt m a p resurser Krav är dynamiska med omvärlden Kvalitativa krav Dålig kvantifiering är bättre än ingen man kan åtminstone förbättra systematiskt Kvalitativa krav måste brytas ner i flera nivåer Kvantifiering av: Hur väl systemet svarar mot behoven Hur effektivt systemet upplevs vara Hur lätt systemet är att lära Hur snabbt, säkert, tilltalande systemet är Kvantitativa krav Baserat på tid, antal, andel Tid för att lösa ett problem Tid spenderad på hjälp Antal fel som användare gör Tid för att nå viss effektivitet Etc. Angreppssätt och antaganden 1) Interaktion det ska vara enkelt att registrera 2) Produktegenskap använd ej listbox för lista med mer än 25 objekt 3) Process gör GUI-utvärdering en gång i veckan 4) Kompetens teamet ska ha användbarhetsdesigner Vilka antaganden finns bakom? 5
Definiera Kontext för användning Användartyper Användningsfall Användare ska anse Felhantering Snyggt, ganska mycket Gränsvärden rimliga antagande Jämförelse med nuvarande situation Prototyping Avgöra kvalitet Prova funktionalitet Besluta om krav Hitta svagheter Testa prestanda och utseende Prova sekvenser Grafisk kommunikation Finna problem/svårigheter tidigt i projekt! Vad kan man designa med? Pappersprototyper löjligt? Snygga system förföriska Klara system hämmar användaren Klara system dyra att förändra Fördelar med papper Snabbt, PhotoShop slukar tid Ser inte klart ut Rätt fokus, ingen klagar på detaljer Lätt att ändra och dokumentera under körning Mer dynamiskt än många tror 6