Eliciting Efficiency Requirements with Use Cases

More documents

Recommendations

Info

must be elicited and documented, whenever it is available.3.2. Elicitation and documentation of NFRsFigure 6 shows the activities and documents needed toelicit and consolidate NFRs. A checklist that is derivedfrom the quality model as described in Section 2.2 guideseach activity. Activities are explained in more detail inthe following. We distinguish between different elicitationactivities: user task NFR elicitation, system task NFRelicitation and system NFR elicitation. Each activity focuseson eliciting NFRs that constrain one certain type ofQA (i.e., organization QA, user task QA, system task QA,and system QA). The user task NFR elicitation is basedon use cases. The system task NFR elicitation is based onthe interaction sequence described for each use case. Thesystem NFR elicitation is based on physical subsystemsand interaction sequences.Activity “Elicit organizational NFRs”In this activity, NFRs are elicited that constrain QAs ofthe organization. The customer, for example, might havecertain requirements concerning the organizational structureand experience of a supplier. The customer is askedto phrase these requirements. This process is guided by aset of clues in form of a checklist. These clues suggestthinking about domain-experience, size, structure or ageof the supplier organization, as well as required standards(e.g. RUP), activities (e.g. inspections), documents or notations(e.g. statecharts). In our case study, some of therequirements expressed were:• “The supplier needs at least three years of experiencein the domain of access-control.“• “The supplier has to create a specification document.”To avoid unnecessarily design decisions, the customer isinstructed to scrutinize this NFR again, just as Socratesused to try to get to the bottom of statements over andover. This form of Socratic dialogue serves to uncover therationale behind that NFR and prevents the customer fromconstraining the system unnecessarily. NFRs are reformulateduntil they reflect the rationale. It is a good practiceto document the rationale as well [5].As soon as the now elicited and justified NFRs arephrased in a measurable way (this is the case if the metricattached to the QA in the quality model can be applied tothe requirement), it is documented in the chapter “organizationalrequirements” of the template.Activity “Elicit user task NFRs”In this activity, NFRs are elicited that constrain QAs ofuser tasks. In our case study, the QA “usage time” includedin the quality model is a user task QA. These QAsare documented for each use case included in the use casediagram, because each use case represents a user task. Asshown in Figure 7, NFRs are added to use cases with thehelp of notices.In our case study the requirement “the use case shall beperformed within 30 min.” was attached to the use case“Handle alarm”. Again, a justification as described aboveis performed to prevent unnecessary anticipated designdecisions. The resulting rationale “breakdown of plantlonger than 30 min. is too expensive” is documented inparenthesis behind the NFR.UCTxt UCdiagramDescriptionUCWorstAveragecasecaseUC ScenariosSystemArchitectureOrgaQA´sUsertaskQA´sSystemtaskQA´sSystemQA´sFigure 7: Use cases with attached user task NFRs1. ElicitOrgaNFR´sProcessCheckList 1Stakeholder2. ElicitUser taskNFR´sRefinedUCdiagramCheckList 2Txt UCDescr.Of NFR´s3. ElicitSystem taskNFR´sConsolidateCheckList 3TxtDescriptionUC overspNFR´sCheckList 54. ElicitSystemNFR´sFigure 6: Elicitation process for NFRsCheckList 4DependenciesBetweenQAsActivity “Elicit system task NFRs”In this activity, NFRs are elicited that constrain QAs ofsystem tasks. The elicitation is based on the detailed interactionsequence (also called flow of events) documentedin the use case. For this activity, maximum andaverage usage data (Figure 5 shows the developmentprocess of this information) are needed. The checklistgives clues of thinking of scenarios where the maximumand the average amount of data are processed in the system.With these scenarios in mind, every step and everyexception described by the use case description arechecked. Elicited NFRs are documented. Figure 8 showsthe textual description of the use case “handle alarm”. It
describes that the system shows an alarm and where thealarm was produced. As reaction to this, the user acknowledgesthe alarm, so other users know s/he is takingcare of it.As Figure 10 shows, the NFR field of the use case descriptionis segmented into NFRs related to every physicalsubsystem.Figure 10: UC with attached system NFRsFigure 8: UC steps with attached system task NFRsAs a result of the elicitation and documentation process,NFRs that constrain the system task QA “response time”were documented. The NFR “at least in 5 sec.” was attachedto the use case step 2 “System shows alarm andwhere the alarm was produced” and the NFR “just oneclick” was attached to the users reaction described in usecase step 3. Both requirements were documented in theNFRs field within the textual description of the use case,after being justified by the customer in the Socratic dialogue.The rationale lead to the statement, that the NFRselicited were assumed times only and could be changed, ifnecessary. As shown in Figure 7 and Figure 8, the rationalewas documented in parenthesis.Activity “Elicit system NFRs”In this activity, NFRs are elicited that constrain QAs ofthe system and subsystems. In this activity, again maximumand average usage data is needed. Additionally, thearchitecture of the physical subsystems is used, if available.The subsystems and architecture constraints on ourcase study are shown in Figure 9.Figure 9: Constraints on system-architectureThe checklist gives instructions on how to consider thescenarios while phrasing NFRs for each use case descriptionand physical subsystem of the system architecture.In the use case “handle alarm”, NFRs for the QA “capacity”could only be phrased for the physical subsystem“PDA”. The subsystem shall have a maximum capacity of64 MB and shall be able to handle up to 50 alarms at thesame time. The rationale for this NFR is the need for usageof standard components available at the consumermarket. This rationale is documented as well.The QA “throughput” does only apply to the subsystem“Network” by definition. Our experience shows, thatsome QAs are related to only a subset of subsystems. Thisrelationship is documented in the quality model.The elicited NFRs for single subsystems are documentedwithin the textual use case description as well as in thesection “use case overspanning textual description ofNFRs”. This is done to be able to consolidate the requirementsover several use cases.Activity “Consolidate”In this activity, the NFRs are analysed for conflicts. Thisactivity includes two sub-activities. In the first, NFRs forone physical subsystem are analysed over all use cases.The checklist gives hints on how to identify conflicts andhow to solve them. It has to be checked, for example,whether NFRs can be achieved if use cases are executedin parallel. In the second sub-activity, NFRs that constraindifferent QAs are validated under consideration ofthe dependencies documented within the quality model.The consolidation activity discovered an important conflictbetween the determined throughput requirements andthe defined hardware constraints. As shown in Figure 10one of the throughput requirements stated:• “The network between secondary database and PDAshall be able to deal in worst case with 8 people thatdownload 1 doc (size of 8 docs constrained to
Page 1 and 2: Eliciting Efficiency Requirements w
Page 3: • A NFR describes a certain value
Page 9 and 10: use the graph to represent dependen

Eliciting Efficiency Requirements with Use Cases

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?