Eliciting Efficiency Requirements with Use Cases

1. Organizational requirements1.1. Process requirements1.2. Stakeholder requirements2. Task descriptions2.1. UC diagram2.2. Textual UC description3. Task overspanning requirements3.1. Textual description of Task overspanning NFR´s Figure 5 shows the pre-required documents and theactivities to create them.Figure 4: Subset of the requirements template •The elicitation process is guided by our experience thatvarious entities (e.g., user task, system task) have differenttypes of QAs. Each NFR has to be elicited under considerationof this entity. In addition, if an entity is describedby one or a set of documentation elements (e.g., auser task is described by a use case, a system task is describedby a step of a use case), the NFR has to be documentedtogether with this entity.In the following sections, we describe the activities to beperformed within the elicitation process. We use examplesfrom a case study of the CWME project from Siemensabout a wireless framework for mobile services.The application enables up to eight users to monitor productionactivities, manage physical resources, and accessinformation within an industry plant. The user can receivestate data from the plant on his mobile device, send controldata from the mobile device to the plant components,position the maintenance engineer and get guidance to fixerrors on machines. The case study is based on a real systemand was provided by Siemens in the context of theEmpress project.3.1. PrerequisitesThe elicitation process is based upon the documentationof• the system´s functionality (behavior) described by usecases (Ucs),• the physical architecture, if available, and further implementationconstraints (e.g. constrained HWresourcesor constraints derived from the operatingsystems), and• assumptions about the average and the maximumamount of data used in the system. The amount of datafor each use case is determined under consideration ofthe amount of data for the entire system.Since some activities of the elicitation and documentationprocess are closely related to the functionality, the completenessof the NFRs is limited by the completeness ofthe FRs.As described above, some of the QAs are associated touser tasks and system tasks. Therefore, we recommenduse cases to describe the FRs. This seems to be beneficial,because QAs associated to user tasks can directly be relatedto use cases. QAs associated to system tasks can directlybe related to use case steps. However, we believethat our approach can be applied to other notations aswell.Activities “Prioritize” and “Chose quality models”:Many times, budget and time limitations oblige to prioritizeand select a subset of high-level QAs most importantfor a project. This activity is supported by aprioritisation questionnaire developed at IESE. Itbuilds a ranking order for the QAs described in ISO9126 (e.g., maintainability, efficiency, reliability, andusability). The questionnaire is described in more detailin [17]. Based on this ranking order, quality modelsfor certain high-level QAs relevant for the projectcan be chosen.• Activity “Elicit FRs”: In this step, the FRs are elicitedand documented in form of a graphical use casediagram.Each use case included in the diagram islater associated to NFRs that constrain QAs of usertasks. In addition, each use case is described textually.The textual description includes an interaction sequencebetween actor and system. This description allowsus later to associate NFRs that constrain QAs ofsystem tasks to use case steps.Questionnaire1. PrioritizePrioritizationlist2. ChooseQualitymodelsProjectQualitymodels3.Elicit funct.Req´sUCTxt UCdiagramDescriptionUCWorstcase4. DefineScenariosoverallWorstcaseTemplateAveragecaseData assumption5. DefineScenarioseach UCAveragecaseUC Data assum.Figure 5: Development of prerequisites6.DescribePhys.Sys. Arch.SysArch• Activities “Define scenarios” and “Define scenariosfor each UC”: In order to be able to imagine NFRs,maximum and average usage data for the overall system,as well as for each use case are elicited and documented.• Activity “Describe physical system architecture”:Some NFRs can only be elicited if the detailed physicalsystem architecture is known. So the architecture