Chapter 5, Requirements Elicitation and Analysis

Last Lesson and Outlook Requirements Elicitation 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

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)

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.

Roles in the Software Life-Cycle Developer A role that is concerned with specifying and implementing (sub)systems Client (Customer) (End-)User A role representing the people who will use the delivered system A role representing the person or company commissioning paying for the development of the system

Process of Requirements Elicitation: The Requirements Elicitation Cycle Tests Validation Validation Validation Observing users As-Is Scenarios Use Cases + Refinements Prototypes Interviewing users and clients Visionary Scenarios Validation Validation Stable Requirements Specification (System Specification) Functional Requirements Non-Functional Requirements Use Cases Scenarios

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.

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 Re-design and/or re-implementation of an existing system using newer technology Helps to reveal problems and hints that exist in the current situation

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

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.

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.

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

Process of Requirements Elicitation: The Requirements Elicitation Cycle Tests Validation Validation Validation Observing users As-Is Scenarios Use Cases + Refinements Prototypes Interviewing users and clients Visionary Scenarios The validation process can be improved by implementing prototypes Prototypes 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 requirements Validation Validation Stable Requirements Specification (System Specification) Functional Requirements Non-Functional Requirements Use Cases Scenarios

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

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 A 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 case ReportEmergency Use Case Model: The set of all use cases specifying the complete functionality of the system

Use Cases: Communication relationships between actors and use cases Dispatcher FieldOf f icer OpenIncident ReportEmergency A line indicates which users are capable of invoking a use case AllocateResources Users, Roles Which user can invoke which use case

Use Cases Textual Representation Template for a textual use case Use case name Participating Actors Flow of Events Entry Condition Exit Condition Quality Requirements

Use Cases Textual Representation Example (Excerpt, see [Bruegge&Dutoit, 2004], p. 135) Initialized by an actor Use case name Participating Actors Flow of Events Entry Condition Exit Condition Quality Requirements ReportEmergency Initiated by FieldOfficer, communicates with Dispatcher The FieldOfficer activates the ReportEmergency function on this terminal SYSTEM responds by presenting a dialog form to the FieldOfficer FieldOfficer completes and submitts the form SYSTEM receives the form, evaluates the inform- ation in interaction with a Dispatcher and sends an acknowledge Initialized by the system Indented events: denotes who has initialized this step within the entire flow of control. Writing guide how one can write a use case The FieldOfficer is logged into the SYSTEM The FieldOfficer receives an acknowledge The FieldOfficer‘s request is acknowlegded within 30 seconds.

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

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 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 Reducing complexity by functional decomposition <<include>> CreateIncident HandleIncident CloseIncident

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. ReportEmergency FieldOfficer <<extend>> Base Use Case Supplier Use Case ConnectionDown 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.

Use Cases in a textual way Describing <<include>> and <<extend>> Report Emergency <<include>> Evaluate Info <<include>> relationship Flow of Events ... FieldOfficer completes and submitts the form SYSTEM receives the form, evaluates the information (by using Use Case EvaluateInfo) being received and sends an acknowledge <<extend>> relationship Report Emergency <<extend>> Connection Down 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 Entry Condition Flow of Events

Anticipating Change: Extension Points ReportEmergency Entry Condition The Selection extension point is reached in the extended use case. 1. Open the help system and show context help for the current selection. Flow of Events example taken from the OMG Specification of the Unified Modeling Language: Superstructure version 2.0

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. CheckPassword Parent Case Child Use Case ValidateUser CheckFingerprint

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

Requirements Validation (1/3) Requirements Elicitation 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 Consistent: 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

Requirements Validation (2/3) Requirements Elicitation More Requirements validation criteria Realistic Requirements can be implemented and delivered Verifiable Requirements can be checked Needs an exact description of the requirements With respect to deadline and budget restrictions

Requirements Validation (3/3) Requirements Elicitation 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

What is Requirements Engineering? (ctd.) Requirements Elicitation Requirements Analysis + Basis for Discussions Definition of the system in terms understood by the customer (“Problem Description”) Design basis for developers Technical specification of the system in terms understood by the developer (“Problem Specification”)  System Specification  Analysis Model

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

Process of Requirements Analysis Problem Statement Requirements Elicitation System specification: functional and non-functional requirements Requirements Analysis Analysis Model: dynamic model Analysis object model

Analysis Object Model vs. Dynamic 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)

From Requirements Specification to the Analysis Object Model 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) Requirements Elicitation Specification Scenarios Use Cases  Functional Requirements Conditions Exceptions

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)

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?

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

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 Focus on user terms (+) Quality of object model depends on the style of writing of the analyst, imprecise lanugage, many nouns Works well for short description for generating a small list of candidate objects

Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component Example Proper noun object Jim Smith Common noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-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 verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

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

Analysis Object Model: Example – Analyzing The Flow of events (1/2) 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

Analysis Object Model: Example – Analyzing with Abbott’s (2/2) Grammatical construct UML Component “Monopoly" Proper noun Object “toy“, “board game” Common noun class "8 years old" Adjective Attribute “enters" verb Method “depends on…." Intransitive verb Method “is a" ,“either..or", “type of…" Classifying verb Inheritance "Has a ", “consists of" Having Verb Aggregation “must be", “less than…" modal Verb Constraint