Eliciting Efficiency Requirements with Use Cases

checklists support completeness, the priorization questionnairesupports the focussedness of the NFRs.• a template, which embeds use cases into a full-fledgedrequirements document and provides specific placesfor documenting NFRs. This template supports traceabilityfrom NFRs to FRs, completeness and focussedness.• the use of rationales to justify each NFR. Using rationalessupports minimality of the set of NFRs.The paper is structured as follows. In Section 2, wesketch our terminology and explain the notation of thequality model. Then, we present our approach by way ofan example. Section 4 summarizes our experience andSection 5 discusses related work. We conclude with anoutlook on future work.2. TerminologyThis section describes the foundation of our approach.Subsection 2.1 points out a metamodel that describes thebasic concepts of our approach. Subsection 2.2 gives anoverview on the “quality model”, which instantiates partsof the metamodel.2.1. MetamodelThe metamodel (see Figure 1) describes the main conceptsof our approach. Our experience showed, that certaindecisions have to be made during the elicitation ofNFRs (e.g. does a quality aspect affect a user task, orrather AOs?). The concepts described in the metamodelsupport these decisions. In the following, we explain themost important elements.• A quality attribute (QA) is a non-functional characteristicof a system, user task, system task, or organization.Quality attributes of the organization include developmentprocess specific aspects.The distinction between different types of qualityattributes is important for our elicitation process. Eachtype of quality attribute is elicited differently (see Section3). QAs can be refined into further QAs. In addition,QAs can have positive or negative influences oneach other. A more detailed description of the types ofQAs and their relationships can be found in Section2.2.• A system (e.g., “wireless control and monitor system”)can be refined into a set of subsystems (e.g., “wirelessnetwork”, “mobile device”). Architectural requirements(e.g., “the system shall have a database”) constrainthe system.• We distinguish between two types of tasks: user tasksand system tasks. User tasks are tasks, a certain userhas to perform. They are supported by the system(e.g., “monitoring of certain machines”), but includesome user involvement. System tasks are tasks the systemperforms. In contrast to user tasks, the user is notinvolved in system tasks. Tasks can be refined intofurther tasks. User tasks can be refined into more finegraineduser tasks. Furthermore, user tasks can be refinedinto parts carried out by the user and systemtasks (e.g., a user task “monitoring machine x” is refinedinto a set of system tasks such as “system displaysalarm message if machine runs out of filling”).A task is described by one or more FRs.refined intoTaskdescribes1*1refined into11..*OrganizationUser TaskSystem TaskSystem2..*constrainsFunctional Requirement1111*****OrganizationQuality AttributeUser TaskQuality AttributeSystemTaskQuality AttributeSystemQuality AttributeArchitectural RequirementRequirement*Meansachieved by1refined into**influencesQuality Attribute* 1measured by*has influence on*constrains*1 **Non-functional Requirement1..*justifies1*1..*1..*MetricdeterminesValueRationale1 1..*Figure 1: The metamodel