REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Conceptual Modelling
AGENDA Analysis & Specification with Conceptual Models 2
Requirements Specification ANALYSIS & SPECIFICATION WITH CONCEPTUAL MODELS 3
Requirements Analysis as Part of Specification Requirements Analysis is performed in order to analyze certain quality characteristics of requirements Is Requirements Analysis then synonym to requirements V&V? No! Analysis is concerned with an incomplete set of requirements, not discussed by the stakeholder. Requirements Analysis can be a very early activity. Requirements validation should have a complete, agreed upon set of requirements as input. Therefore, it is also regarded as part of the specification. 4
Means for Requirements Analysis Analysis Checklists Conceptual Modeling 5
Requirements Analysis Checklists Typical Questions (1) Is the requirement adequate with the business goal of the project? Does the requirement conflict with some domain constraint, policies or regulation? Does the requirement include premature design or implementation information? Is the requirement necessary? Does the requirement require non-standard hardware or must software be used? Is the requirement ambiguous, could different persons read it in different ways? What are the different interpretations for the requirement? Is the requirement realistic given the technology that will used to implement the system? 6
Requirements Analysis Checklists Typical Questions (2) Does the description of a requirement describe a single requirement or could it be broken into several different requirements? Has each requirement been assigned a priority? Are the system boundaries well defined? Have the portability, reliability, usability and maintainability requirements for the system been respected? Did you develop a behavioral or structural model for the system? Is the Data Dictionary implemented and correctly updated? Is the requirement testable by the test engineers? 7
Conceptual Modeling Conceptual Modeling is performed by the requirements engineer (analyst) to understand the problem domain and the requirements. Various models can be created to find out whether a problem domain or the requirements are understood well, i.e., whether the understanding of the requirements engineer is complete, consistent, and correct: Goals Data Interaction Structure Note: The models created during conceputal modeling are not necessarily part of the requirements specification. But they can be part of the requirements specification. 8
Conceptual Models For the different models, also various notations can be used, e.g., i-star (i*) E/R Diagrams UML SysML Business Process Modelling Notations 9
Goal Modeling Definitions Goal Models are often the first models used as they are on a high abstraction level. Definition goal: A goal is a desirable state lying in the future, which is not reached automatically but by specific actions. Goals and their dependencies are often described in conceptual models that are based on modelling languages. Definition goal model: A goal model is a conceptual model. Its goals and decompositions are documented in sub-goals and as necessary further dependencies between (sub)-goals. 10
Goal Modeling: Why should one do goal modeling? Goals can be one of the very early starting points (besides current problems) for requirements elicitation Goals are a fundamental concept to understand why new software or systems or changes to these systems are needed Goal modeling can be the anchor (rationale) for the following requirements traceability from high level to lower level 11
Classification of Goals Subject that has a goal Organizations or organizational units Individual Persons or Roles Object affected by the goal Quality goals Functional goals 12
Representation of Goals Various notations exist for goal modeling i-star (i*) GRL SIG (Softgoal interdependency graphs) And / OR Trees Just text 13
i*-framework I*-Framework I*-Framework is a graphical modelling language that is used for analysing and documentation It can be used in an early phase of system modelling for detecting and understanding problems It consists of two different models: Strategic Dependency Model (SDM): The Strategic Dependency Model is used to describe the dependency relationships among various actors. Strategic Rationale Model (SRM): The Strategic Rationale Model is used to provide rationales for single dependencies in the SDM. 14
Objects in i* Objects in i* Actor Actor Boundary Resource An actor is a person or a system that is in contact with the system. (Agents, Roles, Positions) A resource is a result required or supplied by the actor for completing the goal Softgoal A soft-goal describes the wish of an actor to complete a function regarding the quality Goal A goal is the documented intention of an actor Task A task consists of a number of steps which an actor has to execute for completing a task 15
Connections in i* Dependencies in i* Depender Dependee D D Soft-goal Dependency The soft-goal dependency describes an actors (Depender) completion of a soft-goal depends on another actor (Dependee). D Goal Dependency D The goal dependency describes an actors (Depender) completion of a goal depends on another actor (Dependee) D Task Dependency D The task dependency describes that an actor (Depender) depends on a task and that task depends on another actor (Dependee) D Resource Dependency D The resource dependency describes an actors (Depender) depending on a resource for goal completion and the resource is supplied by another actor (Dependee) 16
Connections in i* Links Means-end-Link The means-ends-link expresses what soft-goals, tasks and/or resources are needed to complete a goal. A meansends-link documents the reason why an actor is able to complete a specific goal, execute a specific task or use a specific resource. Task-Decomposition-Link The task-decomposition-link describes more detailed a task though goals, soft-goals, resources and/or more specified tasks. A task-decomposition-link documents the essential elements of a task to complete sub-goals or softgoals an the needed resources. +/- Contribution-Link + pos. affected - neg. affected The contribution-link describes a positive or a negative affect on soft-goals through tasks or other soft-goals. A contribution-link describes in what extend a task or another soft-goal contributes the soft-goal. But it does not explain the precisely range of support. 17
Example SDM Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2 18
Example SRM Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2 19
And / OR Decompositions (Trees) And-decomposition of a goal, i.e., the coarse-grain goal G0 is refined into several fine-grain goals G1 Gn that all have to be fulfilled to achieve goal G0. Or-decomposition of a goal. Again, a coarse-grain goal G0 is refined into several fine-grain goals G1 Gn. To fulfill G0, one (or more) of G1 Gn have to be achieved. 20
Example Example taken from Master Software Engineering for Embedded Systems, TU Kaiserslautern, Textbook E-M.2 21
Usage of UML for Conceptual Modeling (1) Various Diagrams of the UML can be used for Requirements Analyis, e.g.: Activity Diagrams for business processes / workflows Class and Object Diagrams for modeling data User Interface Navigation Maps, Collaboration Diagrams, and Sequence Diagrams for Interaction between different systems and stakeholders and systems 23
Usage of UML for Conceptual Modeling (2) Use Case Diagrams for getting an overview on the system functionality State Diagrams for modeling intended system states and their transformation or the (business) object lifecycles 24
UML Class Diagram to show Object Relationships 25 Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris UML-Intensive Framework for Modeling Software Requirements
UML Diagram for Object Lifecycle 26 Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris UML-Intensive Framework for Modeling Software Requirements
UML Use Case Model for Functional Overview 27 Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris UML-Intensive Framework for Modeling Software Requirements
UML Activity Diagram to refine a Use Case 28 Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris UML-Intensive Framework for Modeling Software Requirements
UML Information Flow Diagram for System Context 29 Figures taken from: Dr. Darius Silingas, Prof. Rimantas Butleris UML-Intensive Framework for Modeling Software Requirements
Conceptual Models in Different RE-Approaches Armour Use Case Diagram [Armour & Miller, 01] Domain Object Modell Initial what-is System Use Case Initial what will be System Use Case Base System Use Case Internal Use Case Elaborated System Use Case Transaction Information Model Transaction Trees Analysis Object Model Many different models and tasks, but basic design decisions are in common Holtzblatt [Beyer & Holtzblatt, 98] Work Model Focus Area User Environment Design (UED) Storyboard Use Case Object Model Constantine [Constantine & Lockwood, 99] Task model Domain model Content model Context Navigation Map Essential Use Case Use Case Maps 30
Conceptual Models Summary Conceptual models help clarifying certain aspects of a system in more detail than just natural language Support requirements analysis For different aspects of a system, different notations can be used 31