E Both the proposition and the reason are false.

Transkript

1 Lunds Tekniska Högskola, Datavetskap Skriftlig ttam i ETS170 Kravhantering kl 8-13, Vic:3C-3D Hjälpmedel: Inga Lund University, Computer Scice Writt Exam in Requiremts Engineering Assisting material: None NAMN/NAME: PERSONNUMMER/PERSONAL ID NBR: Ttam innehåller två delar: Del A Teori 50 poäng, Del B Uppsatsämn 50 poäng Del A består av flervalsfrågor och fylls i direkt i detta häfte Del B innehåller öppna frågor som besvaras i uppsatsform och lämnas in på separata papper Skriv namn på varje inlämnat papper! DEL A TEORI 50p Dna del innehåller uppgifter med påståd och anledningar För varje uppgift svara med ett av följande alternativ: The exam consists of two parts: PART A Theory 50 points, Part B Essays 50 points Part A consists of multiple choice problems and is answered directly in this booklet Part B consists of op topics that are answered by essays and handed in on separate paper Please write your name on each paper sheet! PART A THEORY 50p This part includes assignmts with pairs of propositions and reasons For each assignmt choose one of the following answers: A Både påstådet och anledning är korrekta uttaland och anledning förklarar påstådet på ett korrekt sätt B Både påstådet och anledning är korrekta uttaland, m anledning förklarar inte påstådet C Påstådet är ett korrekt uttalande, m anledning är falsk D Påstådet är falskt, m anledning är ett korrekt uttalande E Både påstådet och anledning är falska För påståde-anledning-uppgifter ger rätt svar 2 poäng medan felaktigt eller inget svar ger 0 poäng A Both the proposition and the reason are correct statemts, and the reason explains the proposition in a correct way B Both the proposition and the reason are correct statemts, but the reason does not explain the proposition C The proposition is a true statemt, but the reason is false D The proposition is false, but the reason is a true statemt E Both the proposition and the reason are false Correctly answered proposition-reason assignmts give 2 points, while incorrect or missing answers give 0 points 1

2 A1 sv Det är ofta bättre att vänta med att prioritera krav till i slutet av kravprocess It is oft better to wait with requiremts prioritization until the d of the requiremts gineering process En delmängd av krav blir normalt tydligare allteftersom kravprocess fortskrider A subset of the requiremts normally become clearer as the requiremts gineering process proceeds A2 sv Prioritering med ordinal skala kräver ofta mer arbete jämfört med prioritering med ratio-skala Prioritization using ordinal scale oft requires more work compared to prioritization using a ratio scale Vid användning av ratio-skala behöver prioriteternas inbördes förhålland eliciteras Wh a ratio scale is used mutual priority fractions also need to be elicited A3 sv Krav på domän-nivå tar ibland inte ställning till hur uppdelning av deluppgifter mellan systemet och dess aktörer ska göras Förtida beslut om uppdelning kan i onödan begränsa möjlighet att under implemtation göra bra avvägningar mellan kostnad och nytta Sometimes requiremts at domain level do not stipulate how subtasks should be divided betwe the system and its actors Premature decisions about the split can put unnecessary restrictions on the possibilities to make good trade-offs betwe cost and befit during implemtation A4 sv Ett användbarhetstest gomförs med fördel som demonstration där utvecklare visar hur systemet används Användbarhetstestning är ofta mer verkningsfullt när det gäller att hitta verkliga användbarhetsproblem i jämförelse med heuristisk utvärdering A usability test can preferably be carried out as a demonstration where the developer shows how to use the system Usability testing is oft more effective in finding real usability problems compared to heuristic evaluation 2

3 A5 sv Bra kravhantering åstadkommer samma höga fullständighetsnivå för olika typer av krav Både triviala och icke-triviala krav bör specificeras med lika stor noggrannhet för bästa användning av spderad ansträngning Good requiremts gineering achieves the same high level of completess for differt types of requiremts Both trivial and non-trivial requiremts should be specified with the same accuracy to make best use of spt effort A6 sv Prestandakrav bör i upphandlingssammanhang innehålla fix maximal svarstid Riskerna för leverantör av ett fleranvändarsystem blir lätt orimligt höga om svarstidskrav har maxtidsgräns som inte tar hänsyn till systemets belastning Performance requiremts in a tder context should include a fix maximal response time The risks for the supplier of a multi-user system can easily become unacceptably high if response time requiremts have a maximum limit that do not take the system load into account A7 sv Om prototyp till hög grad uppfyller krav kan verifiering av implemtation undvikas Om integratör begränsar sitt ansvar till prototyper av lit andel av delsystem kan verifieringsrisk minska avsevärt för kund If a prototype to a large degree fulfills the requiremts th the verification of the implemtation can be avoided If the integrator limits its responsibility to prototypes of a small fraction of the subsystems th the customer s risk of verification can be reduced significantly 3

4 A8 sv Om man tar hänsyn till preceds och koppling i utgåveplanering är det troligt att lösningsrymd minskar Antalet möjliga utgåveplaner som uppfyller villkor blir i allmänhet fler om fler begränsningar införs If precedce and coupling is tak into account in release planning it is likely that the solution spaces becomes smaller The number of possible release plans that fulfil the constraints will in geral be greater if more constraints are introduced A9 sv D obefintliga klyftan mellan marknads- och utvecklingsavdelning som påvisades i kätstude [Karlsson, et al, 2002], visar att andra utmaningar är viktigare att hantera Snabba organisatoriska förändringar kan göra det svårt att införa återuppringsbar kravprocess The minimal chasm betwe marketing and developmt found in a survey [Karlsson, et al, 2002], shows that other challges are more important to address Rapid organisational changes may lead to difficulties in installing a repeatable requiremts gineering process A10 sv Om kombination av olika prioriteringstekniker används, krävs det att de valda teknikerna använder samma ratio-skala En kombination av tekniker minskar granularitet i prioritering If a combination of differt prioritization techniques is applied, it is required that the chos techniques use the same ratio scale A combination of techniques reduces the granularity of prioritzation 4

5 A11 sv Att ersätta stora delar av d skriftliga kommunikation mellan utvecklare och kunder med muntlig kommunikation kan vara riskfyllt Om intsiv kommunikation ej kan uppnås kan risk att kravprocess resulterar i inkorrekta krav öka betydligt To replace large parts of the writt communication betwe developers and customers with face-to-face communication can pose risks If intsive communication cannot be achieved, the risk that the requiremts gineering process leads to incorrect requiremts may increase significantly A12 sv Iterativ kravhantering visade sig i de flesta fall leda till bättre hantering av kvalitetskrav [Cao och Ramesh, 2008] I tidiga iterationer fick kvalitetskrav ofta begränsad uppmärksamhet jämfört med funktionella krav [Cao och Ramesh, 2008] Iterative requiremts gineering in most cases led to improved treatmt of quality requiremts [Cao and Ramesh, 2008] In early iterations quality requiremts oft got limited atttion compared to functional requiremts [Cao and Ramesh, 2008] A13 sv Test-driv utveckling kan öka spårbarhet Testfall kan fånga krav m länkar inte till design och kod Test-driv developmt can increase traceability Test cases can capture requiremts but do not link to design and code A14 sv Det var färre företag som använde test-driv utveckling jämfört med iterativ kravhantering i kartläggning av agil praxis av Cao and Ramesh, 2008 Det finns stora risker vad gäller till exempel skalbarhet med att låta prototypkod överföras till produktionskod It was fewer companies that used test-driv developmt compared to iterative requiremts gineering in the survey on agile practice by Cao and Ramesh, 2008 There are large risks, for example regarding scalability, with transferring code from prototypes to production code 5

6 A15 sv 9-faldig inspektion innefattar 9 (9 1)/2 oberode granskningsgrupper och är därför sällan försvarbart om fokus ligger på feltäckning snarare in kostnad för persontid Antalet parvisa jämförelser mellan krav växer kvadratiskt med antalet krav 9-folded inspection comprises 9 (9 1)/2 indepdt inspection teams and is hce seldom justifiable if the focus is on defect coverage rather than cost of effort The number of pairwise comparisons betwe requiremts grows quadratically with the number of requiremts A16 sv Forskning har visat att täckning av defekter ökar om flera grupper gör oberode granskningar Validering med fokus på inkorrekta krav försöker täcka krav som inte återspeglar verkliga behov Research has shown that defect coverage increases if several groups do indepdt inspections Validation with focus on incorrect requiremts tries to cover requiremts that do not reflect real needs A17 sv Eliminering av redundans kan påverka läsbarhet av ett kravdokumt negativt Referser mellan krav istället för upprepning ökar risk för spridda kravtexter som saknar sammanhang Elimination of redundancy may have a negative impact on the readability of a requiremts documt Refercing instead of repetition increases the risks of scattered requiremts texts out of context A18 sv Multiplicitet i ett E/R-diagram försämras om virtuella fönster används som underlag för användargränssnittsdesign Kardinalitet i virtuella fönster visas mer effektivt med främmande nycklar The multiplicity in an E/R-diagram gets worse if virtual windows are used as the basis for user interface design The cardinality in virtual windows is more effectively shown if foreign keys are used 6

7 A19 sv Skärmbilder och prototyper är mer lämpade för att beskriva krav på domännivå jämför med uppgiftsbeskrivningar Uppgiftsbeskrivningar saknar information om hur aktörernas måluppfyllese sker Scres and prototypes are more suitable wh describing requiremts at domain level compared to task descriptions Task descriptions lack information about how actors achieve their goals A20 sv Kontextdiagram är lämpliga för att beskriva krav på både målnivå och designnivå Ett kontextdiagram kompletteras ofta med specifikationer av domändata som överförs via gränssnitt mellan de aktörerna i d inre domän och systemet Context diagrams are suitable for describing requiremts at both goal level and design level A context diagram is oft complemted by specifications of domain data that is transferred via interfaces betwe actors in the inner domain and the system A21 sv Kontextdiagram är inte lämpligt vid utveckling med löpande räkning Context diagrams are not suitable for time-and-material-based developmt Kontextdiagram specificerar i första hand aktörer i d yttre domän Context diagrams primarily specifies actors in the outer domain A22 sv QUPER beskriver utplaning av kvalitetsnyttan med differsieringsbrytpunkt Innan barriär kan kvalitet förbättras till förhållandevis låg kostnad, m vid barriär krävs större investeringar för att nå högre kvalitet QUPER describes a flatting out of the quality befit by a differtiation breakpoint Before a barrier, the quality can be improved to a relatively small cost, while at a barrier larger investmts are required to gain higher quality 7

8 A23 sv Uppgiftsbeskrivningar är ofta lättare för användare att validera jämfört med klassdiagram I uppgiftsbeskrivningar är tidsordning av underuppgifter bestämd av ansvarsfördelning mellan systemet och aktörerna Task descriptions are oft easier for users to validate compared to class diagrams In task descriptions the temporal ordering of subtasks is determined by the division of responsibility betwe the system and the actors A24 sv Ett virtuellt fönster är bra för att beskriva flödet i de bearbetningar av data som sker efter att användar konfirmerat inmatning Specifikation av datakrav med virtuella fönster fokuserar på relation mellan indata och utdata och de transformeringar som sker däremellan A virtual window is good for describing the flow of data computations that are made after user input confirmation Specification of data requiremts with virtual windows focuses on the relation betwe input and output and the transformations that are made in-betwe A25 sv Kvalitetskrav är ofta svårare att specificera än datakrav Kvalitetskrav påverkar ofta flera systemkomponter än datakrav och specifikation av kvalitetsnivåer sker ofta i relation till glidande skalor Quality requiremts are oft more difficult to specify than data requiremts Quality requiremts oft affect more system componts than data requiremts and the specification of quality levels is oft made in relation to sliding scales 8

9 DEL B UPPSATSER 50p Part B: ESSAYS 50 p Utgå från ämna nedan och skriv uppsatser inom maximalt antal sidor ligt nedan Uppsatserna poängsätts efter (a) hur väl ämnet beskrivs gom begrepp i listan, samt (b) hur väl begrepp definieras och exemplifieras Var noga med att skriva läsligt Svårlästa eller svårbegripliga uppsatser ger avdrag Börja på nytt blad för varje ny uppsats Based on the topics below, write essays within the giv maximum number of pages The essays are marked based on (a) how well the topic is described using the concepts in the list, and (b) how well the concepts in the list are defined and exemplified Please make an effort to write readable Essays that are difficult to read or difficult to understand will rder deduction Start on a new paper sheet for each essay B1 Prioritering max 1 sida max 10 poäng skalor, kombinera tekniker, omprioritering, utgåveplanering B1 Prioritization max 1 page max 10 points scales, combine techniques, re-prioritization, release planning B2 Elicitering max 2 sidor max 20 poäng barriärer, olika saker att elicitera, eliciteringsteknikers lämplighet, intresstanalys, intervjuer, fokusgrupper, prototyper, mål-domän-analys B2 Elicitation max 2 pages max 20 points barriers, things to elicit, suitability of elicitation techniques, stakeholder analysis, interviews, focus groups, prototypes, goal-domain analysis B3 Validering max 2 sidor max 20 poäng korrekt, fullständig, otvetydigt, konsekvt, modifierbar, verifierbar, checklista, konsekvskontroll, SLUTÖ-matris B3 Validation max 2 pages max 20 points correct, complete, unambiguous, consistt, modifiable, verifiable, check list, consistcy check, CRUDO matrix 9

10 Skriftlig ttam i ETS170 Kravhantering kl 8-13, Vic:3C-3D FACIT DEL A 1

11 2

12 A1 sv Det är ofta bättre att vänta med att prioritera krav till i slutet av kravprocess En delmängd av krav blir normalt tydligare allteftersom kravprocess fortskrider PRIO, MDRE, baserad på studtförslag It is oft better to wait with requiremts prioritization until the d of the requiremts gineering process A subset of the requiremts normally become clearer as the requiremts gineering process proceeds D A2 sv Prioritering med ordinal skala kräver ofta mer arbete jämfört med prioritering med ratio-skala Prioritization using ordinal scale oft requires more work compared to prioritization using a ratio scale Vid användning av ratio-skala behöver prioriteternas inbördes förhålland eliciteras Wh a ratio scale is used mutual priority fractions also need to be elicited PRIO, baserad på studtförslag D A3 sv Krav på domän-nivå tar ibland inte ställning till hur uppdelning av deluppgifter mellan systemet och dess aktörer ska göras Förtida beslut om uppdelning kan i onödan begränsa möjlighet att under implemtation göra bra avvägningar mellan kostnad och nytta Lau:1, baserad på studtförslag A Sometimes requiremts at domain level do not stipulate how subtasks should be divided betwe the system and its actors Premature decisions about the split can put unnecessary restrictions on the possibilities to make good trade-offs betwe cost and befit during implemtation A4 sv Ett användbarhetstest gomförs med fördel som demonstration där utvecklare visar hur systemet används Användbarhetstestning är ofta mer verkningsfullt när det gäller att hitta verkliga användbarhetsproblem i jämförelse med heuristisk utvärdering Lau:6, baserad på studtförslag D A usability test can preferably be carried out as a demonstration where the developer shows how to use the system Usability testing is oft more effective in finding real usability problems compared to heuristic evaluation 3

13 A5 sv Bra kravhantering åstadkommer samma höga fullständighetsnivå för olika typer av krav Good requiremts gineering achieves the same high level of completess for differt types of requiremts Både triviala och icke-triviala krav bör specificeras med lika stor noggrannhet för bästa användning av spderad ansträngning Both trivial and non-trivial requiremts should be specified with the same accuracy to make best use of spt effort Lau:9, p376, baserad på studtförslag E A6 sv Prestandakrav bör i upphandlingssammanhang innehålla fix maximal svarstid Riskerna för leverantör av ett fleranvändarsystem blir lätt orimligt höga om svarstidskrav har maxtidsgräns som inte tar hänsyn till systemets belastning Lau:75, 65 D Performance requiremts in a tder context should include a fix maximal response time The risks for the supplier of a multi-user system can easily become unacceptably high if response time requiremts have a maximum limit that do not take the system load into account A7 sv Om prototyp till hög grad uppfyller krav kan verifiering av implemtation undvikas If a prototype to a large degree fulfills the requiremts th the verification of the implemtation can be avoided Om integratör begränsar sitt ansvar till prototyper av lit andel av delsystem kan verifieringsrisk minska avsevärt för kund If the integrator limits its responsibility to prototypes of a small fraction of the subsystems th the customer s risk of verification can be reduced significantly Lau:3, 5, baserad på studtförslag E 4

14 A8 sv Om man tar hänsyn till preceds och koppling i utgåveplanering är det troligt att lösningsrymd minskar Antalet möjliga utgåveplaner som uppfyller villkor blir i allmänhet fler om fler begränsningar införs RP C If precedce and coupling is tak into account in release planning it is likely that the solution spaces becomes smaller The number of possible release plans that fulfil the constraints will in geral be greater if more constraints are introduced A9 sv D obefintliga klyftan mellan marknads- och utvecklingsavdelning som påvisades i kätstude [Karlsson, et al, 2002], visar att andra utmaningar är viktigare att hantera Snabba organisatoriska förändringar kan göra det svårt att införa återuppringsbar kravprocess MDRE D The minimal chasm betwe marketing and developmt found in a survey [Karlsson, et al, 2002], shows that other challges are more important to address Rapid organisational changes may lead to difficulties in installing a repeatable requiremts gineering process A10 sv Om kombination av olika prioriteringstekniker används, krävs det att de valda teknikerna använder samma ratio-skala En kombination av tekniker minskar granularitet i prioritering PRIO E If a combination of differt prioritization techniques is applied, it is required that the chos techniques use the same ratio scale A combination of techniques reduces the granularity of prioritzation 5

15 A11 sv Att ersätta stora delar av d skriftliga kommunikation mellan utvecklare och kunder med muntlig kommunikation kan vara riskfyllt Om intsiv kommunikation ej kan uppnås kan risk att kravprocess resulterar i inkorrekta krav öka betydligt AGRE A To replace large parts of the writt communication betwe developers and customers with face-to-face communication can pose risks If intsive communication cannot be achieved, the risk that the requiremts gineering process leads to incorrect requiremts may increase significantly A12 sv Iterativ kravhantering visade sig i de flesta fall leda till bättre hantering av kvalitetskrav [Cao och Ramesh, 2008] I tidiga iterationer fick kvalitetskrav ofta begränsad uppmärksamhet jämfört med funktionella krav [Cao och Ramesh, 2008] AGRE D Iterative requiremts gineering in most cases led to improved treatmt of quality requiremts [Cao and Ramesh, 2008] In early iterations quality requiremts oft got limited atttion compared to functional requiremts [Cao and Ramesh, 2008] A13 sv Test-driv utveckling kan öka spårbarhet Test-driv developmt can increase traceability Testfall kan fånga krav m länkar inte till design och kod Test cases can capture requiremts but do not link to design and code AGRE, Lau: 9 C A14 sv Det var färre företag som använde test-driv utveckling jämfört med iterativ kravhantering i kartläggning av agil praxis av Cao and Ramesh, 2008 Det finns stora risker vad gäller till exempel skalbarhet med att låta prototypkod överföras till produktionskod AGRE B It was fewer companies that used test-driv developmt compared to iterative requiremts gineering in the survey on agile practice by Cao and Ramesh, 2008 There are large risks, for example regarding scalability, with transferring code from prototypes to production code 6

16 A15 sv 9-faldig inspektion innefattar 9 (9 1)/2 oberode granskningsgrupper och är därför sällan försvarbart om fokus ligger på feltäckning snarare in kostnad för persontid Antalet parvisa jämförelser mellan krav växer kvadratiskt med antalet krav INSP, PRIO D 9-folded inspection comprises 9 (9 1)/2 indepdt inspection teams and is hce seldom justifiable if the focus is on defect coverage rather than cost of effort The number of pairwise comparisons betwe requiremts grows quadratically with the number of requiremts A16 sv Forskning har visat att täckning av defekter ökar om flera grupper gör oberode granskningar Validering med fokus på inkorrekta krav försöker täcka krav som inte återspeglar verkliga behov INSP, Lau:9 B Research has shown that defect coverage increases if several groups do indepdt inspections Validation with focus on incorrect requiremts tries to cover requiremts that do not reflect real needs A17 sv Eliminering av redundans kan påverka läsbarhet av ett kravdokumt negativt Elimination of redundancy may have a negative impact on the readability of a requiremts documt Referser mellan krav istället för upprepning ökar risk för spridda kravtexter som saknar sammanhang Refercing instead of repetition increases the risks of scattered requiremts texts out of context Lau:9, pp A A18 sv Multiplicitet i ett E/R-diagram försämras om virtuella fönster används som underlag för användargränssnittsdesign Kardinalitet i virtuella fönster visas mer effektivt med främmande nycklar Lau:2 E The multiplicity in an E/R-diagram gets worse if virtual windows are used as the basis for user interface design The cardinality in virtual windows is more effectively shown if foreign keys are used 7

17 A19 sv Skärmbilder och prototyper är mer lämpade för att beskriva krav på domännivå jämför med uppgiftsbeskrivningar Uppgiftsbeskrivningar saknar information om hur aktörernas måluppfyllese sker Lau: E Scres and prototypes are more suitable wh describing requiremts at domain level compared to task descriptions Task descriptions lack information about how actors achieve their goals A20 sv Kontextdiagram är lämpliga för att beskriva krav på både målnivå och designnivå Ett kontextdiagram kompletteras ofta med specifikationer av domändata som överförs via gränssnitt mellan de aktörerna i d inre domän och systemet Lau:15, 32 D Context diagrams are suitable for describing requiremts at both goal level and design level A context diagram is oft complemted by specifications of domain data that is transferred via interfaces betwe actors in the inner domain and the system A21 sv Kontextdiagram är inte lämpligt vid utveckling med löpande räkning Context diagrams are not suitable for time-and-material-based developmt Kontextdiagram specificerar i första hand aktörer i d yttre domän Context diagrams primarily specifies actors in the outer domain Lau:1,3 E A22 sv QUPER beskriver utplaning av kvalitetsnyttan med differsieringsbrytpunkt Innan barriär kan kvalitet förbättras till förhållandevis låg kostnad, m vid barriär krävs större investeringar för att nå högre kvalitet QUPER D QUPER describes a flatting out of the quality befit by a differtiation breakpoint Before a barrier, the quality can be improved to a relatively small cost, while at a barrier larger investmts are required to gain higher quality 8

18 A23 sv Uppgiftsbeskrivningar är ofta lättare för användare att validera jämfört med klassdiagram I uppgiftsbeskrivningar är tidsordning av underuppgifter bestämd av ansvarsfördelning mellan systemet och aktörerna Lau:36, 312 C Task descriptions are oft easier for users to validate compared to class diagrams In task descriptions the temporal ordering of subtasks is determined by the division of responsibility betwe the system and the actors A24 sv Ett virtuellt fönster är bra för att beskriva flödet i de bearbetningar av data som sker efter att användar konfirmerat inmatning Specifikation av datakrav med virtuella fönster fokuserar på relation mellan indata och utdata och de transformeringar som sker däremellan Lau:2 E A virtual window is good for describing the flow of data computations that are made after user input confirmation Specification of data requiremts with virtual windows focuses on the relation betwe input and output and the transformations that are made in-betwe A25 sv Kvalitetskrav är ofta svårare att specificera än datakrav Kvalitetskrav påverkar ofta flera systemkomponter än datakrav och specifikation av kvalitetsnivåer sker ofta i relation till glidande skalor Lau:14 p 18, 6 p 217 A Quality requiremts are oft more difficult to specify than data requiremts Quality requiremts oft affect more system componts than data requiremts and the specification of quality levels is oft made in relation to sliding scales 9