E Both the proposition and the reason are false.

Transkript

1 Lunds Tekniska Högskola, Datavetskap Skriftlig ttam i ETSN15 Kravhantering kl , MA:9C&9D 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 Affärskunder som bart kommunicerar med användare av produkt tillhör d inre domän. D inre domän består av produkt och dess omgivande arbetsområde, vilk inkluderar affärsdomän (business domain"). Business customers that only communicate with the product via users of the product belong to the inner domain. The inner domain consists of the product and the surrounding work area, which includes the business domain. A2 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. A3 sv Krav på målnivå gör att leverantörer kan ta ett mindre ansvar för verksamhet kring produkt. Vilk kravnivå man väljer för kund-leverantörs kommunikation beror i stor utsträckning på vem som ska utföra uppdraget. Goal level requiremts able a supplier to take less responsibility for business activities around the product. The requiremts level used in customer-supplier communication depds largely on whom will perform the assignmt. A4 sv Det är lämpligt att skapa ett kontextdiagram mot slutet av ett projekt när implemtation är komplett. Det är ofta svårt för kunder att upptäcka om några avgörande gränssnitt saknas med hjälp av ett kontextdiagram. Ideally, a context diagram is created at the d of the project, wh the implemtation has be completed. Customers usually find it hard to see if any major interfaces are missing by using a context diagram. 2

3 A5 sv Användningsfall på designnivå är ofta mindre lämpliga än domännivåkrav för COTS-baserade system. COTS-baserade system behöver specificeras med detaljerade krav på designnivå. Design level use cases are oft less suitable for COTS based systems than domain level requiremts. COTS based systems need to be specified by detailed design-level requiremts. A6 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. A7 sv I ett virtuellt fönster (virtual window) visas dataflödet (data flow) mellan användargränsnittet och databas. Datakrav berör relation mellan input-output och d bearbetning som sker däremellan. A virtual window shows the data flow betwe the user interface and the database. Data requiremts are concerned with relationships betwe the input-output and the respective processing. A8 sv Beslutstabeller är väl lämpade för att specifiera användbarhetskrav. Besluttabeller stödjer precis beskrivning av affärsregler med alla möjliga kombinationer av villkor och utfall. Decision tables are well suited for specifying usability requiremts. Decision tables allow a precise description of business rules listing all the possible combinations of conditions and resulting actions. 3

4 A9 sv En datamodell, t.ex. ett E/R-diagram, kan användas för att ange kardinalitet i relationer mellan titeter. En fallgrop med virtuella fönster är att de kan misstolkas som del av d grafiska utformning av gränssnittet. A data model, e.g. an E/R diagram can be used for specifying cardinality of relations among itities. A pitfall with virtual windows is that they may be misinterpreted as part of the graphic design of the user interface. A10 sv Vid elicitering är det ofta bra att fråga intresster vilka uppgifter de utför. Uppgiftsdemonstrationer (task demos) är lämpliga för att motverka eliciterings barriär att användare ofta anger lösningar iställer för behov eller upplevda problem. During the elicitation it is oft good to ask stakeholders which tasks they perform. Task demos are suitable for mitigating the elicitation barrier of users oft specifying solutions instead of needs or expericed problems. A11 sv Öppna mål med kund förväntningar är ett bra sätt att specificera system responstid när tid är icke-kritisk. Öppna mål kräver inte att kund kan specifiera kvalitets mätning, t ex av systemets responstid. Op target with customer expectations is a good way to specify system response time wh the time is non-critical. Op targets do not require the customer to specify a quality measuremt, e.g. of system response time. A12 sv En väl gjord kvalitetsmatris (quality grid) förser utvecklare med konkreta kvalitetskrav. Med kvalitetsmatris (quality grid) kan man på ett systematiskt sätt ranka olika kvalitetsfaktorer. A well done quality grid provides a developer with concrete quality requiremts. Through a quality grid one can systematically rank differt quality factors. 4

5 A13 sv Forskning har visat att täckning av defekter ökar om flera grupper gör oberode granskningar. Validering med fokus på inkorrekta krav syftar till att upptäcka krav som inte återspeglar verkliga behov. Research has shown that defect coverage increases if several groups do indepdt inspections. Validation with a focus on incorrect requiremts aims to uncover requiremts that do not reflect real needs. A14 sv QUPER-modell kan användas för att fatta välgrundade beslut om kvalitetsnivåmål. QUPER-modell tillhandahåller riktlinjer för att utföra kostnad-värde-analys för kvalitetskrav. The QUPER model can be used to make informed decisions about the targeted quality level. The QUPER model provides guidelines for performing cost-befit analysis with respect to quality requiremts. A15 sv Kostnadsvyn i QUPER innehåller barriärers som represterar d icke-linjära relation mellan kvalitetsnivåer och kostnad. Före 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. The cost view in QUPER contains barriers represting the non-linear relation betwe the quality level and cost. Prior to reaching a barrier, the quality level can be improved at a relatively small cost, but at a barrier larger investmts are required to gain higher quality. A16 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 maintance of requiremts. The impact of requiremts changes can be more easily managed with links betwe requiremts to design and test case artefacts. 5

6 A17 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. I tidiga faser brukar kravinsats fokuseras på funktionella krav snarare än på kvalitetskrav. The lack of quality requiremts is a common problem for both traditional and for agile developmt that oft leads to quality issues in the final product. Requiremts efforts in the early phases td to be focused on functional requiremts rather than on quality requiremts. A18 sv Enligt studie av Cao och Ramesh har vissa kvalitetskrav, så som säkerhet och skalbarhet, tds att negligeras inom agil utveckling. Inom agil utveckling prioriteras ofta funktionella krav högre än kvalitetsaspekter eftersom prioritering ofta baseras på produktägars syn på produkts affärsvärde. According to a study by Cao and Ramesh, some quality requiremts, such as security and scalability, have a tdcy to be neglected within agile developmt. In agile developmt, functional requiremts td to be prioritized higher than quality aspects since prioritization is oft based on the product owner s view of business value. A19 sv Det är ofta bättre att vänta med att prioritera krav till i slutet av kravprocess. Krav inklusive dess prioriteter blir vanligtvis tydligare efterhand som kravprocess fortlöper. It is oft preferable to wait with requiremts prioritization until the d of the requiremts gineering process. The requiremts including their priority normally become clearer as the requiremts gineering process proceeds. 6

7 A20 sv När det finns stora glapp i kommunikation mellan marknads och utvecklingsavdelningar så påvisar detta att åsiktsskillnaderna mellan dessa inte är något stort problem inom marknadsdrivkravhantering. Snabba organisatoriska förändringar kan göra det svårt att etablera återuppringsbar kravprocess. Wh there are large gaps in the communication betwe the marketing and developmt units this indicates that the differces in the views are not an important issue in the market driv requiremts gineering (MDRE) context. Rapid organisational changes may hinder efforts to establish a repeatable requiremts gineering process. A21 sv Ett anvandbarhetstest gomfors med fordel som demonstration dar utvecklare visar hur systemet anvands. Anvandbarhetstestning ar formodlig mer verkningsfullt nar det galler att hitta verkliga anvandbarhetsproblem i jamforelse med heuristisk utvardering.. Preferably, a usability test should be carried out as a demonstration where the developer shows how to use the system. Usability test is more likely to be effective in idtification of usability problems compared to heuristic evaluation. A22 sv Berod mellan krav är ofta ojämnt fördelade. Under utgåveplanering kan berod ha stor påverkan på resultatet. Requiremts depdcies are oft unevly distributed. In release planning, requiremts depdcies can have a large impact on the result. 7

8 A23 sv Användbarhetstester utförs lämpligast vid slutet av utveckling för att påvisa att systemet är användarvänligt. Användbarhetstester behöver ett fullt fungerande system för att utföra testet på. Usability tests are best carried out at the d of developmt process to sure that the system is user fridly. Usability tests require a fully functioning system to perform the test on. A24 sv Kvalitet på ett ett system som består av flera integrerade delsystem kan ofta hanteras utan uttryckligt ansvar för d övergripande lösning. Risk för kund för helhetslösning kan minskas avsevärt gom integratör begränsar sitt ansvar till verifiering på delsystemnivå. The quality of a system consisting of multiple integrated subsystems can oft be managed without explicit responsibility for the overall solution. The customer s risks for the overall system can be significantly reduced by limiting the integrator s responsibility to verification at subsystem level. A25 sv Det lämplig att använda datauttryck (data expressions) för att beskriva datakrav både för experter och de flesta användare. Datauttryck är kompakta formler som kan visa struktur utan att gå in djupare i detalj. It is suitable to use data expressions to describe data requiremts for both the experts and majority of users. Data expression has compact notation that can show data structure without going into details. A26 sv Virtuella fönster är oftast inte användbara för att validera E/R modeller på ett adekvat sätt. Multiplicitet i relationer mellan titeter är normalt inte synliga i virtuella fönster. Virtual windows are usually not useful for validating that E/R models are adequate. The cardinality in relations betwe tities is normally not visible in virtual window. 8

9 A27 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. A28 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. A29 sv Op source-mjukvaran framträder kontinuerligt och följaktlig följer inte d formella programvarukravsprocess. Traditionellt har d formella mjukvarukravsteknikprocess haft roll i utveckling av föreslagna system före deras utveckling. Op source software (OSS) continuously emerges and, thus does not follow the formal software requiremts process. Traditionally, the formal software requiremts gineering process has served a role in the developmt of proposed systems prior to their implemtation. 9

10 A30 sv De flesta OSS-utvecklares nuvarande arbetssätt åtstadkommer hög nivå av strings gom att hantera krav med formell kravprocess. OSS-krav distribueras vitt över geografiska avstånd, och över tid, personer och artefakter som länkar dem. The majority of OSS developers are achieving a higher rigour within their existing practices by adopting formal requiremts gineering processes. OSS requiremts are distributed across space, time, people and the artifacts that link them. 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 Utgåve Planering max 1 sidor max 10 poäng berod, resursbegränsningar, optimering, viktad medeltillfredsställelse, "vad händer om-scarier, alfa-krav, osäkerhet B2 Release Planning max 1 pages max 10 points depdcies, resource constraints, optimization, weighted average satisfaction, åhat if-scarios, alfa requiremts, uncertainty 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