07-Functional Requirements.pdf

Requirements Engineering Lecture 7 Prof. Dr. Alexander Pretschner Chair of Software & Systems Engineering TUM Department of Informatics Technical University of Munich Orientation Recap:...

Requirements Engineering Lecture 7 Prof. Dr. Alexander Pretschner Chair of Software & Systems Engineering TUM Department of Informatics Technical University of Munich Orientation Recap: Lecture 6: Goals and Non-functional Requirements How can we measure NFRs Functional vs. Non-Functional Ethics in the RE process Coming up: Functional Requirements Domain Models Usage Models Use Cases User Stories Function Hierarchies Requirements Engineering | SS 2024 | TUM i4 3 How can we separate Functional and Non-Functional Requirements? Example 1 (NFR): “The Scooter app backend must be capable of serving 10,000 clients simultaneously with a response time under 600ms.” Example 2 (FR): “The user should be able to log into the Scooter app with their personal account.” Requirements Engineering | SS 2024 | TUM i4 4 Definition: Functional Requirements Definition Functional Requirements: External system behavior, characterized by stimulus-response (input-output) pairs. [Davis93] (Then everything else becomes a non-functional requirement.) Functional Requirements: Often in the form of "The system must do [xy]". Justified by objectives and collected from various sources (see Lecture 4) Specify product features of a system Critical view Definition and distinction between “functional“ and “non-functional” requirements is difficult → On which levels of abstraction and in which context can functionality be considered? → How can behavior systematically be recorded and described in a structured way? Requirements Engineering | SS 2024 | TUM i4 5 Levels and Concepts of Behavioral Modeling 1 External Stake Business Processes Systems 1. Analysis of Business Processes 1 holder......... Context of the system Which technical processes should be supported by the Context User System Usage system? Model 2 2. Structured specification of Use Cases and Scenarios 2 Behavioral modeling off perspective of the user ("Black Box") Modes Modes Functional Hierarchy Modes F1 How should the system be used by (external) actors?...... 3......... Requirements 3 3. Step-by-step refinement to system specification using Component Model Function Hierarchies Behaviour Model Port 1 SM1. 2 Component 1 States Specification of functions, interfaces, system behavior SM1. 3 SM1. 4 Which functions are required? Component... System Requirements Engineering | SS 2024 | TUM i4 7  Scooter Rent Scooter Interf ace Customer Decide Where to Go Directly Book at Example: Business Process Model Location Search for Scooter 1. Analysis of Business Processes 1 Tasks and causal dependencies Ask Customer For Renting Time Roles and responsibilities v ia Website Mode of Selecting v ia App Involved business objects Put in Starting Location Log in w ith Account Select Scooter Check Needed Select Renting Battery Charging Time Example Business Process: Not Enough Charged Renting a scooter. Enough Charged Activate Scooter Activate Rent Start Scooter Driv e Requirements Engineering | SS 2024 | TUM i4 9 Example: Usage Model Use Case Diagram Include 1. Relationship 2 Structured specification of Use Cases System and Scenarios Boundary E-Scooter Rental Derivation of tasks to be realized in interaction with the system End Rent Call Center Operator Identification of Use Cases Start Rent Authentication Coordination and modeling of interaction scenarios Customer Top up prepaid card Request Scooter Locations In Use Case Diagrams Relationships can be: Generalization Actor “Juicer” Request out of charge Include scooter locations Extend Extension point Relationship System Use Case Requirements Engineering | SS 2024 | TUM i4 10 Example: Function Hierarchy Rent Scooter 1. Specification using Function Hierarchies 3 Identification of system functions Authentification Connection to … based on scenarios Scooter Refinement of the functions and Log into App … identifications of interactions Specification of the interfaces Enter User Enter Verify Account Name Password Credentials Access … Database Requirements Engineering | SS 2024 | TUM i4 12 What is a Use Case? Definition Use Case: Use Case A use case bundles all possible scenarios that can occur when an 1 1..* actor tries to achieve a certain technical goal with the help of the Scenario system under consideration. 1 1..* Notation: structured text, use case diagram (UML),... Action Definition Scenario: System Actor An ordered set of interactions between partners, usually between a Action Action system and a set of external actors [Glinz06]. performs realises Notation: structured text, sequence/interaction diagrams System under Actor Consideration (e.g., UML, Message Sequence Charts (MSCs), AutoFocus EETs,...) Requirements Engineering | SS 2024 | TUM i4 13 Difference between a Use Case and a Scenario? A use case is a set of scenarios A scenario is an ordered set (sequence) of interactions (functional requirements) Use cases can be described with the Use Case Template of Cockburn The interactions in a scenario can be unfolded into smaller and smaller interactions (e.g., “buy a coke” and “put coin into machine”) Some scenarios end with success, some end with failure Requirements Engineering | SS 2024 | TUM i4 14 Use Cases and Scenarios (1/2) 1 ATM transfer money authentication deposit money pay out money customer A Use Case is a state- and property-oriented structuring of the system behavior which 2 1. has purpose and context (business processes). 2. collects several scenarios. Requirements Engineering | SS 2024 | TUM i4 15  Use Case Use Cases and Scenarios (2/2) Use Cases summarize a number of scenarios for a (1) (2) targeted system usage. Use Case: Task, objective, performance for the "users", task structuring, causal dependencies (also pre- and post- Scenario conditions) Iterative development Scenario: (see Refinement and abstraction of Sequence of events (work steps, events, interactions) goals - VL 5) (1) Combine scenarios into tasks and structure (2) Collect task-related scenarios, "play through" and analyze Requirements Engineering | SS 2024 | TUM i4 16 Use Cases vs. Scenarios vs. Functional Requirements Scenario Use Case: Set of all scenarios “Functional Requirement” Scenario: A concrete interaction process Functional Requirement: A (system)-response to a stimulus (take with a grain of salt!) Use Case Requirements Engineering | SS 2024 | TUM i4 17 Specification of Use Cases Modeling of Use Cases Using structured text By using models (Activity Diagrams, Message Sequence Charts) Core Components Context of use (remember design thinking: "user journey" extends this idea) Primary actors and their goals Precondition: Assumptions about system environment and the initial situation Postcondition: Utilization goal and target situation Scenarios: Work steps and required Interaction between actors (users, neighboring systems) and system → Control Flow → Scenarios (instances per use case) Requirements Engineering | SS 2024 | TUM i4 18 Use Case Template of Cockburn USE CASE 5 Buy Goods Buyer issues request directly to our company, expects Goal in Context goods shipped and to be billed. A scenario is a sequence of goal-achieving actions Scope & Level Company, Summary Preconditions We know Buyer, their address, etc. Success End Condition Buyer has goods, we have money for the goods. The main success scenario is the most common scenario: We have not sent the goods; Buyer has not spent the Failed End Condition Is a simple/typical story without too much complexity money. Buyer, any agent (or computer) acting for the customer. Cockburn: Description without Extension or Sub- Primary, Secondary Actors Credit card company, bank, shipping service Trigger purchase request comes in. Variations DESCRIPTION Step Action 1 Buyer calls in with a purchase request Company captures buyer’s name, address, The use case collects all the scenarios which are related to 2 requested goods, etc. the goal of the primary actor: 3 Company gives buyer information on goods, prices, delivery dates, etc. The "set of possible sequences" is called a "use case“ 4 Buyer signs for order. The "sequence of (concrete) interactions" is called a EXTENSIONS Step Branching Action Company is out of one of the ordered items: "scenario" in the use cases 3a 3a1. Renegotiate order A scenario consists of steps, each step is an action. 4a Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) SUB-VARIATIONS Step Branching Action → A use case is the collection of possible scenarios Buyer may use phone in, fax in, use web order 1 form, electronic interchange Requirements Engineering | SS 2024 | TUM i4 19 Discussion: Scenarios and Use Cases It is sufficient to focus on the main success scenario as it is the most important scenario Requirements Engineering | SS 2024 | TUM i4 20 What is a Business Process? Definition Business Process: A business process is a sequence of work steps for the fulfillment of a goal. Concepts (simplified) Function/Aim (Purpose/Intention - Why?) Process steps (tasks/activities) and causal dependencies/sequence (interaction sequence - what? when? how? ) Business objects (with what?) Distribution of tasks to involved roles (by whom? ) organizational units, system users Systems, processes, HW/SW components of the system environment Requirements Engineering | SS 2024 | TUM i4 22 Example of a Business Process according to BPMN Requirements Engineering | SS 2024 | TUM i4 23 From Business Process Instances to Business Processes A business process is a set of business process instances Describing a set of process instances is often difficult →Therefore: Description of selected, representative instances, e.g.: Create new Course Review Information Book Customer Requirements Engineering | SS 2024 | TUM i4 24 From Business Processes to Functions: Basic Idea Product planning Which actor (or role) leads which steps? Needs ass- Which steps are supported by the system? essment → Identification of functions that must be available in a system. Planning Realization Evaluation → The way in which this use takes place can be recorded in use cases (see following slide). Plan survey Analyze Purchase Country-specific Interview Plan Design Pharmacist Procedure Create Combine National Total Concept Results Coordinate Evaluation Evaluation Project Interview Create Instruct Questionnaire Distribution Doctors Analyze National Manage Support Evaluation Total Interview Questionnaire Survey Interview Evaluation Results Process System to be developed 25 Use Cases: From Business Processes to Functions Capture and Model Business Processes Stake Business Processes External Systems holder 1. Identification of tasks and steps (building structures)......... → Surveys 2. Specification of partial steps, causal order and actors User System Usage → Surveys, observations, analysis of target models Model 3. Identification of business objects Analyze Processes and Identify Functions 1. Identification of use case candidates → tasks be performed by the system, which by external systems, which remain manual? 2. Definition of which sub-steps are to be performed by the user and which sub-steps are to be realized by the system 3. Derivation of interaction scenarios → Going through different scenarios, often interactively with modification of the processes based on new findings → Basis for function hierarchies Requirements Engineering | SS 2024 | TUM i4 26 Meaning of the Usage Model Meaning of the Usage Model Application domain analysis: processes between external actors (users, neighboring systems) and the system in context; business processes to be supported Essential basis for voting on External system behavior (especially unclear/"critical" system behavior) scenarios and their treatment) − Identification of functions Use of the Usage Model Basis of communication: "playing through" contextual system utilization → Review and consolidation of processes Basis for: − Planning and definition of systems (rule scenarios, exception scenarios) − Design (architecture, communication protocols, interfaces,...) − Specification of test cases (acceptance tests), detailed effort estimates,... − Formation of function hierarchies as transition to the design Requirements Engineering | SS 2024 | TUM i4 27 Example 1 2 3 + Payment of the scooter ride Requirements Engineering | SS 2024 | TUM i4 Picture source: https://e-scooter.one/bird/ 28 What is a Function Hierarchy? Definition Function: A (usage) function is an excerpt from the behavior of the system, which can be perceived at the system interface and serves a certain purpose. Related terms: usage function, service, feature, user-visible function Definition Function Hierarchy: Decomposition/structuring of functions and sub-functions as well as (intentional/unintentional) dependencies (feature interaction) to analyze their required behavior definition according to different principles, such as Tasks - subtasks Causal/temporal order Communication Relations Distribution to system components Requirements Engineering | SS 2024 | TUM i4 29 Importance of Function Hierarchies Importance of Function Hierarchies Overview of functions for analyzing system behavior Functions are 1. identified on the basis of use cases, 2. analyzed/tuned by means of Use Cases and 3. structured in hierarchies → Essential basis for design of the (internal) system behavior Use of the Function Hierarchies Creation of syntactic interfaces: Specification of the amount of inputs and outputs at system interfaces, which serve the realization of the function Specification of the behavior (models) Definition of a logical component architecture Requirements Engineering | SS 2024 | TUM i4 30 Discussion: Function Hierarchy How could one decompose the function „The user pays for the ride“? Requirements Engineering | SS 2024 | TUM i4 31 From Scenarios to Functions: Basic Idea 1. Identify system functions based on the use cases / scenarios User System Usage Model (context of use with assumptions, preliminary and post conditions, triggers,...) 2. Refine and structure system functions using a hierarchy 3. Identify dependencies between the functions 4. Define external interfaces (Dialogs, Data,...) Functional Hierarchy Function Hierarchies allow smooth transition into the design F1 Definition of a logical component architecture...... Specification of interface behavior by means of automata......... Iterative data modelling (continuous completion) Requirements Engineering | SS 2024 | TUM i4 32 Discussion: Interfaces and Contracts How to define an Interface? What is the difference between an Interface and a Contract? Requirements Engineering | SS 2024 | TUM i4 33  More details in Lecture 9 What is a User Story? Definition User Story: A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects: [Cohn04] A written description of the story used for planning as a reminder Conversations about the story that serve to flesh out the details of the story Tests that convey and document details and that can be used to determine when a story is complete More details about User stories: Represent customer requirement rather than document them Traditionally, stories are written on cards with test cases on the back side of the card Details can be expressed as additional stories Requirements Engineering | SS 2024 | TUM i4 34  More details in Lecture 9 Writing good User Stories A good User Story is: Independent: No dependencies between stories as they lead to planning problems Negotiable: User Stories are no requirements, but description of functionality to be negotiated Valuable: User Stories should be valuable to users or customers Estimable: Developers should be able to estimate the size of a story Small: Long stories are difficult to understand and should be split up in a series of smaller stories Testable: Stories must be written so as to be testable. Passing all tests proves deployment Comparison between User Stories and Use Cases (flaky!): User Stories: Written in users’ everyday language, small scale and easy to use information; more geared towards needs; "atomic"; clear role; "invitation to discuss" Use Cases: Written in users’ business language, organize requirements, list of steps; more geared towards requirements; multiple scenarios; "can be used as basis in a contract" Requirements Engineering | SS 2024 | TUM i4 35 Discussion: User Story How could a possible user story in our rent- a-scooter example look like? What are possible test cases for this story? Requirements Engineering | SS 2024 | TUM i4 36 Examples of User Stories Sub-stories Tests A user can search for As a user, I can make a scooter different scooters. The reservation results can be filtered by distance and battery charge Try it with a valid account and then of the scooter with a blocked account User Story Try it on the Android and IOS Apps A user can input his goal Try it with an account that has a As a user, I can destination in the app before card expiration date in the past make a scooter making a reservation. Only Try it with an account that already reservation scooters that can reach this has an ongoing reservation destination are shown A scooter can only be reserved with a valid user account Requirements Engineering | SS 2024 | TUM i4 37 General Problems with Behavioral Modeling Behavioral modeling does not start with the design! → Use of modeling techniques allow seamless transition to the design → Danger of solution orientation (drifting into the draft) → Multiple facets/languages need to be synchronized The tendency is therefore: Make sure that There is focus on the analysis of the intended usage behavior from the overall system view (black box) Use cases and scenarios are used to understand and analyze the context and intention of the users Function hierarchies can be used, − to systematically implement a change of perspective from usage scenarios to user-visible functions − to systematize an (iterative) transition into the design Requirements Engineering | SS 2024 | TUM i4 38 Summary External Structured view on functionality has vital Stake Business Processes Systems holder......... importance for RE Functionality must usually be seen in an User System Usage Context Model operational context Functions can be described on different levels and in different forms Functional − Business process models Modes Modes Hierarchy Modes F1 − Use Cases and Scenarios............... − Function hierarchies Requirements Component Model Component 1 Behaviour Model Port 1 SM1. 2 States SM1. SM1. 3 4 Component... System Requirements Engineering | SS 2024 | TUM i4 39 Outline and Outlook Terms and Definitions Context-specific nature of SE and RE Quality models for requirements Engineering Models Stakeholder and Requirements Elicitation Goals and Goal-oriented RE Non-functional Requirements Functional Requirements Formalization Agile Processes Requirements Management and Quality Assurance Trends in Research Requirements Engineering | SS 2024 | TUM i4 40 Literature Davis, Alan M. Software Requirements: Objects, Functions, and States. Prentice-Hall, Inc., 1993. Glinz, Martin. "Requirements Engineering I." Nicht funktionale Anforderungen. Universität Zürich, Institut für Informatik, Zürich (2006). https://files.ifi.uzh.ch/rerg/arvo/ftp/re_I/Kapitel_08_Szen.pdf Alistair, Cockburn. “Writing Effective Use Cases” Humans and Technology in preparation for Addison-Wesley Longman, 2000. https://www.infor.uva.es/~mlaguna/is1/materiales/BookDraft1.pdf Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley Professional. Requirements Engineering | SS 2024 | TUM i4 41