Tentafrågor Grupp C. Fråga 1

Relevanta dokument
Förslag till tentamensuppgifter

Eventuella felaktiga svar kanselerar motsvarande mängd rätta svar

Fråga 1 Skriv in vilken kravnivå kravet tillhör i rutan under varje krav.

Frågor och svar till tentamen i Kravhantering

Skriftlig tentamen den 25 oktober 2014 Kravhantering, ETS672, 7,5 hp

Problem 1-1,5p Två av följande metoder för kravspecifikation är ej lämpade att använda vid ett COTSprojekt,

Inlämning 1 - Tentafrågor. Projektgrupp A

Skriftlig tentamen den 16 januari 2015 Kravhantering, ETS672, 7,5 hp

Fråga 1. A) Domain-requirement analysis B) Questionaires C) Focus groups D) Design workshop C) Stakeholder analysis. Svar: C, D

Rätt svar och poängsättning: 0,5p per rätt svar, max 2,5p A. 2 B. 5 C. 3 D. 6 E. 4

Kurs: ETS 170 Kravhantering. Tentauppgifter. Grupp G Christian Andersson Jacob Gradén Björn Nilsson. Lund,

Skriv namn på varje inlämnat papper!

Tentamensproblem A Grupp H

1) Kravhantering varför? (1.5p)

Tentafrågor 1. Grupp. B

Skriftlig tentamen den 21 oktober 2008 Kravhantering, ETS672, 7,5 hp

Enligt IEEE Std har en bra kravspecifikation en mängd fordringar att uppfylla. Kravspecifikationen skall vara;

produkters egenskaper och innehåll

Rätt ifylld bokstav ger 0.5 poäng och fel ifylld bokstav ger 0.5 poäng i avdrag. Rätt svar: Alternativ A, C, D, A, C uppifrån.

Varje rätt svar ger 0.5 poäng. (max 3p)

Frågor och svar till tentamen i Kravhantering. Del 2. Kravhantering (ETS170), LTH Grupp B

Inlämning 2 - Tentafrågor. Projektgrupp A 1 december 2010

Anledning: Generellt så undviker QUPER att göra fullständiga förutsägelser för relationerna mellan ett systems fördelar, kostnad och kvalitet.

För varje par av påstående/anledning svara med ett av följande alternativ (½ p per rätt svar):

Skriv namn på varje inlämnat papper!

Design för användbarhet

Inlämning 2 - Förslag till tentamensfrågor i Kravhantering, Grupp A. Kompletterar de kursavsnitt som inte täcktes av förra inlämningen.

Skriv namn på varje inlämnat papper!

Kravhantering rep. ETS672. Engineer ANONYMA&TENTOR& & GLÖM&INTE&ANMÄLA&ER!& Olika sammanhang och projekttyper

Kravhantering (ETS170) Tentamensproblem 1. Grupp F 20 november 2013

Skriv namn på varje inlämnat papper!

Fråga 2 (3p): Läs påstående och anledning och välj det alternativ som passar bäst.

LARS. Ett e-bokningssystem för skoldatorer.

Innehåll. Kravhantering. Kravhantering TDDD06 Introduktion till kravhantering. Vad är kravhantering?

Föreläsning 3: Elicitering, Kvalitetskrav

Exercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15

Welcome to ETSN15 Requirements Engineering (Kravhantering)

Prototypningsverktyg. A Human-Centered Design Process (ISO , 2010) Mattias Institutionen för datavetenskap

Kravprocessen som. Project Challenge Factors ETS672. Engineer. Lärandeprocess Underrättelseverksamhet Beslutsprocess

Chaos om datorprojekt..

Validering av krav. Agile utveckling. Christin Lindholm. ETS672 Requirements Engineering L6: Agile Prioritisation. Anpassa kravarbetet till projektet

* Rätt svar A. * Motivering De flesta hushållsmaskiner har en på- och avstäningsknapp och inte endast en av-knapp.

Mobiltelefoner, datorer, läsplattor och andra kommunikationsmedel får inte användas.

Inlämning 2 - Tentamensfrågor

Att fastställa krav. Annakarin Nyberg

Kravhantering IV2032. Kursintroduktion Föreläsning 1: Introduktion till kravhantering

Projektuppgift i Användarcentrerad Systemdesign, ht 04

Exercise 1b: Requirements evaluation

Föreläsning 11, Planera utvärdering. Att planera utvärdering. Vetenskapliga experiment. Kapitel i kursboken

LOGISTIKSYSTEM FÖR SNABBA HJULET AB UTVECKLINGSPROCESS BASERAD PÅ DR. DEBORAH J. MAYHEW S THE USABILITY ENGINEERING LIFECYCLE

Föreläsning 3 Användare, uppgift och omgivning. Kapitel 3-4 i Stone et al.

FTEA12:4 Vetenskapsteori. Observation och experiment

Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning

Agila Metoder. Nils Ehrenberg

Föreläsning 12 Inspektionsmetoder. Rogers et al. Kapitel 15

Föreläsning 11, Mer utvärdering

Detta har hänt... Agenda. Kursinformation. Kursinformation

Kurser och seminarier från AddQ Consulting

Quality-Driven Process for Requirements Elicitation: The Case of Architecture Driving Requirements

Fö 2: Designprocessen. Projektet. Design är... Forts. projektet

CUSTOMER VALUE PROPOSITION ð

Design för användbarhet Användarcentrerad utvecklingsprocess

Fältstudier och analys

Projektarbetet 100p L I T E O M I N T E R V J U E R L I T E O M S K R I V A N D E T A V A R B E T E T S A M T L I T E F O R M A L I A

Mjukvarudesign. Designprocessen. Teknisk design. Konceptuell design

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Agenda. Inledning, teoretiska metoder Hierarkisk uppgiftsanalys, HTA Cognitive walkthrough CW Heuristisk evaluering

Rapport av genomförd enkät till företag i Kronobergs och Kalmar län med anledning av konjunkturläget.

Arbetsrapport CEQ, ETS170

Vad vi pratade om förra gången. Fast med andra ord

Detta har hänt... Föreläsning 2: Projektplanering & granskning. Pratat och provat kravhantering. Bildat projektgrupper :-) Skaffat litteratur?

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT

Exercise 1b: Requirements evaluation

" «Observable» DataGenerator" betyder att klassen DataGenerator ärver från den abstrakta klassen Observable.

Prototypning. Filmtajm. Prototypens roll: Evolutionär eller kasta bort. Dagens föreläsning. Detaljgrad. Detaljerad i vilket avseende?

SCRUM och mycket mer

Process- och metodreflektion Grupp 5

Utveckling av en kravspecifikation för ett incidentrapporteringssystem

E Both the proposition and the reason are false.

Studiestrategier för dig som är visuell

Användarcentrerad systemdesign

Validering av krav. Agile utveckling. Christin Lindholm. ETSF30 Requirements Engineering L6: Agile Prioritisation. Anpassa kravarbetet till projektet

Nätkurs Design & konstruktion av användargränssnitt 1MD113 Sid 1 (5) Lektion 11 Användare, uppgifter och krav del

Objektorientering. Grunderna i OO

Användarcentrerad Systemutveckling

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys

Föreläsning 2: Projekt, Kravhantering, Dokumentgranskning

Kravhantering med prototyp

RUP är en omfattande process, ett processramverk. RUP bör införas stegvis. RUP måste anpassas. till organisationen till projektet

ETSN15 Kravhantering

Arbetsrapport CEQ, ETS170

Detta har hänt... Kursinformation. Agenda. Kursinformation

Agenda. Projektbeskrivning avsnitt 8: Acceptanstest - MS4 i korthet. Kursinformation

Design och Prototyping

Agenda. Föreläsning 6: Utvärdering och om tentamen. Kursinformation

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT

Lecture 1: Sign-up, Introduction

Webprogrammering och databaser. Konceptuell datamodellering med ER-modellen

Digitala resan mot en världsledande e-hälsa

Agenda. Kursinformation. Manual för systemstart... Föreläsning 6: Utvärdering och om tentamen

Transkript:

Tentafrågor Grupp C Fråga 1 Focal Point-metoden innehåller sex iterativa och inkrementella aktiviteter. Välj ut dessa och ordna dem medurs efter varandra i spiralmodellen nedan. a ) Gör en CRUD-check b ) Visualisera och validera diagram c ) Strukturera krav d ) Ställ upp en cost-benefit matris e ) Samla in krav f ) Jämför krav tre och tre g ) Selektera och planera krav h ) Gör en riskanalys i ) Definiera kriterier j ) Fyll i relationsmatris k ) Gör en intressentanalys l ) Jämför krav parvis Rättningsmall: (med början klockan 12): e c i l b g 0,5 p för rätt aktivitet på rätt plats 0,25 p för rätt aktivitet på fel plats Fråga 2 - Frågor om marknadsdriven produktledning Svarar mot inlärningsmål: 1. Syfte o svårigheter med kravhantering 2. Intressenternas roll i kravprocessen 6. Kravhantering för olika situationer

(7. Krav vs produktledning) 16. Välj teknik beroende på sammanhang 18. Marknadsorienterad produktplanering Form enl. Exempel Påstående-anledn. Förel. 4, s.6. (1/2p / rätt svar) Påstående: I marknadsdriven produktutveckling är det alltid viktigast at vara först på marknaden med produkten. Den produkt som först når ut på marknaden vinner oftast störst marknadsandel och har oftast ett större antal försäljningsmånader. Svar: D, påståendet är felaktigt. Det är inte alltid viktigast att vara först på marknaden, utan vikten ligger i att vara på marknaden i rätt tid. Ibland kan det vara en fördel att vara nummer två. Anledningen är däremot ett korrekt påstående. Påstående: Då man arbetar marknadsdrivet är ofta kravhanteringsprocessen betraktad som svår och problematisk. Man använder metoder och verktyg som är avsedda att användas för kontraktdriven utveckling. Svar: A, både påstående o anledning är korrekta och anledningen förklarar påståendet på ett korrekt sätt. Påstående: Feature-rika produkter är ofta mer attraktiva för kunden men för mycket features kan ge en alltför komplex produkt, dvs mindre attraktiv. 80-20-regeln betyder att 20% av de features som finns står för 80% av användandet medan 80% av features står för 20% av användandet. Svar: B, anledningen till att feature-rika produkter ofta säljer bättre är att kundens behov är komplexa. De köper inte bara produkter som täcker dessa behov utan vill köpa produkter som täcker behov som de skulle kunna komma att få. Påstående: Generellt visar resultat på att av de produkter som utvecklas i industrin är mindre än hälften hjälpsamma. McKenna hävdar att orsaken till att så många produkter inte är lönsamma är att de inte är marknadsdrivna. Svar: A, både påståendet o anledningen är sanna, och anledningen förklarar påståendet korrekt.

Påstående: Marknadssegmentering är en del av processen för marknadsdriven produktledning. Marknadssegmentering innebär att vi delar in marknaden för att hitta gap mellan olika produkter eftersom det där kan finnas utrymme för nya produktidéer eller erbjudanden. Svar: C, påståendet är korrekt men anledningen är felaktig. Att hitta gap mellan produkter innebär att man gör en portföljanalys. Marknadssegmentering görs för att dela in våra kunder efter deras behov och förväntningar. Påstående: I marknadsdriven produktutveckling har man oftast många kunder, många konkurrenter och stor valfrihet i produktens innehåll och pris. I marknadsdriven produktutveckling har man ofta kända kunder, med vilka man har en dialog under produktens utveckling. Svar: C, påståendet är korrekt men anledningen felaktig. Anledningen beskriver snarare hur det kan förhålla sig för kontraktsdriven produktutveckling. Fråga 3 Tyvärr är kravhantering inte så enkelt att man bara kan fråga intressenterna vad de vill ha. Lauesen nämner ett antal problem vid elicitering (elicitation barriers). Ange de två eliciteringstekniker (A-R) som passar bäst för att övervinna varje eliciteringsproblem. A. Stakeholder analysis B. Interview C. Observation D. Task demo E. Document studies F. Questionnaires G. Brainstorm H. Focus groups I. Workshops J. Prototyping K. Pilot experiments L. Similar companies M. Ask suppliers N. Negotiation O. Risk analysis P. Cost/benefit Q. Goal-domain analysis R. Domain-requirement analysis

Intressenterna har svårt att uttrycka vilka uppgifter de gör och varför Intressenterna berättar lösningar istället för behov Intressenterna har svårt att föreställa sig nya sätt att göra sina uppgifter eller konsekvenserna av det nya sättet Olika intressenter har olika krav som är i konflikt med varandra Intressenterna hittar på för många krav där vissa är viktiga och andra lyx Det är svårt att hitta alla kraven med en gång, konsekvensen blir att man hittar fler krav när man har börjat använda systemet Bedömningsmall Varje rätt ifylld ruta ger 0,5 poäng. Intressenterna har svårt att uttrycka vilka uppgifter de gör och varför: D & C Intressenterna berättar lösningar istället för behov: B & R Intressenterna har svårt att föreställa sig nya sätt att göra sina uppgifter eller konsekvenserna av det nya sättet: M & N Olika intressenter har olika krav som är i konflikt med varandra: Två av O, I och P (det är alltså fler än två alternativ som är rätt) Intressenterna hittar på för många krav där vissa är viktiga och andra lyx: P & Q Det är svårt att hitta alla kraven med en gång, konsekvensen blir att man hittar fler krav när man har börjat använda systemet: K & L Frågan relaterar till inlärningsmål 1 (svårigheter), 2, 11, 15 och 16 i föreläsning 1. Rätt svar till frågan kan man komma fram till genom att läsa Lauesen kapitel 8 och tänka själv. Lausen berättar om problemen och teknikerna, men gör ingen (tydlig) mappning från problem till teknik. Fråga 4 Följande fråga relaterar till kurs målet om att vi ska kunna vissa tekniker för att specifiera krav. Det går att läsa om dessa i Lauesens kapitel 2 och 3. Vilken typ av krav (A till E) passar bäst i följande situationer. Uppgiften ger ett ½ poäng per ruta. A. Task & Support B. Virtual windows C. Feature requirements D. Data flow diagrams E. Screens and prototypes En produkt innehåller mycket data och man vill hitta vilken data som kommer att behöva vara tillgänglig och vilken data som kommer att ändras i vid en viss task. SVAR: D, Data flow diagram är bra på att visa vad som händer med datan vilket t.ex. virtual windows inte klarar av så bra.

Man vill på domännivå låta en oerfaren kund vara med och bestämma vilka produktegenskapskrav som ska ingå i produkten. SVAR: A, Eftersom kunden är oerfaren och man vill ha domänkrav så passar Task & Support. För en viss uppgift vill vi ha goda möjligheter att validera att rätt data finns tillgänglig och att datan är lätt att ta till sig. SVAR: E, Eftersom både viken data och hur lättillgänglig den är ska beskrivas passar Screens and prototypes. Påstående: Task & Support är bättre än Use case på att beskriva domänkrav. Use case är dåligt på domänkrav eftersom dom inte håller detaljer om specifika aktiviteter. SVAR: Påstående är rätt men anledning ä felaktig (Fall C i föreläsnings anteckningarna) Följande frågor relaterar till kunskap om flera tekniker att specificera krav. Varje svar till en fråga ger ett ½ poäng. Påståendet: Lauesens vivid senario är bättre på att ge utvecklarna en helhetsbild av en tänkt arbetssituation än vad Task & deskription är. Task descriptions beskriver mer varianter av en aktivitet än vad ett scenario gör. SVAR: Påståendet är rätt och anledning är rätt men inte en anledning till påståendet (Fall B i föreläsnings anteckningarna) Påståendet: Med context diagram så är det lätt att göra en högnivåvalidering av att alla gränssnitt behandlas men det är inte lätt för kunden att validera själva context diagrammet. Kunden har ofta svårt att se vad som fattas i ett context diagram. SVAR: Både påståendet och andledningen är felaktiga.