Bestbrains - kravspecifikationen m? d? - 8 oktober 2012
- 1. Hvorfor kravspecifikationen skal d?. BestBrains 4. oktober 2012 tirsdag den 9. oktober 12
- 2. Klaus Silberbauer Partner, Creative Director Think! Digital tirsdag den 9. oktober 12
- 3. Strategy Tactics Operations tirsdag den 9. oktober 12
- 4. Strategy Tactics Operations tirsdag den 9. oktober 12
- 5. Strategy Tactics Operations } UX mindset tirsdag den 9. oktober 12
- 6. ¡° Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. tirsdag den 9. oktober 12
- 7. ¡° Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. ŒO×Ó SUN TZU, 500 B.C. tirsdag den 9. oktober 12
- 8. tirsdag den 9. oktober 12
- 9. Sor? Kommune tirsdag den 9. oktober 12
- 10. tirsdag den 9. oktober 12
- 11. tirsdag den 9. oktober 12
- 12. tirsdag den 9. oktober 12
- 13. tirsdag den 9. oktober 12
- 14. EPN 24 sep 2012 tirsdag den 9. oktober 12
- 15. Svar p? kravspecifikation ¡°Der m? ikke tages forbehold¡± L?st Delvist l?st Ikke l?st tirsdag den 9. oktober 12
- 16. tirsdag den 9. oktober 12
- 17. tirsdag den 9. oktober 12
- 18. ¡° Kravspecifikationer til web er ofte resultatet af, at en gruppe mennesker uden indsigt i mediet og under tidspres bliver bedt om at finde l?sninger p? problemer, de endnu ikke kender. tirsdag den 9. oktober 12
- 19. Eksempel Form?l: At oprette brevskabeloner, der kan anvendes af XXXXXX i givne XXXXXX-processer. Akt?rer: Redaktionen F?r-tilstand, foruds?tninger: Akt?ren er logget p? systemet Beskrivelse: For akt?ren er oprettelsen af en brevskabelon kendetegnet ved at v?re dialogbaseret, brugervenlig og overskuelig. Akt?ren v?lger at oprette en skabelon.?N?r akt?ren v?lger at oprette en ny skabelon, v?lges i en trinvis dialog, hvilke felter der skal anvendes p? formularen: Indtastningsfelter (input) , Enten-eller felter (radio- buttons) , B?de-og felter (checkboxe) , Rullegardiner (dropdowns), Kommentar-felt (text-area)? tirsdag den 9. oktober 12 Akt?ren har mulighed for at tilf?je et vilk?rligt antal
- 20. Akt?ren er logget p? systemet Eksempel Beskrivelse: For akt?ren er oprettelsen af en brevskabelon kendetegnet ved at v?re dialogbaseret, brugervenlig og overskuelig. Akt?ren v?lger at oprette en skabelon.?N?r akt?ren v?lger at oprette en ny skabelon, v?lges i en trinvis dialog, hvilke felter der skal anvendes p? formularen: Indtastningsfelter (input) , Enten-eller felter (radio- buttons) , B?de-og felter (checkboxe) , Rullegardiner (dropdowns), Kommentar-felt (text-area)? Akt?ren har mulighed for at tilf?je et vilk?rligt antal felter og i en vilk?rlig r?kkef?lge. For hvert felt der tilf?jes, angiver akt?ren overskrift til feltet. ?G?ldende for alle typer af skabeloner er, at akt?ren angiver overskrift og br?dtekst til skabelonen samt udl?bsdato for formularen. ? N?r udl?bsdatoen er overskredet kan skabelonen ikke l?ngere anvendes af slutbrugerne p? XXXXXXX. Skabelonens ops?tning f?lger de fastsatte design retningslinier for XXXXXX, og akt?ren har ikke mulighed for at ?ndre p? denne ops?tning. Efter-tilstand, resultat: tirsdag den 9. oktober 12 Akt?ren har oprettet en brevskabelon uden brug af
- 21. Akt?ren er logget p? systemet Eksempel Beskrivelse: For akt?ren er oprettelsen af en brevskabelon kendetegnet ved at v?re dialogbaseret, brugervenlig og overskuelig. Akt?ren v?lger at oprette en skabelon.?N?r akt?ren v?lger at oprette en ny skabelon, v?lges i en trinvis dialog, hvilke felter der skal anvendes p? formularen: Indtastningsfelter (input) , Enten-eller felter (radio- buttons) , B?de-og felter (checkboxe) , Rullegardiner (dropdowns), Kommentar-felt (text-area)? Akt?ren har mulighed for at tilf?je et vilk?rligt antal felter og i en vilk?rlig r?kkef?lge. For hvert felt der tilf?jes, angiver akt?ren overskrift til feltet. ?G?ldende for alle typer af skabeloner er, at akt?ren angiver overskrift og br?dtekst til skabelonen samt udl?bsdato for formularen. ? N?r udl?bsdatoen er overskredet kan skabelonen ikke l?ngere anvendes af slutbrugerne p? XXXXXXX. Skabelonens ops?tning f?lger de fastsatte design retningslinier for XXXXXX, og akt?ren har ikke mulighed for at ?ndre p? denne ops?tning. Efter-tilstand, resultat: tirsdag den 9. oktober 12 Akt?ren har oprettet en brevskabelon uden brug af
- 22. Eksempel tirsdag den 9. oktober 12
- 23. tirsdag den 9. oktober 12
- 24. Form?let med at bygge en bro er broen i sig selv. En webl?snings m?l er ikke l?sningen i sig selv, men den v?rdi, l?sningen skal skabe. tirsdag den 9. oktober 12
- 25. Reduktion ad absurdam Hvad skal en kravspeci?kation ? Implementering: Hvilke krav er der til projektledelse og gennemf?relse af projektet. Hvilken rolle er det tilsigtet at indeholde? leverand?ren skal have? Hvilke arbejdsgange skal forbedres? Hvordan ser det ud fra brugerens synsvinkel? Hvad er ? Det bedste forsvar mod tilbud af ringe kvalitet er at lave en forbindelsen fra de forretningsm?ssige m?l til kravene? godt organiseret kravspeci?kation, som leverand?rer kan Skal leverand?ren bruge bestemte metoder og v?rkt?jer f?lge. (f.eks. use cases, prototyping, agile, extreme programming, ? I grove tr?k skal en kravspeci?kation indeholde f?lgende usability test). Hvor meget tr?ning er n?dvendig? afsnit: ? Leverand?r kvali?kationer og referencer. ? Opsummering: Hvilket problem skal l?ses, og hvilke behov s?ges tilfredsstillet M?lbare succeskriterier. ? Yderligere information fra leverand?ren: Hvis leverand?ren har relevant, men ikke p?kr?vet information at tilf?je ? Administrativ information: Kontakt data, deadline, formalia, vigtige de?nitioner og afgr?nsning ? Pris: Hvordan skal dette pr?senteres? ? Tekniske krav ? Kontrakt og licensaftale: Alle juridiske detaljer ? Leverand?ren skal kunne forst? det eksisterende IT-landskab, ? Bilag, der indeholder relevant information, s? som netv?rksdiagrammer, projektplaner og forretningskrav. herunder hvilke systemer der skal integreres med. Her n?vnes ogs? krav til oppetid, svartider, back-up, clustering, ? De enkelte punkter i kravspeci?kationen kan med fordel load-balancing, dynamisk/statisk levering markeres med et ¡°K¡± for krav og et ¡°?¡± for ?nske. Kravene er forbeholdt de elementer, som er strengt n?dvendige, mens ?nskerne forventes tilgodeset. Se eksempler p? krav i vores artikel om rimelige forretningskrav. tirsdag den 9. oktober 12
- 26. Beslutninger l?ses tidligt Konventionel kravspec Agile / best practice Man skal (fors?ge) at tage hensyn til Man har fokus p? m?lene og alle scenarier. Typisk uden at visionen - problemer l?ses gennemf?re en egentlig designfase. undervejs. Man skal forudse problemer, der ikke er opst?et endnu og situationer, man ikke har kendskab til. tirsdag den 9. oktober 12
- 27. Beslutninger l?ses tidligt Konventionel kravspec Agile / best practice Designbeslutninger tages uden Alle optioner holdes ?bne til sidste indsigt, og l?ses kontraktligt. ?jeblik. Designbeslutninger tages f?rst n?r indsigten er st?rst. tirsdag den 9. oktober 12
- 28. Vi leverer ¡°til spec¡± Konventionel kravspec Agile / best practice En leverand?r er fristet til at levere M?lene s?ttes l?bende i dialog ¡°til spec¡± og ikke til virkeligheden. mellem kunde og leverand?r. M?lene er realistiske og bliver ¡°Til spec¡± opfylder kravene, men konstant holdt op imod den v?rdi, resultatet kan v?re en skandale. som slutproduktet skal a??de. tirsdag den 9. oktober 12
- 29. ?ndringer bliver sv?re Konventionel kravspec Agile / best practice ?ndringer undervejs kan kr?ve ?ndringer er n?dvendige. change requests og dermed store Processen l?rer os nye ting og vi summer i projektledelse. skal kunne adaptere undervejs. Man vil derfor typisk fors?ge at undg? ?ndringer. tirsdag den 9. oktober 12
- 30. Kunden f?r en ja-siger Konventionel kravspec Agile / best practice Tilbudsfasen g?r nemmest, hvis Vi ved, at resultatet aldrig er som man blot accepterer kravene speci?ceret, for ny viden opn?et (selvom kunden skriver, at man skal undervejs i processen giver os nye udfordre kravspec¡¯en). id¨¦er. Det er fristende at acceptere t?belige krav mod bedre vidende. tirsdag den 9. oktober 12
- 31. Forsimplet syn p? udvikling Konventionel kravspec Agile / best practice Kravpec¡¯en cementerer opfattelsen Drift er udvikling og udvikling er af web- eller IT-udvikling som et drift. projekt med en start, slutning og et klart de?neret produkt. Man skelner typisk mellem udvikling og drift tirsdag den 9. oktober 12
- 32. Kombineret med udbud, ak Konventionel kravspec Agile / best practice ¡°Hvem kan bygge noget ud fra en ¡°Hvem vil indg? i et samarbejde p? d?rlig opskrift, p? mindst tid og til disse vilk?r, hvor begge parter g?r f?rrest penge¡± alt for at skabe v?rdi indenfor givne ?konomiske rammer¡±. tirsdag den 9. oktober 12
- 33. Pris Konventionel kravspec Agile / best practice Et komplekst udbud med stor Kunden og leverand?ren bruger de kravspec kan tage +1.000 timer at +2.000 timer til sammen at skrive og +1.000 timer at besvare. formulere udfordringerne, m?lene og opn? tillid og enighed. Disse penge skal ind - prisen stiger. tirsdag den 9. oktober 12
- 34. Risiko Konventionel kravspec Agile / best practice Risikomaksimerende - projektledere Risikominimerende - product p? overarbejde og jurister stand-by. owners en del af l?sningen, jurister Modstridende interesser parterne i sj?ldent n?dvendige. F?lles mellem. interesser. tirsdag den 9. oktober 12
- 35. Dr?bende interaktionsfejl tirsdag den 9. oktober 12
- 36. Dr?bende interaktionsfejl Misforst?elser af brugerens kontekst Processer underst?ttes Forkert forkert. navngivning. tirsdag den 9. oktober 12
- 37. Dr?bende interaktionsfejl Misforst?elser af brugerens kontekst Processer underst?ttes Forkert forkert. navngivning. Manglende Over??dig funktionalitet funktionalitet Konceptm?ssige fejl tirsdag den 9. oktober 12
- 38. Dr?bende interaktionsfejl Misforst?elser af brugerens Brugervenligheds- m?ssige fejl kontekst Processer Brugerforst?r underst?ttes Forkert ikke systemes forkert. navngivning. bruger?ade Manglende Over??dig funktionalitet funktionalitet Konceptm?ssige fejl tirsdag den 9. oktober 12
- 39. Dr?bende interaktionsfejl Misforst?elser af brugerens Brugervenligheds- m?ssige fejl kontekst Processer Brugerforst?r underst?ttes Forkert ikke systemes forkert. navngivning. bruger?ade Systemet er Manglende Over??dig indforst?et Systemet funktionalitet funktionalitet taler ned til brugeren Konceptm?ssige fejl Diskursm?ssige fejl tirsdag den 9. oktober 12
- 40. ¡°Fail early¡± tirsdag den 9. oktober 12
- 41. ¡°Fail early¡± Kompleksitet / pris / risiko Tid tirsdag den 9. oktober 12
- 42. ¡°Fail early¡± Kompleksitet / pris / risiko Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 43. ¡°Fail early¡± Kompleksitet / pris / risiko Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 44. ¡°Fail early¡± Interaktionsfejl Kompleksitet / pris / risiko ?nt Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 45. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko ?nt acceptable Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 46. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko ?nt acceptable problematiske Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 47. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl Kompleksitet / pris / risiko ?nt acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 48. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl ¡°Amanda¡± Kompleksitet / pris / risiko ?nt acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Tid tirsdag den 9. oktober 12
- 49. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl ¡°Amanda¡± Kompleksitet / pris / risiko ?nt acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Risikominimering Scope down Tid tirsdag den 9. oktober 12
- 50. ¡°Fail early¡± Interaktionsfejl Interaktionsfejl Interaktionsfejl Interaktionsfejl ¡°Amanda¡± Kompleksitet / pris / risiko ?nt acceptable problematiske ekstremt problematiske Sketching Wireframing Prototyping Visual design Development Risikominimering Scope down Tid tirsdag den 9. oktober 12
- 51. Hvad g?r vi s?? tirsdag den 9. oktober 12
- 52. Start med interface design Design Test Indsigt Design Reality Agile Forretning Brand Struktur Interaktion check Dev M?l / KPI Dialog Succeskriterier Visuelt Design Brugere Tech Arkitektur Platform Data/Integration tirsdag den 9. oktober 12
- 53. tirsdag den 9. oktober 12
- 54. IxD / IA ? Projektledelse Testbrugere AD / Design Beslutningstagere tirsdag den 9. oktober 12
- 55. Et nyt paradigme tirsdag den 9. oktober 12
- 56. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. tirsdag den 9. oktober 12
- 57. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Formul¨¦r hvilke m?l den endelige l?sning skal opfylde. Der kan v?re 100 forskellige veje derhen - lyt til leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end man troede. tirsdag den 9. oktober 12
- 58. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Formul¨¦r hvilke m?l den endelige Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end man troede. tirsdag den 9. oktober 12
- 59. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Formul¨¦r hvilke m?l den endelige Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 60. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Sats p? langvarigt samarbejde og tillidsopbygning. Formul¨¦r hvilke m?l den endelige Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 61. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Sats p? langvarigt samarbejde og L?g stor v?gt p? f?lles konceptudvikling. tillidsopbygning. Formul¨¦r hvilke m?l den endelige Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 62. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Kunden: Insister p?, at der Sats p? langvarigt s?ttes et team, ikke bare s?lges samarbejde og timer. L?g stor v?gt p? f?lles konceptudvikling. tillidsopbygning. Formul¨¦r hvilke m?l den endelige Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 63. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg med tal og typisk p?lagt store risiko-bu?ere. Kunden: Insister p?, at der Sats p? langvarigt s?ttes et team, ikke bare s?lges samarbejde og timer. L?g stor v?gt p? f?lles konceptudvikling. tillidsopbygning. Leverand?ren: Insister p? at kunden dedikerer tid og Formul¨¦r hvilke m?l den endelige n?glepersoner, ikke blot Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re kommunikerer pr. skrift. men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 64. Et nyt paradigme V?lg leverand?r p? baggrund af meritter, ikke p? baggrund af et tilbud, som for det meste er ren leg Indse, at ingen spec er med tal og typisk p?lagt store risiko-bu?ere. fuldkommen, at software udvikles over tid og at tillid er Kunden: Insister p?, at der den eneste vej. Sats p? langvarigt s?ttes et team, ikke bare s?lges samarbejde og timer. L?g stor v?gt p? f?lles konceptudvikling. tillidsopbygning. Leverand?ren: Insister p? at kunden dedikerer tid og Formul¨¦r hvilke m?l den endelige n?glepersoner, ikke blot Afs?t ikke et projektbudget, l?sning skal opfylde. Der kan v?re kommunikerer pr. skrift. men et l?bende proces- 100 forskellige veje derhen - lyt til budget. leverand?rens id¨¦er. Det kan typisk g?res nemmere og billigere, end Begge parter: Undg? kompleksitet, man troede. hvor muligt. Selvom man kan s?lge mange timer p? indviklet kode, s? er det sj?ldent risikoen v?rd. tirsdag den 9. oktober 12
- 65. Think! Digital is a Copenhagen based, strategic digital agency, ?rmly rooted in the tradition of user experience design. Digital is business. facebook.com/thinkdigitaldk twitter.com/thinkdigitaldk www.thinkdigital.dk lets@thinkdigital.dk +45 3164 0100 tirsdag den 9. oktober 12