+ Många bra och lagom svåra frågor.
- (3) delvis missvisande om 'tacit reqts' (underförstådda krav); man kan inte generellt säga att dessa inte 'ska' vara med, då man ju kan jobba med att gräva fram dem och göra dem explicita (fast då är de ju inte underförstådda längre)...
+ Många bra frågor.
- (5) Ganska lång och komplicerad; påståendet innehåller även en anledning '... as it ...'. (6) 'All types' kanske väl lätt att genomskåda som 'fel' eftersom det är så svepande.
+ Flera bra frågor.
- Ord 'alla' (1), 'bäst' (2) etc. är ofta alltför kategoriska och det blir lätt uppenbart falskt. (6) Om en enkät är bra eller dålig beror på enkäten - man kan inte generellt hävda att enkäter är dåliga som eliciteringsverktyg...
+ Några bra frågor.
- (1) 'hela kravspecen' är väl lätt att genomskåda som fel. (2) Väldigt svår och kanske tvetydigt eller felaktigt facit - visst kan väl användaren som kör användartestet 'råka' berätta att den har problem? (3) Påståendet nog väldigt lätt att genomskåda som fel om man läst minsta lilla om QUPER. (4) Inkonsekvens i facit: är inte påståendet sant om det som står i facit gäller (alltså att om den gäller för båda gäller den också för den ena)? (6) Kan inte gott samarbete orsaka att det blir lätt att ändra?
+ En del bra frågor.
- (P3) Väl kategoriskt 'no use' och 'all details' - blir för lätt då. (P4) 'specific parts' väl vagt, vilka delar? (P5) 'should be used' är väl kategoriskt - för lätt, uppenbart fel.
+ Flera bra frågor.
- (2.2p2) Är det inte kunden som har svårt att välja nivå snarare än leverantören? (3.2p2) Men man kan väl ändå samarbeta även om man ser olika risker? (4.2p2) Ni fokuserar på hur 'sofistikerade' teknikerna är, men det är väl egentligen viktigare hur lång tid det tar att göra dem och huruvida det finns redundans i jämförelserna så att man kan upptäcka eller ej cirkulära inkonsekvenser. (5.1p1) Resonemanget i motivationen gäller stora ändringar medan påståendet rör ändringsfrekvensen. Detta är ju faktiskt olika saker...
+ Flera bra frågor.
- (2) Det är iofs inget som förbjuder att affärsmål är krav, men det kan vara olämpligt om leverantören inte kan ta ansvar för själva användandet av produkten i ett affärssammanhang.(6) Tasks descriptions innehåller väl mestadels funktionella aspekter, så i någon mening är de mestadels funktionella krav på domännivå.
+ Flera bra frågor
- (2) I påståendet blir det förvirrande. Är det kravens korrekthet eller systemets korrekthet som avses? (4) Detta är nog lite för lätt att genomskåda som felaktigt.
+ Många bra frågor.
- (2) Detaljrikedomen har väl inte med vilken typ af information som finns? Det kan väl finnas mer eller mindre detaljrika VW? Det man vill undvika är att de missuppfattas som en design av användargränssnittet...
+ Flera bra frågor
- (Problem Tender process) 'time cost(s)' -> effort?, time costly -> time consuming? (Problem: Open target) Är anledningen verkligen förklarande? (Problem Requirement specification:) Ang motivationen: Det beror väl på vilken nivå man tycker är lämplig för kraven. Om domännivå är lämpligare i ngt specifikt fall och man kanske inte har så stort inflytande över användragränssnittet (tex vid inköp av COTS) så kanske det inte är så bra med en massa gui-detaljer... (Problem: Release planning) Kanske väl lätt. Jag tycker annat med rp är viktigare att testa än detta- tex förståelsen för att det lätt blir en kombinatorisk 'explosion'...
+ Många bra frågor.
- (1) Jag tror iofs att man kan ha nytta av krav på domän-nivå även för då man ska köpa COTS, tex för att kolla om våra arbetsuppgifter verkligen stöds av COTS-produkten.
+ Många bra frågor
- (1) Det blir lite rörigt att tolka frågan med flera påstående i ett och dessutom flera anledningar... Bättre att renodla till ett påstående och en anledning.
+ Flera bra frågor
- (1) Ordet 'enbart' gör det här väl lätt att genomskåda att det är falskt. (2) Ordet 'obegränsade' gör det här väl lätt att genomskåda att det är falskt. (8) Påståendet kan vara sant för vissa fall. Bättre att göra en utsaga om fallet som utesluts. 'Affärsmål karaktäriserar nyttan även för produkter utan vinstsyfte' el likn.
+ Många bra frågor.
- (2) Man kan nog argumentera för att piloter inte fullt ut förstår vad som händer i flygplanens styrsystem... (4) Vad är en 'längre process'? (6) Klyddigt med flera utsagor i både påstående och anledning. Bättre att renodla. (8) 'Finns inget bevis' - har ni kollat alla empiriska studier? Kanske har ngn ett bevis ni inte känner till...
+ Flera bra frågor.
- (P3) Kategoriska uttalanden är ofta lätt genomskådade as falska, som i detta fall: 'can not'. (P5) Är det systemet eller kraven som 'har' uppgiftsbeskrivningar? Är rätt svar verkligen A? (P7) För lätt.
+ Många bra frågor.
- (4) Men det kan ju vara en väg mot korrektion... Anledningen kan således tolkas som sann. (6) 'must' är ett starkt ord...
+ Många bra frågor
- (Kap8-1) Oklart om ni avser att anledningen förklara påståendet. Gör den det?
+ Flera bra frågor.
- (1) Påståendets meningsbyggnad är svårläst. Är anledningen verkligen alltid falsk? (2) 'skall endast' är starka ord som ganska enkelt avslöjar att påståendet är falskt utan att man behöver förstå så mycket av vad frågar ämnar testa. (3) Verkar vettigt, men vi har i och för sig inte studerat dessa saker empiriskt, så vi vet inte att det är så.