Presentation on theme: "Chapter 5, Requirements Elicitation and Analysis"— Presentation transcript:
1 Chapter 5, Requirements Elicitation and Analysis
2 Last Lesson and Outlook Requirements ElicitationWhat are requirements?Functional vs. non-functional requirementsProcess of requirements elicitation1. Step: How to elicit requirementsAnalyzing existing systems (Tests, Manuals)InterviewsToday:ElicitationObservationsWrite Down Requirements ( Scenarios)Aggregate Scenarios ( Use Cases) and Refine Use CasesRequirement ValidationRequirements AnalysisMap Use Cases to the Analysis Object Model
3 ObservationPeople often find it hard to describe what they do because it is so natural to them.Actual work processes often differ from formal, prescribed processes Sometimes the best way to understand it is to observe them at workApproach: adopt methods e.g. from the social sciences which has proved to be valuable in understanding actual work processesSuitable Approach: Ethnography (Lecture ORE)
4 BrainstormingBrainstorming refers to the process of systematic and liberal generation of a large volume of ideas from a number of participants.Participants are encouraged to provide creative inputs in an atmosphere that is free of criticism and judgment from other participants. Unstructured brainstormingParticipants can give ideas as these come to mindQuite often not very efficientStructured brainstormingParticipants must follow a process model in order to make the gathering of inputs more orderly and more efficiently.
5 Roles in the Software Life-Cycle DeveloperA role that is concerned with specifying and implementing (sub)systemsClient (Customer)(End-)UserA role representing the people who will use the delivered systemA role representing the person or company commissioning paying for the development of the system
6 Process of Requirements Elicitation: The Requirements Elicitation Cycle TestsValidationValidationValidationObserving usersAs-Is ScenariosUse Cases + RefinementsPrototypesInterviewing users and clientsVisionary ScenariosValidationValidationStable Requirements Specification (System Specification)Functional RequirementsNon-Functional RequirementsUse CasesScenarios
7 Scenarios“A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]A concrete, focused, informal description of a single feature of the system used by a single actor.Developers and Users collaboratively write scenarios to gain a shared understanding of what the system should beScenarios can have many different uses during the software lifecycleRequirements Elicitation: As-is scenario, visionary scenarioClient Acceptance Test: Evaluation scenarioSystem Deployment: Training scenario.
8 Scenarios: Different Types As-is scenarioUsed in describing a current situationUsually used in re-engineering projectsThe user describes the systemVisionary scenarioUsed to describe a future systemUsually used in greenfield engineering and reengineering projectsCan often not be done by the user or developer alone brainstorming sessions, future workshopEvaluation scenarioUser tasks against which the system is to be evaluatedTraining scenarioStep by step instructions that guide a novice user through a systemRe-design and/or re-implementation of an existing system using newer technologyHelps to reveal problems and hints that exist in the current situation
9 Scenarios: Heuristics for finding Scenarios Ask yourself or the client the following questionsWhat are the primary tasks that the system needs to perform?What data will the actor create, store, change, remove or add in the system?What external changes does the system need to know about?What changes or events will the actor of the system need to be informed about?However, don’t rely on questionnaires alone.Insist on task observation if the system already exists (interface engineering or reengineering)Ask to speak to the end user, not just to the client
10 Scenarios: Example - Accident Management System What needs to be done to report an incident?What do you need to do if a person reports “Warehouse on Fire?”Who is involved in reporting an incident?Can the system cope with a simultaneous incident report “Warehouse on Fire?”What kind of questions could be asked for such as systmes.
11 Scenario: Example - Warehouse on Fire Bob, driving down main street in his patrol car notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from her car by using the SYSTEM.Alice enters the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.Alice received the acknowledgment and the ETA.
12 Scenarios: Observations about “Warehouse on Fire” Concrete scenarioDescribes a single instance of reporting a fire incident.Does not describe all possible situations in which a fire can be reported.Participating actorsBob, Alice and John
13 Process of Requirements Elicitation: The Requirements Elicitation Cycle TestsValidationValidationValidationObserving usersAs-Is ScenariosUse Cases + RefinementsPrototypesInterviewing users and clientsVisionary ScenariosThe validation process can be improved by implementing prototypesPrototypes are used to simulate selected functions of the system to the client, so that users have a better understanding of what the system should be. Also used to evaluate the requirementsValidationValidationStable Requirements Specification (System Specification)Functional RequirementsNon-Functional RequirementsUse CasesScenarios
14 Use Cases: Next goal, after the scenarios are formulated Find all the use cases in the set of scenarios that completely represent the future system.Abstractions of many scenariosExample: “Report Emergency” is a candidate for a use case from the first paragraph of the scenarioDescribe each of these use cases in more detailParticipating actorsDescribe the Entry ConditionDescribe the Flow of EventsDescribe the Exit ConditionDescribe ExceptionsDescribe Special Requirements (Constraints, non-functional Requirements
15 Use Cases: DefinitionA Use Case describes a function (behaviour) provided by the system in terms of flowing events, including interaction with actorsIt is initiated by an actorEach use case has a nameGraphical Notation: An oval with the name of the use caseA Use Case describes or a function or behaviour provided by the system in terms of flowing events. Since a use case is initiated by an actor, we can also indicate that a use case realizes the external behaviour of a system as seen from the users point of view. Consequently, a use case does not only model the internal flow of control, but also the communicatin between actors and the function being modelled by the use caseReportEmergencyUse Case Model: The set of all use cases specifying the complete functionality of the system
16 Use Cases: Communication relationships between actors and use cases DispatcherFieldOfficerOpenIncidentReportEmergencyA line indicates which users are capable of invoking a use caseAllocateResourcesUsers, RolesWhich user can invoke which use case
17 Use Cases Textual Representation Template for a textual use caseUse case nameParticipating ActorsFlow of EventsEntry ConditionExit ConditionQuality Requirements
18 Use Cases Textual Representation Example (Excerpt, see [Bruegge&Dutoit, 2004], p. 135)Initialized by an actorUse case nameParticipating ActorsFlow of EventsEntry ConditionExit ConditionQuality RequirementsReportEmergencyInitiated by FieldOfficer, communicates with DispatcherThe FieldOfficer activates the ReportEmergency function on this terminalSYSTEM responds by presenting a dialog form to the FieldOfficerFieldOfficer completes and submitts the formSYSTEM receives the form, evaluates the inform- ation in interaction with a Dispatcher and sends an acknowledgeInitialized by the systemIndented events: denotes who has initialized this step within the entire flow of control.Writing guide how one can write a use caseThe FieldOfficer is logged into the SYSTEMThe FieldOfficer receives an acknowledgeThe FieldOfficer‘s request is acknowlegded within 30 seconds.
19 Use Cases: Associations A use case model consists of use cases and use case associationsA use case association is a relationship between use casesImportant types of use case associations: Include, Extends, GeneralizationIncludeA use case uses another use case (“functional decomposition”)ExtendsA use case extends another use caseGeneralizationAn abstract use case has different specializations
20 Use Cases: <<Include>> Functional Decomposition Problem:A function in the original problem statement is too complex to be solvable immediately or the function is already existingSolution:Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use casesManageIncidentReducing complexity by functional decomposition<<include>>CreateIncidentHandleIncidentCloseIncident
21 Use Cases: <<Extend>> Association for Use Cases Problem:The functionality in the original problem statement needs to be extended (optional behaviour, exceptional behaviour)Solution:An extend association from a use case A to a use case B indicates that use case B is an extension of use case A.ReportEmergencyFieldOfficer<<extend>>Base UseCaseSupplierUse CaseConnectionDownNote: (a) The base use case can be executed without the use case extension in extend associations. (b) The Extending UC knows when it should be executed.
22 Use Cases in a textual way Describing <<include>> and <<extend>> ReportEmergency<<include>>EvaluateInfo<<include>> relationshipFlow of Events...FieldOfficer completes and submitts the formSYSTEM receives the form, evaluates the information (by using Use Case EvaluateInfo) being received and sends an acknowledge<<extend>> relationshipReportEmergency<<extend>>ConnectionDownThe ConnectionDown use case extends any use case in which the connection between the FieldOfficer and the SYSTEM can be lostThe FieldOfficer is notified that the connection is brokenEntry ConditionFlow of Events
23 Anticipating Change: Extension Points ReportEmergencyEntry ConditionThe Selection extension point is reached in the extended use case.Open the help system and show context help for the current selection.Flow of Eventsexample taken from the OMG Specification of the Unified Modeling Language: Superstructure version 2.0
24 Use Cases: Generalization association in use cases Problem:You would like to model a specialized use case from an existing use case.Solution:The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior.CheckPasswordParentCaseChildUse CaseValidateUserCheckFingerprint
25 Use Cases: How do I find use cases? Refine a single scenario of the systemDiscuss it in detail with the user to understand the user’s assumption about the systemDefine many not-very-detailed scenarios to define the scope of the system.Discuss the scope with the userUse illustrative prototypes (mock-ups) as visual supportHowever: interface design is no integral part of use casesPresent multiple and different alternative scenariosParticularize all scenarios in more detailMake abstractions over all identified scenarios (use cases)Validate with user
26 Requirements Validation (1/3) Requirements ElicitationRequirements validation is a critical step in the development process, usually during requirements engineering or requirements analysis. Also at delivery (client acceptance test).Requirements validation criteria:CompleteAll possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the systemConsistentThere are no two functional or nonfunctional requirements that contradict each otherUnambiguousRequirements can not be interpreted in mutually exclusive waysCorrectThe requirements represent the client’s viewConsistent:FieldOfficer should, on the one hand, report an incident on the way, but should at the same time be responsible to acknowledge the report and to allocate the fire unti. introduce an other actor (Dispatcher) who takes over this task
27 Requirements Validation (2/3) Requirements ElicitationMore Requirements validation criteriaRealisticRequirements can be implemented and deliveredVerifiableRequirements can be checkedNeeds an exact description of the requirementsWith respect to deadline and budget restrictions
28 Requirements Validation (3/3) Requirements ElicitationProblem with requirements validationRequirements change very fast during requirements elicitation.Tool support for managing requirementsStore requirements in a shared repositoryProvide multi-user accessAllow for change managementAutomatically create a system specification document from the repositoryProvide traceability throughout the project lifecycle
29 What is Requirements Engineering? (ctd.) Requirements ElicitationRequirements Analysis+Basis for DiscussionsDefinition of the system in terms understood by the customer (“Problem Description”)Design basis for developersTechnical specification of the system in terms understood by the developer (“Problem Specification”) System Specification Analysis Model
30 Analysis and Analysis Model Analysis focus on producing a model of the system (analysis model) which is:CorrectCompleteConsistentUnambiguousStructuring and formalizing the requirementsNew details are added, insights and errors may be discovered Update of System Specification often necessaryAnalysis Model is basis for further developmentAnalysis Object ModelDynamic Model
31 Process of Requirements Analysis ProblemStatementRequirementsElicitationSystem specification: functional and non-functional requirementsRequirementsAnalysisAnalysis Model: dynamic modelAnalysis object model
32 Analysis Object Model vs. Dynamic Model System from the user’s perspectiveClasses and Objects (User-Level Concepts, no software classes!)AttributesOperationsAssociations can serve as visual dictionary of application domainDynamic ModelModels the behavior of the systemResponsibilities, Flow of ControlI.e. usingStatechart Diagram (1 Object)Sequence diagram (Flow of control, relationships)
33 From Requirements Specification to the Analysis Object Model Important Objects and ClassesAttributesApplication specificAttributes in one system can be classes in anotherTurning Attributes into ClassesOperationsDetection of operationsGeneric operations: Get/Set, General world knowledge, design patternsDomain operations: Dynamic model, Functional modelAssociations (Relations)Generic associationsCanonical associationsPart of- Hierarchy (Aggregation)Kind of-Hierarchy (Generalization)Requirements ElicitationSpecificationScenariosUse CasesFunctional RequirementsConditionsExceptions
34 Analysis Object Model: Class Identification (1/3) Identify and describe all important entities in the systemSteps during object modeling1. Class identificationBased on the fundamental assumption that we can find abstractions2. Find the attributes3. Find the methods4. Find the associations between classesWhat happens if we find the wrong abstractions?Iterate and correct the modelOrder of steps secondary, only a heuristic (Iteration is important)Basic assumptionWe can find the classes for a new software system (Forward Engineering)We can identify the classes in an existing system (Reverse Engineering)
35 Analysis Object Model: Class Identification (2/3) Objects are not just found by taking a picture of a scene or domainThe application domain has to be analyzedDepending on the purpose of the system different objects might be foundHow can we identify the purpose of a system?Scenarios and use casesAnother important problem: Define system boundaryWhat object is inside, what object is outside?
36 Analysis Object Model: Object vs. Class Object (instance): Exactly one thingThis lecture on Software Engineering on November 15 from 14:30 -16:00A class describes a group of objects with similar propertiesGame, tournament, mechanic, car, databaseObject diagram: A graphic notation for modeling objects, classes and their relationships ("associations")Class diagramTemplate for describing many instances of dataUseful for taxonomies, patterns, schemata...Instance diagramA particular set of objects relating to each other.Useful for discussing scenarios, test cases and examples
37 Analysis Object Model: Class Identification (3/3) Abbott Textual Analysis, 1983, (noun-verb analysis)Set of heuristics for identifying objects, attributes and associations from a requirements specificationMapping of parts of speech to model componentsNouns are good candidates for classesVerbs are good candidates for operationsIn the problem statement (originally proposed, but rarely works if the problem statement is large (more than 5 pages)Quality depends on style of writingToo many nounsIn the flow of events of use cases (preferable)Small list of candidate objectsFocus on user terms (+)Quality of object model depends on the style of writing of the analyst, imprecise lanugage, many nounsWorks well for short description for generating a small list of candidate objects
38 Mapping parts of speech to object model components [Abbott, 1983] Part of speechModel componentExampleProper nounobjectJim SmithCommon nounclassToy, dollDoing verbmethodBuy, recommendbeing verbinheritanceis-a (kind-of)Verbs which take an object are usually called transitive verbs. Verbs which do not take an object are usually called intransitive verbs.having verbaggregationhas anmodal verbconstraintmust beadjectiveattribute3 years oldtransitive verbmethodenterintransitive verbmethod (event)depends on
39 Analysis Object Model: Identifying Participating Objects Pick a use case and look at its flow of eventsFind terms that developers or users need to clarify in order to understand the flow of eventsLook for recurring nouns (e.g., Incident),Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource),Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan),Identify data sources or sinks (e.g., Printer)Be prepared that some objects are still missing and need to be found:Model the flow of events with a sequence diagramAlways use the user’s terms
40 Analysis Object Model: Example – Analyzing The Flow of events (1/2) The customer enters the store to buy a toyIt has to be a toy that his daughter likes and it must cost less than 50 Euro.An assistant helps him.The suitability of the toy depends on the age of the child.His daughter is 8 years oldThe assistant recommends a type of toy, namely the board game “Monopoly“Not a good description, but okay as an example
41 Analysis Object Model: Example – Analyzing with Abbott’s (2/2) Grammatical constructUML Component“Monopoly"Proper nounObject“toy“, “board game”Common nounclass"8 years old"AdjectiveAttribute“enters"verbMethod“depends on…."Intransitive verbMethod“is a" ,“either..or",“type of…"Classifying verbInheritance"Has a ", “consists of"Having VerbAggregation“must be", “less than…"modal VerbConstraint