E Both the proposition and the reason are false.

Transkript

1 Lunds Tekniska Högskola, Datavetskap Skriftlig ttam i ETS170 Kravhantering kl. 8-13, MA:MA10B&C 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, 60 poäng) och del B (uppsatser, 40 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 60p 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, 60 points), and part B (essays, 40 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 60p 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 När man skriver krav på svarstider för ett fleranvändarsystem är det vanligtvis bäst att begränsa specifikation till ett kelt maximum. Svarstider i fleranvändarsystem varierar ofta i förhållande till systemets belastning. Wh writing requiremts for response times of a multi-user system it is oft best to limit the specification to a simple maximum. Response times in multi-user systems oft vary in relation to the system load. A2 sv Det är god praxis att specificera syftet bakom viktiga krav för att minska riskerna med tvetydigheter och feltolkningar. Domännivåkrav innehåller normalt många designbeslut som behöver förklaras. It is good praxis to specify the purpose behind important requiremts to reduce the risks of ambiguity and misinterpretation. Domain-level requiremts normally include many design decisions that need explanation. A3 sv En SLUTÖ-matris (Skapa, Läsa, Uppdatera, Ta bort, Översikt) är bättre lämpad för korrekthetsvalidering än för översstämmelsekontroll vid granskning av datakrav. Motsägelser mellan olika represtationer av datakrav kan idtifieras gom att korsgranska delar i SLUTÖ-matris. A CRUDO-matrix (Create, Read, Update, Delete, Overview) is more suitable for validation of correctness than for consistcy checking in data requiremts inspection. Inconsistcies among differt represtations of data requiremts can be idtified by cross-checking parts of a CRUDO-matrix,. 2

3 A4 sv Virtuella fönster är lämpliga som designnivåkrav på användargränssnittskomponter. Data som innehåller titeter från d yttre domän behöver oftast specificeras med kravteknik på designnivå. Virual windows are suitable as design level requiremts on user interface componts. Data that contain tities from the outer domain oft need to be specified using a design level requiremts technique. A5 sv Enligt Laues är käter med slutna frågor bra för att elicitera nya, okända produktkrav. Enkäter är lämpliga för att samla in information från många intresster. According to Laues, surveys with closed questions are good for eliciting new, unknown product requiremts. Surveys are suitable for collecting information from many stakeholders. A6 sv Fokusgrupper kan hjälpa till att säkerställa att varje intresst får något h önskar av produkt. I resultatet från ett fokusgruppmöte ingår listor med de högsta önskningarna från varje intresst. Focus groups can help make sure that each stakeholder gets something he/she wants from the product. The results of a focus group meeting include lists with each stakeholder s top wishes. A7 sv Öppna mått är lämpliga att använda när kund inte känner till något bra sätt att karaktärisera vissa kvalitetsaspekter. Öppna mått överlämnar ansvaret att definiera kvalitetsnivåer åt leverantör. Op metrics are suitable wh the customer does not know any good way to characterize a certain quality aspects. Op metrics transfer the responsibility to define quality levels to the supplier. 3

4 A8 sv Ett kontextdiagram är inte så lämpligt i upphandlingssituation. Ett kontextdiagram visar aktörerna i d inre domän. A context diagram is not very suitable in a tder situation. A context diagram shows the actors of the inner domain. A9 sv Enligt studie av Cao & Ramesh har vissa kvalitetskrav, så som säkerhet och skalbarhet, tds att negligeras när agil kravhantering används. När man arbetar med agil kravhantering så baseras prioritering ofta på produktägars syn på produkts affärsvärde, vilket sällan är definierat i termer av säkerhet och skalbarhet. According to a study by Cao & Ramesh, some quality requiremts, such as security and scalability, have a tdcy to be neglected wh using agile requiremts gineering. Wh working with agile RE the prioritization is oft based on the product owner s view of the product s business value, which is rarely defined in terms of security or scalability. A10 sv Förändringsbägna krav kan antas öka utvecklingskostnad. Förändringsbägna krav påverkar stabilitet i projektplanering och utvecklare kan behöva välja arkitektur som är mer lämpad för förändring. Volatile requiremts presumably increase the developmt costs. Volatile requiremts affect the project planning stability, and developers may have to select an architecture that is more suited to change. A11 sv Om integratör begränsar sitt ansvar till verifiering på delsystemnivå kan risk minska avsevärt för kund. Integrationsproblem kommer ofta av brist på ansvar för helhetslösning. If the integrator limits it responsibility to verification at subsystem level, the customer s risks can be significantly reduced. Integration problems oft depd on lack of explicit responsibility for the overall solution. 4

5 A12 sv Kvalitetskrav är ofta lättare att specificera än datakrav. Datakrav påverkar ofta flera komponter än kvalitetskrav på systemnivå. Quality requiremts are oft less difficult to specify than data requiremts. Data requiremts oft affect more componts than quality requiremts at system level. A13 sv QUPER-modell är lämplig vid specificering av eliciteringsbarriärer. QUPER-barriärer ger förklad bild av relation mellan kvalitet och kostnad. The QUPER model is suitable wh specifying elicitation barriers. QUPER barriers gives a simplified view of the relation betwe a quality and cost. A14 sv Kontextdiagram är sällan lämpliga som krav på designnivå. Ett kontextdiagram kompletteras ofta med specifikationer av domändata som överförs via gränssnitt mellan aktörerna i d inre domän och systemet. Context diagrams are seldom suitable as design level requiremts. 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. A15 sv Kvalitet i kravselekteringprocess kan karaktäriseras av antalet korrekt utvalda krav plus antalet korrekt förkastade krav gom totala antalet krav. I tillståndsmodell för krav ( laxtrappa ) finns ofta minst tillståndsövergång som represterar att krav förkastats. The quality of the requiremts selection process can be characterized by the sum of the number of correctly selected requiremts and the number of correctly rejected requiremts, divided by the total number of requiremts. In a requiremts state model ( salmon ladder ) there is oft at least one state transition that represts requiremts rejection. 5

6 A16 sv Tillståndsdiagram ger bra stöd vid validering av krav på webbsajter. Med tillståndsdiagram slipper användar inspektera hur händelser påverkar navigering. State diagrams give good support for validation of requiremts on web sites. With state diagrams the user does not have inspect how evts affect the navigation. A17 sv Prioritering med ordinal skala kräver ofta mer exakta estimeringar jämfört med prioritering med ratio-skala. Vid användning av ratio-skala kan prioriteterna jämföras proctuellt på ett mingsfullt sätt. Prioritization using ordinal scale oft requires more exact estimations compared to prioritization using a ratio scale. Wh a ratio scale is used the priorities can be compared in perctages in a meaningful way. A18 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. A19 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. 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. 6

7 A20 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. A21 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. A22 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. 7

8 A23 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. A24 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. A25 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]. 8

9 A26 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, 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, There are large risks, for example regarding scalability, with transferring code from prototypes to production code. A27 sv Skärmbilder och prototyper är mer lämpade för att beskriva krav på domännivå jämfört med uppgiftsbeskrivningar. Uppgiftsbeskrivningar saknar ofta information om hur aktörernas måluppfyllelse sker. Scres and prototypes are more suitable wh describing requiremts at domain level compared to task descriptions. Task descriptions oft lack information about how actors achieve their goals. A28 sv Antalet möjliga parvisa berod mellan krav växer kvadratiskt med antalet krav. Om antalet singulära krav är stort så kan man undvika att undersöka om det finns berod mellan del kravpar. The number of possible pairwise depdcies betwe requiremts grows quadratically with the number of requiremts. If the number of singular requiremts is large th the assessmt of depdcies betwe some requiremt pairs can be avoided. A29 sv Standardkrav är lämpliga som plattformskrav. Kvalitetsaspekter bland krav bör undvikas för standardplattformar. Standard requiremts are suitable as platform requiremts. Quality aspects among requiremts should be avoided for standard platforms. 9

10 A30 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. 10

11 DEL B UPPSATSER 40p Part B: ESSAYS 40 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 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 B1 Elicitation max 2 pages max 20 points barriers, things to elicit, suitability of elicitation techniques, stakeholder analysis, interviews, focus groups, prototypes, goal-domain analysis B2 Validering max 2 sidor max 20 poäng korrekt, fullständig, otvetydigt, konsekvt, modifierbar, verifierbar, checklista, konsekvskontroll, SLUTÖ-matris B2 Validation max 2 pages max 20 points correct, complete, unambiguous, consistt, modifiable, verifiable, check list, consistcy check, CRUDO matrix 11

12 Skriftlig ttam i ETS170 Kravhantering FACIT DEL A 1

13 2

14 A1 sv När man skriver krav på svarstider för ett fleranvändarsystem är det vanligtvis bäst att begränsa specifikation till ett kelt maximum. Svarstider i fleranvändarsystem varierar ofta i förhållande till systemets belastning. Lau:6, baserad på studtförslag D Wh writing requiremts for response times of a multi-user system it is oft best to limit the specification to a simple maximum. Response times in multi-user systems oft vary in relation to the system load. A2 sv Det är god praxis att specificera syftet bakom viktiga krav för att minska riskerna med tvetydigheter och feltolkningar. Domännivåkrav innehåller normalt många designbeslut som behöver förklaras. Lau:1, Lau:9, baserad på studtförslag It is good praxis to specify the purpose behind important requiremts to reduce the risks of ambiguity and misinterpretation. Domain-level requiremts normally include many design decisions that need explanation. C A3 sv En SLUTÖ-matris (Skapa, Läsa, Uppdatera, Ta bort, Översikt) är bättre lämpad för korrekthetsvalidering än för översstämmelsekontroll vid granskning av datakrav. Motsägelser mellan olika represtationer av datakrav kan idtifieras gom att korsgranska delar i SLUTÖ-matris. Lau:9, baserad på studtförslag D A CRUDO-matrix (Create, Read, Update, Delete, Overview) is more suitable for validation of correctness than for consistcy checking in data requiremts inspection. Inconsistcies among differt represtations of data requiremts can be idtified by cross-checking parts of a CRUDO-matrix,. 3

15 A4 sv Virtuella fönster är lämpliga som designnivåkrav på användargränssnittskomponter. Data som innehåller titeter från d yttre domän behöver oftast specificeras med kravteknik på designnivå. Lau:1 & 2, baserad på studtförslag Virual windows are suitable as design level requiremts on user interface componts. Data that contain tities from the outer domain oft need to be specified using a design level requiremts technique. E A5 sv Enligt Laues är käter med slutna frågor bra för att elicitera nya, okända produktkrav. Enkäter är lämpliga för att samla in information från många intresster. Lau:8, baserad på studtförslag According to Laues, surveys with closed questions are good for eliciting new, unknown product requiremts. Surveys are suitable for collecting information from many stakeholders. D A6 sv Fokusgrupper kan hjälpa till att säkerställa att varje intresst får något h önskar av produkt. I resultatet från ett fokusgruppmöte ingår listor med de högsta önskningarna från varje intresst. Lau:8 & 10, baserad på studtförslag Focus groups can help make sure that each stakeholder gets something he/she wants from the product. The results of a focus group meeting include lists with each stakeholder s top wishes. A A7 sv Öppna mått är lämpliga att använda när kund inte känner till något bra sätt att karaktärisera vissa kvalitetsaspekter. Op metrics are suitable wh the customer does not know any good way to characterize a certain quality aspects. Öppna mått överlämnar ansvaret att definiera kvalitetsnivåer åt leverantör. Op metrics transfer the responsibility to define quality levels to the supplier. Lau:6, baserad på studtförslag A 4

16 A8 sv Ett kontextdiagram är inte så lämpligt i upphandlingssituation. Ett kontextdiagram visar aktörerna i d inre domän. Lau:1, baserad på studtförslag A context diagram is not very suitable in a tder situation. A context diagram shows the actors of the inner domain. D A9 sv Enligt studie av Cao & Ramesh har vissa kvalitetskrav, så som säkerhet och skalbarhet, tds att negligeras när agil kravhantering används. När man arbetar med agil kravhantering så baseras prioritering ofta på produktägars syn på produkts affärsvärde, vilket sällan är definierat i termer av säkerhet och skalbarhet. AGRE, baserad på studtförslag A According to a study by Cao & Ramesh, some quality requiremts, such as security and scalability, have a tdcy to be neglected wh using agile requiremts gineering. Wh working with agile RE the prioritization is oft based on the product owner s view of the product s business value, which is rarely defined in terms of security or scalability. A10 sv Förändringsbägna krav kan antas öka utvecklingskostnad. Förändringsbägna krav påverkar stabilitet i projektplanering och utvecklare kan behöva välja arkitektur som är mer lämpad för förändring. PRIO, p 74 A Volatile requiremts presumably increase the developmt costs. Volatile requiremts affect the project planning stability, and developers may have to select an architecture that is more suited to change. A11 sv Om integratör begränsar sitt ansvar till verifiering på delsystemnivå kan risk minska avsevärt för kund. Integrationsproblem kommer ofta av brist på ansvar för helhetslösning. Lau:3, 5, baserad på studtförslag 2013 If the integrator limits it responsibility to verification at subsystem level, the customer s risks can be significantly reduced. Integration problems oft depd on lack of explicit responsibility for the overall solution. D 5

17 A12 sv Kvalitetskrav är ofta lättare att specificera än datakrav. Quality requiremts are oft less difficult to specify than data requiremts. Datakrav påverkar ofta flera komponter än kvalitetskrav på systemnivå. Data requiremts oft affect more componts than quality requiremts at system level. Lau:1.4 p. 18, 6 p. 217 E A13 sv QUPER-modell är lämplig vid specificering av eliciteringsbarriärer. QUPER-barriärer ger förklad bild av relation mellan kvalitet och kostnad. QUPER D The QUPER model is suitable wh specifying elicitation barriers. QUPER barriers gives a simplified view of the relation betwe a quality and cost. A14 sv Kontextdiagram är sällan lämpliga som krav på designnivå. Ett kontextdiagram kompletteras ofta med specifikationer av domändata som överförs via gränssnitt mellan aktörerna i d inre domän och systemet. Lau:1.5, 3.2 B Context diagrams are seldom suitable as design level requiremts. 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. A15 sv Kvalitet i kravselekteringprocess kan karaktäriseras av antalet korrekt utvalda krav plus antalet korrekt förkastade krav gom totala antalet krav. I tillståndsmodell för krav ( laxtrappa ) finns ofta minst tillståndsövergång som represterar att krav förkastats. MDRE B The quality of the requiremts selection process can be characterized by the sum of the number of correctly selected requiremts and the number of correctly rejected requiremts, divided by the total number of requiremts. In a requiremts state model ( salmon ladder ) there is oft at least one state transition that represts requiremts rejection. 6

18 A16 sv Tillståndsdiagram ger bra stöd vid validering av krav på webbsajter. Med tillståndsdiagram slipper användar inspektera hur händelser påverkar navigering. Lau:4 C State diagrams give good support for validation of requiremts on web sites. With state diagrams the user does not have inspect how evts affect the navigation. A17 sv Prioritering med ordinal skala kräver ofta mer exakta estimeringar jämfört med prioritering med ratio-skala. Prioritization using ordinal scale oft requires more exact estimations compared to prioritization using a ratio scale. Vid användning av ratio-skala kan prioriteterna jämföras proctuellt på ett mingsfullt sätt. Wh a ratio scale is used the priorities can be compared in perctages in a meaningful way. PRIO, baserad på studtförslag D A18 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. Lau:9, pp A 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. A19 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. PRIO, MDRE, baserad på studtförslag D 7

19 A20 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 2013 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. A21 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 2013 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. A22 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, p.376, baserad på studtförslag 2013 E 8

20 A23 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. A24 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. A25 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]. 9

21 A26 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, 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, There are large risks, for example regarding scalability, with transferring code from prototypes to production code. A27 sv Skärmbilder och prototyper är mer lämpade för att beskriva krav på domännivå jämfört med uppgiftsbeskrivningar. Uppgiftsbeskrivningar saknar ofta information om hur aktörernas måluppfyllelse sker. Lau: E Scres and prototypes are more suitable wh describing requiremts at domain level compared to task descriptions. Task descriptions oft lack information about how actors achieve their goals. A28 sv Antalet möjliga parvisa berod mellan krav växer kvadratiskt med antalet krav. Om antalet singulära krav är stort så kan man undvika att undersöka om det finns berod mellan del kravpar. INTDEP B The number of possible pairwise depdcies betwe requiremts grows quadratically with the number of requiremts. If the number of singular requiremts is large th the assessmt of depdcies betwe some requiremt pairs can be avoided. A29 sv Standardkrav är lämpliga som plattformskrav. Standard requiremts are suitable as platform requiremts. Kvalitetsaspekter bland krav bör undvikas för standardplattformar. Quality aspects among requiremts should be avoided for standard platforms. Lau:5 C 10

22 A30 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:3.6, 3.12 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. 11