1 Enhancing Requirements Engineering by Quality Modelling: a structured Framework Paolo Donzelli Dept of Informatics Office of the Prime Minister Rome,

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

© Gerald Kotonya and Ian Sommerville Viewpoint-Oriented Requirements Methods.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Knowledge Acquisitioning. Definition The transfer and transformation of potential problem solving expertise from some knowledge source to a program.
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Viewpoint-oriented requirements methods. Objectives To explain the notion of viewpoints in RE To explain the notion of viewpoints in structured analysis.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
AOSE-2003, Melbourne July 15 th 1 Agent Oriented modeling by interleaving formal and informal analysis Anna Perini 1, Marco Pistore 2,1, Marco Roveri 1,
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Chapter 4 Capturing the Requirements 4th Edition Shari L. Pfleeger
Engineering Systems of.
Enterprise Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Introduction To System Analysis and design
UML - Development Process 1 Software Development Process Using UML (2)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
CSI315 Web Applications and Technology Overview of Systems Development (342)
Requirements Analysis
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
CIT UPES | Sept 2013 | Unified Modeling Language - UML.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 A Discipline of Software Design.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Business Analysis and Essential Competencies
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes.
Introduction To System Analysis and Design
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Approaching a Problem Where do we start? How do we proceed?
Chapter 7 System models.
Lecture 7: Requirements Engineering
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
1 Introduction to Software Engineering Lecture 1.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
GRASP: Designing Objects with Responsibilities
Review of Software Process Models Review Class 1 Software Process Models CEN 4021 Class 2 – 01/12.
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
A Goal Based Methodology for Developing Domain-Specific Ontological Frameworks Faezeh Ensan, Weichang Du Faculty of Computer Science, University of New.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Software Engineering Lecture 10: System Engineering.
Use Case, Component and Deployment Diagrams University of Sunderland.
SECURE TROPOS Michalis Pavlidis 8 May Seminar Agenda  Secure Tropos  History and Foundation  Tropos  Basics  Secure Tropos  Concepts / Modelling.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
 System Requirement Specification and System Planning.
Parallel Patterns.
The Systems Engineering Context
Software Quality Engineering
Chapter 9 Architectural Design.
Human Computer Interaction Lecture 14 HCI in Software Process
Presentation transcript:

1 Enhancing Requirements Engineering by Quality Modelling: a structured Framework Paolo Donzelli Dept of Informatics Office of the Prime Minister Rome, Italy (Cranfield University, RMCS – Shrivenham UK) novembre 2001

2 Outline Problem description The Requirements Engineering Framework The Framework at work: a case study From RE to system implementation

3 Problem description

4 Introducing an IT system into an organisation a successful system implementation relies on a firm understanding of the application domain our ability of envisioning its impact but the application domain is far from being stable drives the IT system development but must evolve to exploit the system capabilities The system must become an "organic" component of the re-engineered company (the to- be company)

5 Envisioning the to-be company (a difficult task) The system and its application domain form a larger social-technical system whose overall needs are the ones to be fulfilled. Organisations are made of people: the goals, the expectations, and the needs of all the stakeholders, have to be explicitly addressed Customer satisfaction becomes an organisation-wide concept, beyond the simple individual customer or user point of view.

6 Advances in Requirements Engineering (1) Process modelling-based techniques have been suggested to support the Early RE Phases (requirements discovery, validation and verification), by providing a collaborative environment between analysts and stakeholders to: understand the application domain translate application domain needs into system requirements design the to-be company (by reasoning through feasible alternatives) (i*)

7 the WHY as driving factor of the requirements discovery/modelling process (KAOS – I*) Advances in Requirements Engineering (2)

8 Genesis of the proposed RE Framework (1) adopt new RE techniques (i.e. process modelling-based and “why”-oriented approaches) encompass Quality Modelling approaches, to better deal with stakeholders’ quality issues move from “slow, reactive, adversarial, separated software engineering and systems engineering processes to unified, concurrent processes”, which will also include business process reengineering.

9 Genesis of the proposed RE Framework (2) Reasoning about the Why, the What and the How

10 Main Objectives Support discovery, and early verification and validation of both user-oriented and organisation-oriented requirements Facilitate envisioning and designing the to-be company Force reasoning about non-functional requirements since the outset of the project, while dealing with functional ones Soft goals play a central role, providing a systematic and organized way of handling non-functional requirements  constraints in operational terms, or fit criteria for assessment purposes!

11 The Requirements Engineering Framework Main characteristics, Notation, Process

12 The RE Framework: main characteristics Process Soft Goal modelling Hard Goal modelling Organisation modelling case study

13 Organisation Modelling (1) deals with the application domain structure basic elements

14 Organisation Modelling (2) complex agent simple agent

15 Soft Goal Modelling produces operational definitions of the soft goals, decomposing them into sub hard goals and constraints

16 Hard Goal Modelling determines how to achieve hard goals, by decomposing them into sub hard goals and tasks

17 Combining soft and hard goal models Agent’s behaviour (simple or complex)

18 Applying the Framework: the process Development Flow from top organisational level, down to simple agents level, the models feed each others, in a continuous loop. The complete organisation model will result into a flat network of interrelated goals, tasks, and resources, with agents acting as a modularization mechanism Elicitation and Validation Flow where interaction with the stakeholders occurs Verification Flow to guarantee consistency between models

19 A Case Study

20 The case study Strongly interrelated with the application domain, highly complex and expensive, they require a RE process strongly focused on the early verification and validation Synthetic Environments are distributed interactive simulations of real-world systems, used to support operational, political and economic decisions RE process for a ground-based simulator suitable to investigate the feasibility of equipping an aircraft with a new avionics sub-system

21 A ground-based simulator

22 The Organisation Model from goals to req.s clashing req.s

23 Soft goal upon the Project Leader

24 Hard goals upon the Project Leader

25 From high level goals to system requirements there is not one single set of global goals that has to be achieved (from which the others are refined in a top-down way) an organisation consists of numerous processes occurring simultaneously, involving various agents, following different paths, and intersecting each other an agent may operate as goal generator, as well as a goal transformer goals propagate through the organisation in complex patterns and may even conflict It is from the set of goals and constraints placed upon the system that the final requirements can be obtained

26 Clashing Requirements: detecting and resolving them through soft goals Agents may have different opinions, and their goals collide. How can Soft Goals help? provide a way to reason about trade-offs, to freeze temporary solutions, and to formalise final decisions encourage interactions and a common terminology force us to clarify, very early in the project, concepts that are usually left blurred until it is too late (or too expensive) for any corrective intervention

27 “Realism” soft goal for the Flight Test Crew

28 “Realism” soft goal for the Avionics System Expert

29 Resolved “Realism” soft goal

30 Deliverables of the RE Framework

31 Have the objectives been achieved? The RE Framework improves the early-stage verification and validation of the requirements of a IT system: Verification is improved by reconciling the different models Validation is improved because of the visibility of the decisions made by stakeholders. Application results suggest that the Framework offers benefits to accreditation and maintenance activities, mainly thanks to the two-way goal requirement link Accreditation should be made easier by tracing the IT system properties to application domain needs Maintainability is improved because changes in the application domain may be easily linked to system changes.

32 From RE to System Implementation

33 Deriving the System Requirements Architecture the RE framework allows us to model the application domain at a social-technical level, by providing a systematic approach to deal with agents, soft goals, hard goals and their incremental refinement requirements are expressed as a collection of hard goals and constraints placed upon the system by other agents

34 An Extract from the Organisation Model

35 The RE Framework outcome a set of Hard Goals and Constraints

36 RE Framework as forerunner for UML the front-end activity of any UML-based approach is the use-case modelling, i.e. capturing the ways in which the users intend to interact with it. use-case analysis can benefit from supporting methods (Business Process Modelling and Black Box approaches) that help to identify both the actors, and their goals the output from our RE Framework, in the form of a set of hard goals and constraints placed upon the system by well-defined agents, is entirely consistent with this.

37 Use-cases as a Goal-refinement Strategy a hard goal can lead to one or more use- cases constraints will become non-functional requirements use-cases offer a systematic and intuitive means of capturing functional requirements constraints enrich and complete the use- cases, by providing a systematic and intuitive means of dealing with non- functional requirements.

38 Avionics System Expert: Use-case Diagram constraints goals

39 The Use-case Diagram

40 Building the conceptual model: the class diagram