E Both the proposition and the reason are false.

Transkript

1 Lunds Tekniska Högskola, Datavetskap Skriftlig ttam i ETS170 Kravhantering kl , MA:8A&8B Hjälpmedel: Inga. Lund University, Computer Scice Writt Exam in Requiremts Engineering Assisting material: None. ANONYMKOD/ANONYMOUS CODE: PERSONLIG ID/PERSONAL ID: 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 vald personlig idtifierare 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 chos personal idtifier on each sheet of paper! 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 Mängd av intresster inkluderar ofta system som interagerar med produkt. System som interagerar med produkt inkluderas ofta i ett kontextdiagram. The set of stakeholders oft include systems interacting with the product. Systems that interact with the product are oft included in a context diagram. A2 sv Uppgiftsdemonstrationer är ofta bra teknik för att elicitera behov och aktuella problem. Intresster kan begära lösningar som inte adresserar de tänkta användarnas problem pga bristande förståelse för dessas behov och nuvarande arbetssätt. Task demonstration is a oft a good technique for eliciting needs and prest problems. Stakeholders may demand solutions that do not address the problems of the intded users due to lack of understanding of their needs and currt way of working. A3 sv Kunder utan IT-bakgrund tycker ofta att datamodeller represterade som E/R diagram är svåra att förstå. Entiteter i ett domännivå E/R diagram motsvarar ofta data i d slutgiltiga produkt. Customers without an IT background td to find data models represted as E/R diagrams hard to understand. Entities in a domain-level E/R diagram oft correspond to data tities in the final product. 2

3 A4 sv Brist på kvalitetskrav är ett vanligt problem både för traditionell och agil utveckling som ofta leder till kvalitetsproblem i d slutgiltiga produkt. Eftersom kvalitetskrav ofta ses som triviala att specifiera så fokuserar kravinsats istället på d icke-triviala krav aspekterna. Detta leder till att kvalitetskrav specificeras st under utvecklingsprocess. The lack of quality requiremts is a common problem both for traditional and agile developmt that oft leads to quality issues in the final product. Since quality requiremts are se as trivial to specify, the requiremts efforts are rather focused on the non-trivial requiremts aspects, leaving quality requiremts until late in the developmt process. A5 sv Relativa prioriteter kan vara av intresse för både funktionella krav och kvalitetskrav. Ett kvalitetsrutnät används ofta när kvalitetskravs relativa viktighet inte är av intresse för intressterna. Relative priorities can be interesting for both functional requiremts and quality requiremts. A quality grid is normally used wh the relative importance of quality reqs is not of interest to the stakeholders. A6 sv Fullständighet av kravspecifikation kan förbättras gom att utföra Skapa-Läs-Uppdatera-Ta bort-översikt-kontroll. Missade kvalitetskrav kan kelt idtifieras gom att använda Skapa-Läs-Uppdatera-Ta bort-översikt-matris. The completess of a requiremts specification can be improved by performing a Create-Read-Update-Delete check. Missing quality requiremts can easily be idtified by the use of a CRUD matrix. 3

4 A7 sv När QUPER används för att specificera krav för prioriterade kvalitetsfaktorer så är det önskvärt att sätta målet under differtieringsbrytpunkt och precis ovanför kostnadsbarriär. Att nå kvalitetsnivå ovanför differtieringsbrytpunkt betyder att produkt har konkurrskraftig kvalitet för dna aspekt och står ut på marknad. Wh using QUPER for specifying requiremts for prioritized quality factors, it is desirable to set the target below the differtiation breakpoint and just above a cost barrier. Reaching a quality level above the differtiation breakpoint means that the product has competitive quality for this aspect and stands out on the market. A8 sv Användbarhet av ett system kan utvärderas gom användbarhetstestning. Användbarhetstester utförs vanligtvis bart på slutgiltiga (och kompletta) produktversion. The usability of a system can be assessed through usability tests. Usability tests are normally only performed on the final (and full) product version. A9 sv Agila krav är vanligtvis väldigt välutvecklade, dvs mogna och korrekta. Kunder ska vara aktivt gagerade i d agila utvecklingsprocess. Agile requiremts are usually well developed, i.e. mature and correct. Customers are to be actively involved in the agile developmt process. A10 sv Standardkrav är ofta inte lämpliga som plattformskrav. Plattformskrav är nära besläktade med kvalitetsaspketer så som hastighet och kapacitet. Standard requiremts are oft not suitable as platform requiremts. Platform requiremts are closely related to quality aspects, such as speed and capacity. 4

5 A11 sv Om företräde och koppling tas i beaktan i utgåveplanering så är det troligt att lösningsutrymmet blir mindre. Antalet möjliga utgåveplaner som uppfyller begränsningarna kommer gerellt sätt att bli mindre ju mer begränsningar som introduceras. If precedce and coupling is tak into account in release planning it is likely that the solution space becomes smaller. The number of possible release plans that full the constraints will in geral be less if more constraints are introduced. A12 sv Det är god praxis att undvika att uttrycka designbeslut i domännivåkrav. Att specificera syftet med viktiga krav tderar att minska risk för tvetydighet och feltolknigar. It is good practice to avoid expressing design decisions in the domain-level requiremts. Specifying the purpose behind important requiremts tds to decrease the risks of ambiguity and misinterpretation. A13 sv En kravspecifikation av god kvalitet bör dast innehålla designoberode krav. Attrapper och designnivåkrav är användbara för elicitering m inte specificering. A requiremts specification of good quality should only contain design-indepdt requiremts. Mock-ups and design-level requiremts are useful for elicitation but not for specification. A14 sv Kostnad/nyttobalans uppskattas nogrannare med intervallskala snarare än ordinalskala. Osäkerheterna är oftast stora, speciellt tidigt inom utveckling, och kostnad och nytta kan vara svåra att uppskatta i absoluta tal. The cost-befit balance is more accurately estimated by a ratio scale than by an ordinal scale. The uncertainties are oft large, especially in the early stages of developmt, and cost and befit can be hard to estimate in absolute numbers. 5

6 A15 sv En innehållskontroll av kravspecification uttryckt i ett formellts språk är inte särskilt lämplig för att idtifiera motsägelser. Att uttrycka krav i ett formell snarare än naturligt språk minskar möjlighet för icke-tekniska kunder att validera krav. A contts check of a requiremts specification expressed in a formal language is not very suitable for idtifying inconsistcies. Expressing requiremts in a formal rather than natural language decreases the ability for non-technical customers to validate the requiremts. A16 sv I projekt av typ löpande räkning så kommer man vanligtvis övers om krav i början av projektet och ändrar sedan inte på dem. Att förändra krav är dyrt och kräver ofta konsekvsanalys och påföljande justeringar av projektplaner. In projects of type time-and-material, requiremts are usually agreed at the start of the project and th not changed. Changing requiremts is costly and oft requires an impact analysis and subsequt adjustmt of project plans. A17 sv Spårbarhet i kravspecifikation faciliterar underhåll av krav. Konsekvs av kravförändringar kan hanteras klare med länkar mellan krav och gtemot design- och test-artefakter. Traceability in a requiremts specification facilitates maintaining the requiremts. The impact of requiremts changes can be more easily managed with links betwe requiremts and to design and test case artefacts. 6

7 A18 sv Inom marknadsdriv kravhantering så kan krav förkastas och tas bort från projektomfånget tidigt i kravprocess. Krav som inte är i linje med kunds krav eller önskemål kan förkastas och tas bort från projektomfånget. Within market-driv requiremts gineering requiremts may be rejected and removed from the scope of a project early on in the requiremts process. Requiremts that are not in-line with a customer s requiremts may be rejected and removed from the scope of a project. A19 sv Mål-domänspårning kan vara användbart för både elicitering och validering. Mål- och domänkrav som saknas i kravspecifikation kan idtifieras med mål-domänspårning. Goal-domain tracing can be useful for both elicitation and validation. Goal and domain requiremts that are missing in the requiremts specification can be idtified with goal-domain tracing. A20 sv Utgåveplanering kan underlättas gom att gruppera krav ligt berod. Med färre planeringsobjekt blir utgåveplanering klare. Release planning can be eased by clustering requiremts according to depdcies. With fewer planning objects release planning becomes simpler. A21 sv Specificering av domännivåkrav begränsar möjlighet att idtifiera alternativa kreativa lösningar under implemtation. Det är god praxis att specificera implemtationslösningar med krav på doomännivå. Specifying domain-level requiremts limits the possiblity of idtifying alternative creative solutions during implemtation. It is good practice to specify implemtation solutions with domain-level requiremts. 7

8 A22 sv Ett virtuellt fönster visar dataflödet mellan användargränssnittet och databas. Specifikation av datakrav med virtuella fönster fokuserar på relation mellan indata och utdata, och omvandling mellan dessa två. A virtual window shows the data flow betwe the user interface and the database. Specication of data requiremts with virtual windows focuses on the relation betwe input and output and the transformations that are made in-betwe these. A23 sv Bra kravhantering åtstadkommer samma höga nivå av fullständighet för alla delar av kravspecifikation. Både triviala och icke-triviala krav bör specifieras lika nogrannt för att bäst utnyttja det nerlagda arbetet. Good requiremts gineering achieves the same high level of completess for all parts of a requiremts specification. Both trivial and non-trivial requiremts should be specified with the same level of detail to make best use of the spt effort. A24 sv Kvalitetskrav är ofta svårare att specificera än datakrav. Kvalitetskrav påverkar ofta flera systemkomponter än datakrav och specifikation av kvalitetsnivåer görs ofta i relation till glidande skalor. Quality requiremts are oft more difcult to specify than data requiremts. Quality requiremts oft affect more system componts than data requiremts and the specication of quality levels is oft made in relation to sliding scales. A25 sv Det är ofta bättre att vänta med kravprioritering tills efter kravhanteringsprocess. En delmängd av krav brukar bli tydligare efterhand som kravhanteringsprocess fortlöper. It is oft better to wait with requiremts prioritization until after the requiremts gineering process. A subset of the requiremts normally become clearer as the requiremts gineering process proceeds. 8

9 A26 sv Enligt Laues så är käter med stängda frågor bra till att elicitera nya, okända produktkrav. Enkäter är lämpliga för att samla 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. A27 sv Öppna mätningar är lämpliga när kund inte känner till något bra sätt att mäta viss kvalitetsaspekt. Öppna mätningar förflyttar ansvaret för att definiera kvalitetsnivåerna till leverantör. Op metrics are suitable wh the customer does not know any good way to measure a certain quality aspects. Op metrics transfer the responsibility to de quality levels to the supplier. A28 sv Kvalitetskrav specificerar ofta mätningar ligt viss skala som beskriver hur väl viss systemfunktion bör fungera. Kvalitetskrav står i motsatts till icke-funktionella krav, eftersom de sare definierar icke-fungerande system betede. Quality requiremts oft specify measures on a scale that state how well a certain functionality of the system should to work. Quality requiremts are opposed to non-functional requiremts, as the latter oft defines a malfunctioning system behaviour. A29 sv Kravelicitering producerar ofta mellanliggande arbetsprodukter som stödjer ytterligare elicitering och specificering av krav. Mellanliggande arbetsprodukter hjälper kravanalytikern att förvärva domänkunskap och att förstå olika intressters perspektiv. Requiremts elicitation oft produces intermediate work products that support further elicitation and specifying requiremts. Intermediate work products help the requiremts analyst gain domain knowledge and understand differt stakeholders perspectives. 9

10 A30 sv En kravspecifikation beståde av lista över önskade produktegskaper kan användas för att välja och köpa in lämplig gerisk programvara. Krav på designnivå är sällan lämpliga för att specificera krav i ett projekt för upphandling av hyllprogramvara. A requiremts specification consisting of a list of desired features can be used to select a suitable COTS product. Design-level requiremts rarely suitable wh specifying requiremts in a COTS purchase project. 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 1 sidor max 10 poäng kvalitet, fullständig, verifierbar, spårbar, konsekvskontroll B2 Validation max 1 pages max 10 points quality, complete, verifiable, traceable, consistcy check B3 Prioritering max 1 sidor max 10 poäng kriterier, skala, tekniker, slug taktik, omprioritering B3 Prioritization max 1 pages max 10 points criteria, scale, techniques, shrewd tactics, re-prioritization 11

12 Skriftlig ttam i ETS170 Kravhantering FACIT DEL A 1

13 2

14 A1 sv Mängd av intresster inkluderar ofta system som interagerar med produkt. System som interagerar med produkt inkluderas ofta i ett kontextdiagram. D The set of stakeholders oft include systems interacting with the product. Systems that interact with the product are oft included in a context diagram. A2 sv Uppgiftsdemonstrationer är ofta bra teknik för att elicitera behov och aktuella problem. Intresster kan begära lösningar som inte adresserar de tänkta användarnas problem pga bristande förståelse för dessas behov och nuvarande arbetssätt. B Task demonstration is a oft a good technique for eliciting needs and prest problems. Stakeholders may demand solutions that do not address the problems of the intded users due to lack of understanding of their needs and currt way of working. A3 sv Kunder utan IT-bakgrund tycker ofta att datamodeller represterade som E/R diagram är svåra att förstå. Entiteter i ett domännivå E/R diagram motsvarar ofta data i d slutgiltiga produkt. B Customers without an IT background td to find data models represted as E/R diagrams hard to understand. Entities in a domain-level E/R diagram oft correspond to data tities in the final product. 3

15 A4 sv Brist på kvalitetskrav är ett vanligt problem både för traditionell och agil utveckling som ofta leder till kvalitetsproblem i d slutgiltiga produkt. Eftersom kvalitetskrav ofta ses som triviala att specifiera så fokuserar kravinsats istället på d icke-triviala krav aspekterna. Detta leder till att kvalitetskrav specificeras st under utvecklingsprocess. C The lack of quality requiremts is a common problem both for traditional and agile developmt that oft leads to quality issues in the final product. Since quality requiremts are se as trivial to specify, the requiremts efforts are rather focused on the non-trivial requiremts aspects, leaving quality requiremts until late in the developmt process. A5 sv Relativa prioriteter kan vara av intresse för både funktionella krav och kvalitetskrav. Ett kvalitetsrutnät används ofta när kvalitetskravs relativa viktighet inte är av intresse för intressterna. C Relative priorities can be interesting for both functional requiremts and quality requiremts. A quality grid is normally used wh the relative importance of quality reqs is not of interest to the stakeholders. A6 sv Fullständighet av kravspecifikation kan förbättras gom att utföra Skapa-Läs-Uppdatera-Ta bort-översikt-kontroll. Missade kvalitetskrav kan kelt idtifieras gom att använda Skapa-Läs-Uppdatera-Ta bort-översikt-matris. C The completess of a requiremts specification can be improved by performing a Create-Read-Update-Delete check. Missing quality requiremts can easily be idtified by the use of a CRUD matrix. 4

16 A7 sv När QUPER används för att specificera krav för prioriterade kvalitetsfaktorer så är det önskvärt att sätta målet under differtieringsbrytpunkt och precis ovanför kostnadsbarriär. Att nå kvalitetsnivå ovanför differtieringsbrytpunkt betyder att produkt har konkurrskraftig kvalitet för dna aspekt och står ut på marknad. D Wh using QUPER for specifying requiremts for prioritized quality factors, it is desirable to set the target below the differtiation breakpoint and just above a cost barrier. Reaching a quality level above the differtiation breakpoint means that the product has competitive quality for this aspect and stands out on the market. A8 sv Användbarhet av ett system kan utvärderas gom användbarhetstestning. Användbarhetstester utförs vanligtvis bart på slutgiltiga (och kompletta) produktversion. C The usability of a system can be assessed through usability tests. Usability tests are normally only performed on the final (and full) product version. A9 sv Agila krav är vanligtvis väldigt välutvecklade, dvs mogna och korrekta. Kunder ska vara aktivt gagerade i d agila utvecklingsprocess. D Agile requiremts are usually well developed, i.e. mature and correct. Customers are to be actively involved in the agile developmt process. A10 sv Standardkrav är ofta inte lämpliga som plattformskrav. Plattformskrav är nära besläktade med kvalitetsaspketer så som hastighet och kapacitet. D Standard requiremts are oft not suitable as platform requiremts. Platform requiremts are closely related to quality aspects, such as speed and capacity. 5

17 A11 sv Om företräde och koppling tas i beaktan i utgåveplanering så är det troligt att lösningsutrymmet blir mindre. Antalet möjliga utgåveplaner som uppfyller begränsningarna kommer gerellt sätt att bli mindre ju mer begränsningar som introduceras. A If precedce and coupling is tak into account in release planning it is likely that the solution space becomes smaller. The number of possible release plans that full the constraints will in geral be less if more constraints are introduced. A12 sv Det är god praxis att undvika att uttrycka designbeslut i domännivåkrav. Att specificera syftet med viktiga krav tderar att minska risk för tvetydighet och feltolknigar. B It is good practice to avoid expressing design decisions in the domain-level requiremts. Specifying the purpose behind important requiremts tds to decrease the risks of ambiguity and misinterpretation. A13 sv En kravspecifikation av god kvalitet bör dast innehålla designoberode krav. Attrapper och designnivåkrav är användbara för elicitering m inte specificering. E A requiremts specification of good quality should only contain design-indepdt requiremts. Mock-ups and design-level requiremts are useful for elicitation but not for specification. A14 sv Kostnad/nyttobalans uppskattas nogrannare med intervallskala snarare än ordinalskala. Osäkerheterna är oftast stora, speciellt tidigt inom utveckling, och kostnad och nytta kan vara svåra att uppskatta i absoluta tal. B The cost-befit balance is more accurately estimated by a ratio scale than by an ordinal scale. The uncertainties are oft large, especially in the early stages of developmt, and cost and befit can be hard to estimate in absolute numbers. 6

18 A15 sv En innehållskontroll av kravspecification uttryckt i ett formellts språk är inte särskilt lämplig för att idtifiera motsägelser. Att uttrycka krav i ett formell snarare än naturligt språk minskar möjlighet för icke-tekniska kunder att validera krav. B A contts check of a requiremts specification expressed in a formal language is not very suitable for idtifying inconsistcies. Expressing requiremts in a formal rather than natural language decreases the ability for non-technical customers to validate the requiremts. A16 sv I projekt av typ löpande räkning så kommer man vanligtvis övers om krav i början av projektet och ändrar sedan inte på dem. Att förändra krav är dyrt och kräver ofta konsekvsanalys och påföljande justeringar av projektplaner. D In projects of type time-and-material, requiremts are usually agreed at the start of the project and th not changed. Changing requiremts is costly and oft requires an impact analysis and subsequt adjustmt of project plans. A17 sv Spårbarhet i kravspecifikation faciliterar underhåll av krav. Konsekvs av kravförändringar kan hanteras klare med länkar mellan krav och gtemot design- och test-artefakter. A Traceability in a requiremts specification facilitates maintaining the requiremts. The impact of requiremts changes can be more easily managed with links betwe requiremts and to design and test case artefacts. 7

19 A18 sv Inom marknadsdriv kravhantering så kan krav förkastas och tas bort från projektomfånget tidigt i kravprocess. Krav som inte är i linje med kunds krav eller önskemål kan förkastas och tas bort från projektomfånget. B Within market-driv requiremts gineering requiremts may be rejected and removed from the scope of a project early on in the requiremts process. Requiremts that are not in-line with a customer s requiremts may be rejected and removed from the scope of a project. A19 sv Mål-domänspårning kan vara användbart för både elicitering och validering. Mål- och domänkrav som saknas i kravspecifikation kan idtifieras med mål-domänspårning. A Goal-domain tracing can be useful for both elicitation and validation. Goal and domain requiremts that are missing in the requiremts specification can be idtified with goal-domain tracing. A20 sv Utgåveplanering kan underlättas gom att gruppera krav ligt berod. Med färre planeringsobjekt blir utgåveplanering klare. A Release planning can be eased by clustering requiremts according to depdcies. With fewer planning objects release planning becomes simpler. A21 sv Specificering av domännivåkrav begränsar möjlighet att idtifiera alternativa kreativa lösningar under implemtation. Det är god praxis att specificera implemtationslösningar med krav på doomännivå. E Specifying domain-level requiremts limits the possiblity of idtifying alternative creative solutions during implemtation. It is good practice to specify implemtation solutions with domain-level requiremts. 8

20 A22 sv Ett virtuellt fönster visar dataflödet mellan användargränssnittet och databas. Specifikation av datakrav med virtuella fönster fokuserar på relation mellan indata och utdata, och omvandling mellan dessa två. E A virtual window shows the data flow betwe the user interface and the database. Specication of data requiremts with virtual windows focuses on the relation betwe input and output and the transformations that are made in-betwe these. A23 sv Bra kravhantering åtstadkommer samma höga nivå av fullständighet för alla delar av kravspecifikation. Både triviala och icke-triviala krav bör specifieras lika nogrannt för att bäst utnyttja det nerlagda arbetet. E Good requiremts gineering achieves the same high level of completess for all parts of a requiremts specification. Both trivial and non-trivial requiremts should be specified with the same level of detail to make best use of the spt effort. A24 sv Kvalitetskrav är ofta svårare att specificera än datakrav. Kvalitetskrav påverkar ofta flera systemkomponter än datakrav och specifikation av kvalitetsnivåer görs ofta i relation till glidande skalor. A Quality requiremts are oft more difcult to specify than data requiremts. Quality requiremts oft affect more system componts than data requiremts and the specication of quality levels is oft made in relation to sliding scales. A25 sv Det är ofta bättre att vänta med kravprioritering tills efter kravhanteringsprocess. En delmängd av krav brukar bli tydligare efterhand som kravhanteringsprocess fortlöper. D It is oft better to wait with requiremts prioritization until after the requiremts gineering process. A subset of the requiremts normally become clearer as the requiremts gineering process proceeds. 9

21 A26 sv Enligt Laues så är käter med stängda frågor bra till att elicitera nya, okända produktkrav. Enkäter är lämpliga för att samla information från många intresster. D According to Laues, surveys with closed questions are good for eliciting new, unknown product requiremts. Surveys are suitable for collecting information from many stakeholders. A27 sv Öppna mätningar är lämpliga när kund inte känner till något bra sätt att mäta viss kvalitetsaspekt. Öppna mätningar förflyttar ansvaret för att definiera kvalitetsnivåerna till leverantör. A Op metrics are suitable wh the customer does not know any good way to measure a certain quality aspects. Op metrics transfer the responsibility to de quality levels to the supplier. A28 sv Kvalitetskrav specificerar ofta mätningar ligt viss skala som beskriver hur väl viss systemfunktion bör fungera. Kvalitetskrav står i motsatts till icke-funktionella krav, eftersom de sare definierar icke-fungerande system betede. C Quality requiremts oft specify measures on a scale that state how well a certain functionality of the system should to work. Quality requiremts are opposed to non-functional requiremts, as the latter oft defines a malfunctioning system behaviour. A29 sv Kravelicitering producerar ofta mellanliggande arbetsprodukter som stödjer ytterligare elicitering och specificering av krav. Mellanliggande arbetsprodukter hjälper kravanalytikern att förvärva domänkunskap och att förstå olika intressters perspektiv. A Requiremts elicitation oft produces intermediate work products that support further elicitation and specifying requiremts. Intermediate work products help the requiremts analyst gain domain knowledge and understand differt stakeholders perspectives. 10

22 A30 sv En kravspecifikation beståde av lista över önskade produktegskaper kan användas för att välja och köpa in lämplig gerisk programvara. Krav på designnivå är sällan lämpliga för att specificera krav i ett projekt för upphandling av hyllprogramvara. B A requiremts specification consisting of a list of desired features can be used to select a suitable COTS product. Design-level requiremts rarely suitable wh specifying requiremts in a COTS purchase project. 11