Presentation is loading. Please wait.

Presentation is loading. Please wait.

Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Elicitation.

Similar presentations


Presentation on theme: "Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Elicitation."— Presentation transcript:

1 Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Elicitation and Analysis

2 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2 Last Lesson and Outlook  What are requirements?  Functional vs. non-functional requirements  Process of requirements elicitation  1. Step: How to elicit requirements  Analyzing existing systems (Tests, Manuals)  Interviews Today:  Elicitation  Observations  Write Down Requirements (  Scenarios)  Aggregate Scenarios (  Use Cases) and Refine Use Cases  Requirement Validation  Requirements Analysis  Map Use Cases to the Analysis Object Model Requirements Elicitation

3 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 3 Observation  People 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 work  Approach: adopt methods e.g. from the social sciences which has proved to be valuable in understanding actual work processes  Suitable Approach: Ethnography (Lecture ORE)

4 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 4 Brainstorming  Brainstorming 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 brainstorming  Participants can give ideas as these come to mind  Quite often not very efficient  Structured brainstorming  Participants must follow a process model in order to make the gathering of inputs more orderly and more efficiently.

5 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 5 Roles in the Software Life-Cycle (End-)User Developer Client (Customer) A role representing the people who will use the delivered system A role that is concerned with specifying and implementing (sub)systems A role representing the person or company commissioning paying for the development of the system

6 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 6 Process of Requirements Elicitation: The Requirements Elicitation Cycle Observing users Interviewing users and clients As-Is Scenarios Visionary Scenarios Use Cases + Refinements Prototypes Validation Tests Functional Requirements Non-Functional Requirements Use Cases Scenarios Stable Requirements Specification (System Specification) Validation

7 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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 be  Scenarios can have many different uses during the software lifecycle  Requirements Elicitation: As-is scenario, visionary scenario  Client Acceptance Test: Evaluation scenario  System Deployment: Training scenario.

8 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 8 Scenarios: Different Types  As-is scenario  Used in describing a current situation  Usually used in re-engineering projects  The user describes the system  Visionary scenario  Used to describe a future system  Usually used in greenfield engineering and reengineering projects  Can often not be done by the user or developer alone  brainstorming sessions, future workshop  Evaluation scenario  User tasks against which the system is to be evaluated  Training scenario  Step by step instructions that guide a novice user through a system

9 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 9 Scenarios: Heuristics for finding Scenarios  Ask yourself or the client the following questions  What 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 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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?”

11 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 12 Scenarios: Observations about “Warehouse on Fire”  Concrete scenario  Describes a single instance of reporting a fire incident.  Does not describe all possible situations in which a fire can be reported.  Participating actors  Bob, Alice and John

13 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 13 Process of Requirements Elicitation: The Requirements Elicitation Cycle Observing users Interviewing users and clients As-Is Scenarios Visionary Scenarios Use Cases + Refinements Prototypes Validation Tests Functional Requirements Non-Functional Requirements Use Cases Scenarios Stable Requirements Specification (System Specification) Validation

14 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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 scenarios  Example: “Report Emergency” is a candidate for a use case from the first paragraph of the scenario  Describe each of these use cases in more detail  Participating actors  Describe the Entry Condition  Describe the Flow of Events  Describe the Exit Condition  Describe Exceptions  Describe Special Requirements (Constraints, non-functional Requirements

15 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 15 ReportEmergency Use Cases: Definition  A Use Case describes a function (behaviour) provided by the system in terms of flowing events, including interaction with actors  It is initiated by an actor  Each use case has a name  Graphical Notation: An oval with the name of the use case Use Case Model: The set of all use cases specifying the complete functionality of the system

16 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 16 Use Cases: Communication relationships between actors and use cases ReportEmergency FieldOfficer Dispatcher OpenIncident AllocateResources Users, Roles Which user can invoke which use case

17 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 17 Use Cases Textual Representation  Template for a textual use case Use case name Participating Actors Flow of Events Entry Condition Exit Condition Quality Requirements

18 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 18 Use Cases Textual Representation  Example (Excerpt, see [Bruegge&Dutoit, 2004], p. 135) Use case name Participating Actors Flow of Events Entry Condition Exit Condition Quality Requirements ReportEmergency Initiated by FieldOfficer, communicates with Dispatcher 1.The FieldOfficer activates the ReportEmergency function on this terminal 2.SYSTEM responds by presenting a dialog form to the FieldOfficer 3.FieldOfficer completes and submitts the form 4.SYSTEM receives the form, evaluates the inform- ation in interaction with a Dispatcher and sends an acknowledge The FieldOfficer is logged into the SYSTEM The FieldOfficer receives an acknowledge The FieldOfficer‘s request is acknowlegded within 30 seconds. Initialized by an actor Initialized by the system

19 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 19 Use Cases: Associations  A use case model consists of use cases and use case associations  A use case association is a relationship between use cases  Important types of use case associations: Include, Extends, Generalization  Include  A use case uses another use case (“functional decomposition”)  Extends  A use case extends another use case  Generalization  An abstract use case has different specializations

20 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 20 Use Cases: > Functional Decomposition  Problem:  A function in the original problem statement is too complex to be solvable immediately or the function is already existing  Solution:  Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases ManageIncident CreateIncidentHandleIncidentCloseIncident > Reducing complexity by functional decomposition

21 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 21 Use Cases: > 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. Note: (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. ReportEmergency FieldOfficer > Base Use Case Supplier Use Case ConnectionDown

22 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 22 Use Cases in a textual way Describing > and >... 3.FieldOfficer completes and submitts the form 4.SYSTEM receives the form, evaluates the information (by using Use Case EvaluateInfo) being received and sends an acknowledge  > relationship Flow of Events The ConnectionDown use case extends any use case in which the connection between the FieldOfficer and the SYSTEM can be lost 1. The FieldOfficer is notified that the connection is broken Flow of Events Entry Condition Report Emergency > Evaluate Info Report Emergency > Connection Down

23 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 23 Anticipating Change: Extension Points ReportEmergency example taken from the OMG Specification of the Unified Modeling Language: Superstructure version 2.0 The Selection extension point is reached in the extended use case. 1. Open the help system and show context help for the current selection. Entry Condition Flow of Events

24 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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. ValidateUser CheckPassword CheckFingerprint Parent Case Child Use Case

25 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 25 Use Cases: How do I find use cases?  Refine a single scenario of the system  Discuss it in detail with the user to understand the user’s assumption about the system  Define many not-very-detailed scenarios to define the scope of the system.  Discuss the scope with the user  Use illustrative prototypes (mock-ups) as visual support  However: interface design is no integral part of use cases  Present multiple and different alternative scenarios  Particularize all scenarios in more detail  Make abstractions over all identified scenarios (use cases)  Validate with user

26 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 26 Requirements Validation (1/3)  Requirements 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:  Complete  All possible scenarios, in which the system can be used, are described, including exceptional behavior by the user or the system  Consistent  There are no two functional or nonfunctional requirements that contradict each other  Unambiguous  Requirements can not be interpreted in mutually exclusive ways  Correct  The requirements represent the client’s view Requirements Elicitation

27 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 27 Requirements Validation (2/3)  More Requirements validation criteria  Realistic  Requirements can be implemented and delivered  Verifiable  Requirements can be checked  Needs an exact description of the requirements Requirements Elicitation

28 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 28 Requirements Validation (3/3)  Problem with requirements validation  Requirements change very fast during requirements elicitation.  Tool support for managing requirements  Store requirements in a shared repository  Provide multi-user access  Allow for change management  Automatically create a system specification document from the repository  Provide traceability throughout the project lifecycle Requirements Elicitation

29 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 29 What is Requirements Engineering? (ctd.) Requirements Engineering Requirements Elicitation + Requirements Analysis Design basis for developers Technical specification of the system in terms understood by the developer (“Problem Specification”) Basis for Discussions Definition of the system in terms understood by the customer (“Problem Description”)  System Specification  Analysis Model

30 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 30 Analysis and Analysis Model  Analysis focus on producing a model of the system (analysis model) which is:  Correct  Complete  Consistent  Unambiguous  Structuring and formalizing the requirements  New details are added, insights and errors may be discovered  Update of System Specification often necessary  Analysis Model is basis for further development  Analysis Object Model  Dynamic Model

31 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 31 Process of Requirements Analysis Requirements Analysis Requirements Elicitation Problem Statement System specification: functional and non-functional requirements Analysis Model: dynamic model Analysis object model

32 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 32 Analysis Object Model vs. Dynamic Model  Analysis Object Model  System from the user’s perspective  Classes and Objects (User-Level Concepts, no software classes!)  Attributes  Operations  Associations  can serve as visual dictionary of application domain  Dynamic Model  Models the behavior of the system  Responsibilities, Flow of Control  I.e. using  Statechart Diagram (1 Object)  Sequence diagram (Flow of control, relationships)

33 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 33 From Requirements Specification to the Analysis Object Model Requirements Elicitation Specification Scenarios Use Cases  Functional Requirements Conditions Exceptions  Important Objects and Classes  Attributes  Application specific  Attributes in one system can be classes in another  Turning Attributes into Classes  Operations  Detection of operations  Generic operations: Get/Set, General world knowledge, design patterns  Domain operations: Dynamic model, Functional model  Associations (Relations)  Generic associations  Canonical associations  Part of- Hierarchy (Aggregation)  Kind of-Hierarchy (Generalization) Analysis Object Model

34 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 34 Analysis Object Model: Class Identification (1/3)  Identify and describe all important entities in the system  Steps during object modeling  1. Class identification  Based on the fundamental assumption that we can find abstractions  2. Find the attributes  3. Find the methods  4. Find the associations between classes  What happens if we find the wrong abstractions?  Iterate and correct the model  Order of steps secondary, only a heuristic (Iteration is important)  Basic assumption  We can find the classes for a new software system (Forward Engineering)  We can identify the classes in an existing system (Reverse Engineering)

35 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 35 Analysis Object Model: Class Identification (2/3)  Objects are not just found by taking a picture of a scene or domain  The application domain has to be analyzed  Depending on the purpose of the system different objects might be found  How can we identify the purpose of a system?  Scenarios and use cases  Another important problem: Define system boundary  What object is inside, what object is outside?

36 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 36 Analysis Object Model: Object vs. Class  Object (instance): Exactly one thing  This lecture on Software Engineering on November 15 from 14:30 -16:00  A class describes a group of objects with similar properties  Game, tournament, mechanic, car, database  Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations")  Class diagram  Template for describing many instances of data  Useful for taxonomies, patterns, schemata...  Instance diagram  A particular set of objects relating to each other.  Useful for discussing scenarios, test cases and examples

37 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 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 specification  Mapping of parts of speech to model components  Nouns are good candidates for classes  Verbs are good candidates for operations  In the problem statement (originally proposed, but rarely works if the problem statement is large (more than 5 pages)  Quality depends on style of writing  Too many nouns  In the flow of events of use cases (preferable)  Small list of candidate objects

38 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 38 Mapping parts of speech to object model components [Abbott, 1983] Part of speechModel componentExample Proper nounobjectJim Smith Common nounclassToy, doll Doing verbmethodBuy, recommend being verbinheritanceis-a (kind-of) having verbaggregationhas an modal verbconstraintmust be adjectiveattribute3 years old transitive verbmethodenter intransitive verbmethod (event)depends on

39 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 39 Analysis Object Model: Identifying Participating Objects  Pick a use case and look at its flow of events  Find terms that developers or users need to clarify in order to understand the flow of events  Look 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 diagram  Always use the user’s terms

40 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 40 Analysis Object Model: Example – Analyzing The Flow of events (1/2)  Flow of events  The customer enters the store to buy a toy  It 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 old  The assistant recommends a type of toy, namely the board game “Monopoly“  Not a good description, but okay as an example

41 Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 41 Grammatical construct UML Component Proper nounObject Common nounclass verbMethod Classifying verbInheritance Having VerbAggregation modal VerbConstraint AdjectiveAttribute Intransitive verbMethod Analysis Object Model: Example – Analyzing with Abbott’s (2/2) Example “Monopoly" “toy“, “board game” “enters" “is a",“either..or", “type of…" "Has a ", “consists of" “must be", “less than…" "8 years old" “depends on…."


Download ppt "Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) O bject- O riented S oftware C onstruction Chapter 5, Requirements Elicitation."

Similar presentations


Ads by Google