Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements"

Transcription

1 Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements to be testable? EAssign.pdf Online!!! Deadline: 31 st of October 2011 / Faculteit Wiskunde en Informatica PAGE 0 / Faculteit Wiskunde en Informatica PAGE 1 Techniques for Gathering Requirements Gathering and Analysing Requirements Observation Read documents and discuss requirements with users Shadowing important potential users as they do their work Session video recording Interviewing Conduct a series of interviews Ask about specific details Ask about the stakeholder s vision for the future Ask if they have alternative ideas Ask for other sources of information Ask them to draw diagrams Brainstorming Prototyping The simplest kind: paper prototype. a set of pictures of the system that are shown to users in sequence to explain what would happen The most common: a mock-up of the system s UI Written in a rapid prototyping language Does not normally perform any computations, access any databases or interact with any other systems May prototype a particular aspect of the system / Faculteit Wiskunde en Informatica PAGE 2 / Faculteit Wiskunde en Informatica PAGE 3

2 Gathering and Analysing Requirements Level of detail required in a requirements document Use case analysis Determine the classes of users that will use the facilities of this system (actors) Determine the tasks that each actor will need to do with the system How much detail should be provided depends on: size of the system need to interface to other systems readership stage in requirements gathering level of experience with the domain and the technology cost that would be incurred if the requirements were faulty / Faculteit Wiskunde en Informatica PAGE 4 / Faculteit Wiskunde en Informatica PAGE 5 Representation of requirements Reviewing Requirements Each individual requirement should Have benefits that outweigh the costs of development Be important for the solution of the current problem Be expressed using a clear and consistent notation Be unambiguous Be logically consistent Lead to a system of sufficient quality Be realistic with available resources Be verifiable Be uniquely identifiable Does not over-constrain the design of the system / Faculteit Wiskunde en Informatica PAGE 6 / Faculteit Wiskunde en Informatica PAGE 7

3 Requirements Review Checklist Requirements Review Checklist (cont.) 1. Does each user requirement have a unique identifier? 2. Is each user requirement atomic and simply formulated? (Single sentence. Composite requirements can best be split.) 3. Are user requirements organized into coherent groups? (If necessary, hierarchical; not more than about ten per group.) 4. Is each user requirement verifiable (in a provisional acceptance test)? (Where possible, quantify.) 5. Is each user requirement prioritized? 6. Are all unstable user requirements marked as such? (TBC=`To Be Confirmed') 7. Are all user requirements necessary? 8. Are the user requirements complete? Can everything not explicitly constrained indeed be viewed as developer freedom? Is a product that satisfies every requirement indeed acceptable? (No requirements missing.) 9. Are the user requirements consistent? (Non-conflicting.) 10. Are the user requirements sufficiently precise and unambiguous? (Which interfaces are involved, who has the initiative, who supplies what data; avoid passive voice.) 11. Are the user requirements understandable to those who will need to work with them later? 12. Are the user requirements realizable within budget? / Faculteit Wiskunde en Informatica PAGE 8 / Faculteit Wiskunde en Informatica PAGE 9 Requirements Review Checklist (cont.) Requirements Review Checklist (cont.) 13. Do the user requirements express actual customer needs (in the language of the problem domain), rather than solutions (in developer jargon)? 14. Are the user requirements not overly restrictive? (Allow enough developer freedom.) 15. Is overlap among user requirements pointed out explicitly? (Redundancy; cross-reference.) 16. Are dependencies between user requirements pointed out explicitly? Are these consistent with the priorities? 17. Are the characteristics of users and of typical usage described in sufficient detail? (No user categories missing.) 18. Is the operational environment described in sufficient detail, including e.g. relevant data flows in the "outside" world that do not interact directly with the system? (No external interfaces missing. No capabilities missing. Diagram included.) / Faculteit Wiskunde en Informatica PAGE 10 / Faculteit Wiskunde en Informatica PAGE 11

4 Requirements documents Managing Changing Requirements The document should be: sufficiently complete well organized clear agreed to by all the stakeholders Traceability: Requirements change because: Business process changes Technology changes The problem becomes better understood rationale Requirements document 1.11 XXXX... because 1.2 YYYY Design document...due to requirement 1.2 / Faculteit Wiskunde en Informatica PAGE 12 / Faculteit Wiskunde en Informatica PAGE 13 Managing Changing Requirements V model for software development Requirements analysis never stops Continue to interact t with the clients and users The benefits of changes must outweigh the costs. Certain small changes (e.g. look and feel of the UI) are usually quick and easy to make at relatively little cost. Larger-scale changes have to be carefully assessed Forcing unexpected changes into a partially built system will probably result in a poor design and late delivery Some changes are enhancements in disguise Avoid making the system bigger, only make it better / Faculteit Wiskunde en Informatica PAGE 14 / Faculteit Wiskunde en Informatica PAGE 15

5 The Process of Design Design as a series of decisions Definition: Design is a problem-solving process whose objective is to find and describe a way: To implement the system s functional requirements... While respecting the constraints imposed by the quality, platform and process requirements... including the budget And while adhering to general principles of good quality A designer is faced with a series of design issues These are sub-problems of the overall design problem Each issue normally has several alternative solutions: design options: software vs hardware The designer makes a design decision to resolve each issue This process involves choosing the best option from the alternatives / Faculteit Wiskunde en Informatica PAGE 16 / Faculteit Wiskunde en Informatica PAGE 17 Making decisions From requirements to implementation To make each design decision, the software engineer uses: Knowledge of the requirements the design as created so far the technology available software design principles and best practices what has worked well in the past System: A logical entity, having a set of definable responsibilities or objectives, and consisting of hardware, software or both. A system can have a specification which is then implemented by a collection of components. A system continues to exist, even if its components are changed or replaced. The goal of requirements analysis is to determine the responsibilities of a system. Subsystem: A system that is part of a larger system, and which has a definite interface / Faculteit Wiskunde en Informatica PAGE 18 / Faculteit Wiskunde en Informatica PAGE 19

6 From requirements to implementation From requirements to implementation Component: Any piece of software or hardware that has a clear role A component can be isolated, allowing you to replace it with a different component that has equivalent functionality Many components are designed to be reusable Conversely, others perform special-purpose functions Module: A component that is defined at programming language level For example: classes and packages are modules in Java Function: Unit at programming level with specific behaviour For example: methods in Java, functions in C / Faculteit Wiskunde en Informatica PAGE 20 / Faculteit Wiskunde en Informatica PAGE 21 Top-down and bottom-up design Top-down and bottom-up design Top-down design First design the very high level structure of the system Then gradually work down to detailed decisions about low- level constructs Finally arrive at detailed decisions such as: the format of particular data items; the individual algorithms that will be used Bottom-up design Make decisions about reusable low-level utilities Then decide how these will be put together to create high- level constructs A mix of top-down and bottom-up approaches are normally used: Top-down design is almost always needed to give the system a good structure Bottom-up design is normally useful so that reusable components can be created / Faculteit Wiskunde en Informatica PAGE 22 / Faculteit Wiskunde en Informatica PAGE 23

7 Different aspects of design UML and SysML Architecture design: The division into subsystems and components, How these will be connected How they will interact Their interfaces. Class design: The various features of classes User interface design Algorithm design: The design of computational mechanisms Protocol design: The design of communications protocol Based on the slides of Professor Insup Lee (University of Pennsylvania) / Faculteit Wiskunde en Informatica PAGE 24 / Faculteit Wiskunde en Informatica PAGE 25 The Unified Modeling Language g (UML) is A standard language for specifying, visualizing, constructing and documenting the artifacts of software systems, as well as for business modeling and other non-software systems The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems Six diagram types represent static application structure: Class Diagram Object Diagram Component Diagram Composite Structure Diagram Package Diagram Deployment Diagram / Faculteit Wiskunde en Informatica PAGE 26 / Faculteit Wiskunde en Informatica PAGE 27

8 Three diagram types represent general types of behavior: Use Case Diagram Activity Diagram State Machine Diagram Four diagram types represent different aspects of interactions Sequence Diagram Interaction Overview Diagram Communication Diagram Timing Diagram / Faculteit Wiskunde en Informatica PAGE 28 / Faculteit Wiskunde en Informatica PAGE 29 UML2 Super structure specification Structure diagrams: Class diagram Class diagram shows the relationships between the various classes in the System.The Classes being identified using the OOD paradigm. It s a static diagram and hence does not show the way in which the interaction happens. association -- an instance of one class must know about the other in order to perform its work. ( ) aggregation -- an association in which one class belongs to a collection. ( ) composition -- an association in which one class is composed of other classes.( ) generalization -- an inheritance link indicating one class is a superclass of the other. ( ) / Faculteit Wiskunde en Informatica PAGE 30 / Faculteit Wiskunde en Informatica PAGE 31

9 Structure diagrams: Class diagram Structure diagrams: Object diagram The relationships is shown in terms of the instances created of the objects that we defined The various objects instantiated are shown as well the relationships between th bj t those objects / Faculteit Wiskunde en Informatica PAGE 32 / Faculteit Wiskunde en Informatica PAGE 33 Structure diagrams: Package diagram Package diagram shows the hierarchy in which the system will be modeled in the implementation It gives a high level view for the distribution that can be created within the ifi d j t d if th k i ibilit specified project and specify the package visibility Structure diagrams: Composite Structure diagram Composite Structure diagram reflects the internal collaboration of classes, interfaces or components to describe a functionality Composite Structure diagrams are similar to Class diagrams, except that they model a specific usage of the structure Composite Structure diagram is used to express run-time architectures, usage patterns, and the participating elements' relationships, which might not be reflected by static diagrams / Faculteit Wiskunde en Informatica PAGE 34 / Faculteit Wiskunde en Informatica PAGE 35

10 Structure diagrams: Composite Structure diagram Structure diagrams: Deployment diagram Deployment diagram shows how and where the system will be deployed. Physical machines and processors are reflected as nodes, and the internal construction can be depicted by embedding nodes or artifacts / Faculteit Wiskunde en Informatica PAGE 36 / Faculteit Wiskunde en Informatica PAGE 37 Structure diagrams: Component diagram Component diagram illustrates the pieces of software, embedded controllers, etc. that will make up a system. Component diagram has a higher level of abstraction than a Class diagram - usually a component is implemented by one or more classes (or objects) at runtime Behavior diagrams: Use case diagram Use cases diagram basically are a substitute of the requirements being Modeled into the architecture. The external viewpoint as to what the System should do rather how / Faculteit Wiskunde en Informatica PAGE 38 / Faculteit Wiskunde en Informatica PAGE 39

11 Behavior diagrams: Activity diagram Activity diagrams are used to model the behaviors of a system, and the way in which these behaviors are related in an overall flow of the system The logical paths a process follows, based on various conditions, concurrent processing, data access, interruptions and other logical path distinctions, are all used to construct a process, system or procedure Behavior diagrams: Activity diagram / Faculteit Wiskunde en Informatica PAGE 40 / Faculteit Wiskunde en Informatica PAGE 41 Behavior diagrams: State Machine diagram A State Machine diagram illustrates how an element, often a class, can move between states classifying its behavior, according to transition triggers, constraining guards and other aspects of State Machine diagrams that depict and explain movement and behavior Interaction diagrams: Sequence diagram Sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when Sequence diagrams are organized according to time expressed in the sequential order along the vertical plane / Faculteit Wiskunde en Informatica PAGE 42 / Faculteit Wiskunde en Informatica PAGE 43

12 Interaction diagrams: Sequence diagram Interaction diagrams: Communication/Collaboration diagram Communication diagram shows the interactions between elements at runtime in much the same manner as a Sequence diagram. Communication diagrams are used to visualize inter-object relationships, while Sequence diagrams are more effective at visualizing processing over time / Faculteit Wiskunde en Informatica PAGE 44 / Faculteit Wiskunde en Informatica PAGE 45 Interaction diagrams: Communication/Collaboration diagram Interaction diagrams: Timing diagram Timing diagram defines the behavior of different objects within a time-scale Provides a visual representation of objects changing state and interacting over time. Used for defining hardware-driven or embedded software components / Faculteit Wiskunde en Informatica PAGE 46 / Faculteit Wiskunde en Informatica PAGE 47

13 Interaction diagrams: Interaction Overview diagram Interaction Overview diagrams visualize the cooperation between other interaction diagrams to illustrate a control flow serving an encompassing purpose Interaction ti Overview diagrams are a variant of activity it diagrams, most of the diagram notation is similar, as is the process in constructing the diagram Interaction elements display an inline Interaction diagram, which can be a Sequence diagram, Communication diagram, Timing diagram, or Interaction Overview diagrams Interaction diagrams: Interaction Overview diagram / Faculteit Wiskunde en Informatica PAGE 48 / Faculteit Wiskunde en Informatica PAGE 49

4.4 What is a Requirement? 4.5 Types of Requirements. Functional Requirements

4.4 What is a Requirement? 4.5 Types of Requirements. Functional Requirements 4.4 What is a Requirement? It is a statement describing either 1) an aspect of what the proposed system must do, or 2) a constraint on the system s development. In either case it must contribute in some

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

What is Automotive Software Engineering? What is Automotive Software Engineering? What is Automotive Software Engineering?

What is Automotive Software Engineering? What is Automotive Software Engineering? What is Automotive Software Engineering? Process models: Capability Maturity Model Integration (CMMI) Software Process Improvement and Capability Determination (SPICE) V-Model Standards: MISRA-C standard AUTOSAR Configuration management Product

More information

i. Node Y Represented by a block or part. SysML::Block,

i. Node Y Represented by a block or part. SysML::Block, OMG SysML Requirements Traceability (informative) This document has been published as OMG document ptc/07-03-09 so it can be referenced by Annex E of the OMG SysML specification. This document describes

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

The Role of the Software Architect

The Role of the Software Architect IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

Chapter 8 The Enhanced Entity- Relationship (EER) Model

Chapter 8 The Enhanced Entity- Relationship (EER) Model Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization

More information

Requirements engineering and quality attributes

Requirements engineering and quality attributes Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

Aerospace Software Engineering

Aerospace Software Engineering 16.35 Aerospace Software Engineering Software Architecture The 4+1 view Patterns Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Why Care About Software Architecture? An architecture provides a vehicle

More information

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering System Models Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain why the context of a system should be modeled as part of the RE process To describe

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Designing Real-Time and Embedded Systems with the COMET/UML method

Designing Real-Time and Embedded Systems with the COMET/UML method By Hassan Gomaa, Department of Information and Software Engineering, George Mason University. Designing Real-Time and Embedded Systems with the COMET/UML method Most object-oriented analysis and design

More information

SysML Modelling Language explained

SysML Modelling Language explained Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling

More information

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011 Use Cases Massimo Felici Use Cases 1 Support requirements engineering activities and the requirement process Capture what a system is supposed to do, i.e., systems functional requirements Describe sequences

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

Using UML Part One Structural Modeling Diagrams

Using UML Part One Structural Modeling Diagrams UML Tutorials Using UML Part One Structural Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

Vragen. Architecture presentations in practice. Some terms (from IEEE standard)

Vragen. Architecture presentations in practice. Some terms (from IEEE standard) Vragen Architecture presentations in practice Waarom is software architectuur belangrijk? Waarom schiet de volgende definitie tekort? The architecture of a software system defines that system in terms

More information

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective: CS 487 Week 8 Reading: 1. Ian Sommerville, Chapter 3. Objective: 1. To check the understandibility of the students in life cycle and process model for development of a software product. 2. To check if

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

UML TUTORIALS THE USE CASE MODEL

UML TUTORIALS THE USE CASE MODEL UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between

More information

Open S-BPM: Goals and Architecture

Open S-BPM: Goals and Architecture Open S-BPM: Goals and Architecture Albert Fleischmann Werner Schmidt Table of Content 1 Introduction... 2 2 Mission, Vision and Objectives... 2 3 Research and Development Areas... 3 4 Open S-BPM Architecture...

More information

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The

More information

Mastering increasing product complexity with Collaborative Systems Engineering and PLM

Mastering increasing product complexity with Collaborative Systems Engineering and PLM Mastering increasing product complexity with Collaborative Systems Engineering and PLM Thierry Ambroisine Dassault Systèmes 10 rue Marcel Dassault, 78140 Vélizy Villacoublay, France thierry.ambroisine@3ds.com

More information

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs. CH04 Capturing the Requirements Understanding what the customers and users expect the system to do * The Requirements Process * Types of Requirements * Characteristics of Requirements * How to Express

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.

More information

TOGAF usage in outsourcing of software development

TOGAF usage in outsourcing of software development Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky

More information

Object Oriented Programming. Risk Management

Object Oriented Programming. Risk Management Section V: Object Oriented Programming Risk Management In theory, there is no difference between theory and practice. But, in practice, there is. - Jan van de Snepscheut 427 Chapter 21: Unified Modeling

More information

Requirements Engineering Process

Requirements Engineering Process Software Engineering Requirements Engineering Process Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To describe the principal requirements engineering activities and d their

More information

Introduction. UML = Unified Modeling Language It is a standardized visual modeling language.

Introduction. UML = Unified Modeling Language It is a standardized visual modeling language. UML 1 Introduction UML = Unified Modeling Language It is a standardized visual modeling language. Primarily intended for modeling software systems. Also used for business modeling. UML evolved from earlier

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and

More information

Masters of Science in Software & Information Systems

Masters of Science in Software & Information Systems Masters of Science in Software & Information Systems To be developed and delivered in conjunction with Regis University, School for Professional Studies Object Oriented Design Table of Contents January

More information

Classical Software Life Cycle Models

Classical Software Life Cycle Models Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation

More information

Adaptive Radio. Cognitive Radio

Adaptive Radio. Cognitive Radio What are Cognitive Radio and Dynamic Spectrum Access SDR can act as a key enabling technology for a variety of other reconfigurable radio equipments commonly discussed in the advanced wireless market 1.

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software... 1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand

More information

A complete software development process of a general report publication service implemented using Web Services

A complete software development process of a general report publication service implemented using Web Services A complete software development process of a general report publication service implemented using Web Services Anders Nilsson & Klas Fahlberg February 1, 2008 Master s Thesis in Computing Science, 2*30

More information

UML-based Test Generation and Execution

UML-based Test Generation and Execution UML-based Test Generation and Execution Jean Hartmann, Marlon Vieira, Herb Foster, Axel Ruder Siemens Corporate Research, Inc. 755 College Road East Princeton NJ 08540, USA jeanhartmann@siemens.com ABSTRACT

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 5 Integrated Object-Oriented Methodologies: OPM and Catalysis 1 Object Process Methodology (OPM) Introduced by Dori in 1995 Primarily intended

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

Compliance and Requirement Traceability for SysML v.1.0a

Compliance and Requirement Traceability for SysML v.1.0a 1. Introduction: Compliance and Traceability for SysML v.1.0a This document provides a formal statement of compliance and associated requirement traceability for the SysML v. 1.0 alpha specification, which

More information

Introduction to software architecture

Introduction to software architecture Learning Unit 1 Introduction to software architecture Contents Introduction............................................... 7 1.1 What is software architecture?................................. 7 1.1.1

More information

Non-Functional Requirements

Non-Functional Requirements IBM Software Group Non-Functional Requirements Peter Eeles peter.eeles@uk.ibm.com Agenda IBM Software Group Rational software Definitions Types of requirement Classifying requirements Capturing NFRs Summary

More information

Software Development in the Large!

Software Development in the Large! Software Development in the Large! Peter Eeles Executive IT Architect, IBM peter.eeles@uk.ibm.com IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development

More information

Meta-Model specification V2 D602.012

Meta-Model specification V2 D602.012 PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR

More information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 4 Software Lifecycle and Performance Analysis Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and

More information

Requirements Engineering Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1

Requirements Engineering Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 Requirements Engineering Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 7 Slide 1 Objectives To describe the principal requirements engineering activities and their relationships

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,

More information

SOFTWARE ENGINEERING INTERVIEW QUESTIONS

SOFTWARE ENGINEERING INTERVIEW QUESTIONS SOFTWARE ENGINEERING INTERVIEW QUESTIONS http://www.tutorialspoint.com/software_engineering/software_engineering_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Software Engineering

More information

Layered Approach to Development of OO War Game Models Using DEVS Framework

Layered Approach to Development of OO War Game Models Using DEVS Framework Layered Approach to Development of OO War Game Models Using DEVS Framework Chang Ho Sung*, Su-Youn Hong**, and Tag Gon Kim*** Department of EECS KAIST 373-1 Kusong-dong, Yusong-gu Taejeon, Korea 305-701

More information

Java Programming (10155)

Java Programming (10155) Java Programming (10155) Rationale Statement: The world is full of problems that need to be solved or that need a program to solve them faster. In computer, programming students will learn how to solve

More information

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group

More information

A DOCUMENT MANAGEMENT SYSTEM MODELING

A DOCUMENT MANAGEMENT SYSTEM MODELING A DOCUMENT MANAGEMENT SYSTEM MODELING P tra cu Aurelia Petroleum and Gas University of Ploie ti, Economics Sciences Faculty, patrascuaura@yahoo.com T n sescu Ana Petroleum and Gas University of Ploie t,

More information

UML Diagram Types. Use Cases do the Following. Use Case Diagram

UML Diagram Types. Use Cases do the Following. Use Case Diagram UML Diagram Types Dynamic Models activity diagrams statechart diagrams interaction diagrams sequence diagrams collaboration diagrams use case diagrams Structural Models class diagrams object diagrams packages

More information

Chapter 8 Approaches to System Development

Chapter 8 Approaches to System Development Systems Analysis and Design in a Changing World, sixth edition 8-1 Chapter 8 Approaches to System Development Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases

More information

Communication Diagrams

Communication Diagrams Communication Diagrams Massimo Felici Realizing Use cases in the Design Model 1 Slide 1: Realizing Use cases in the Design Model Use-case driven design is a key theme in a variety of software processes

More information

Component visualization methods for large legacy software in C/C++

Component visualization methods for large legacy software in C/C++ Annales Mathematicae et Informaticae 44 (2015) pp. 23 33 http://ami.ektf.hu Component visualization methods for large legacy software in C/C++ Máté Cserép a, Dániel Krupp b a Eötvös Loránd University mcserep@caesar.elte.hu

More information

Developing SOA solutions using IBM SOA Foundation

Developing SOA solutions using IBM SOA Foundation Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this

More information

The SPES Methodology Modeling- and Analysis Techniques

The SPES Methodology Modeling- and Analysis Techniques The SPES Methodology Modeling- and Analysis Techniques Dr. Wolfgang Böhm Technische Universität München boehmw@in.tum.de Agenda SPES_XT Project Overview Some Basic Notions The SPES Methodology SPES_XT

More information

An Approach to Software Architecture Description Using UML

An Approach to Software Architecture Description Using UML An Approach to Software Architecture Description Using UML Henrik Bærbak Christensen, Aino Corry, and Klaus Marius Hansen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N,

More information

Design methods. List of possible design methods. Functional decomposition. Data flow design. Functional decomposition. Data Flow Design (SA/SD)

Design methods. List of possible design methods. Functional decomposition. Data flow design. Functional decomposition. Data Flow Design (SA/SD) Design methods List of possible design methods Functional decomposition Data Flow Design (SA/SD) Design based on Data Structures (JSD/JSP) OO is good, isn t it Decision tables E-R Flowcharts FSM JSD JSP

More information

Establishing Great Software Development Process(es) for Your Organization. By Dale Mayes DMayes@HomePortEngineering.com

Establishing Great Software Development Process(es) for Your Organization. By Dale Mayes DMayes@HomePortEngineering.com Establishing Great Software Development Process(es) for Your Organization By Dale Mayes DMayes@HomePortEngineering.com Class: ETP-410 Embedded Systems Conference San Francisco 2005 Abstract: There are

More information

Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics:

Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics: Organization of DSLE part Domain Specific Language Engineering Tooling Eclipse plus EMF Xtext, Xtend, Xpand, QVTo and ATL Prof.dr. Mark van den Brand GLT 2010/11 Topics: Meta-modeling Model transformations

More information

California Enterprise Architecture Framework

California Enterprise Architecture Framework Version 2.0 August 01, 2013 This Page is Intentionally Left Blank Version 2.0 ii August 01, 2013 TABLE OF CONTENTS 1 Executive Summary... 1 1.1 What is Enterprise Architecture?... 1 1.2 Why do we need

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

Modeling Guidelines Manual

Modeling Guidelines Manual Modeling Guidelines Manual [Insert company name here] July 2014 Author: John Doe john.doe@johnydoe.com Page 1 of 22 Table of Contents 1. Introduction... 3 2. Business Process Management (BPM)... 4 2.1.

More information

Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction

Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction CS 3141: Team Software Project Introduction Ali Ebnenasir Department of Computer Science Michigan Technological University Acknowledgement Betty H.C. Cheng Software Engineering Systematic approach for

More information

Sofware Requirements Engineeing

Sofware Requirements Engineeing Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (). Understandable

More information

Introduction to Database Systems

Introduction to Database Systems Introduction to Database Systems A database is a collection of related data. It is a collection of information that exists over a long period of time, often many years. The common use of the term database

More information

Automotive System and Software Architecture

Automotive System and Software Architecture Automotive System and Software Architecture Yanja Dajsuren 2IW80 Software specification and architecture March 25, 2014 Which one has more software? Chevrolet Volt, an example modern day car Boeing 787,

More information

Software Engineering. How does software fail? Terminology CS / COE 1530

Software Engineering. How does software fail? Terminology CS / COE 1530 Software Engineering CS / COE 1530 Testing How does software fail? Wrong requirement: not what the customer wants Missing requirement Requirement impossible to implement Faulty design Faulty code Improperly

More information

Scenario-based Requirements Engineering and User-Interface Design

Scenario-based Requirements Engineering and User-Interface Design Scenario-based Requirements Engineering and User-Interface Institut für Computertechnik ICT Institute of Computer Technology Hermann Kaindl Vienna University of Technology, ICT Austria kaindl@ict.tuwien.ac.at

More information

Application of UML in Real-Time Embedded Systems

Application of UML in Real-Time Embedded Systems Application of UML in Real-Time Embedded Systems Aman Kaur King s College London, London, UK Email: aman.kaur@kcl.ac.uk Rajeev Arora Mechanical Engineering Department, Invertis University, Invertis Village,

More information

Interactive system specification. Interactive system definition. Issues to be taken into account for interactive systems

Interactive system specification. Interactive system definition. Issues to be taken into account for interactive systems Interactive system specification From Requirements Engineering Processes and Techniques by G. Kotonya and I. Sommerville 1998 Slide 1 Interactive system definition Interactive systems can be defined as

More information

Configuration & Build Management

Configuration & Build Management Object-Oriented Software Engineering Using UML, Patterns, and Java Configuration & Build Management Outline of the Lecture Purpose of Software Configuration Management (SCM) Some Terminology Software Configuration

More information

Bidirectional Tracing of Requirements in Embedded Software Development

Bidirectional Tracing of Requirements in Embedded Software Development Bidirectional Tracing of Requirements in Embedded Software Development Barbara Draxler Fachbereich Informatik Universität Salzburg Abstract Nowadays, the increased complexity of embedded systems applications

More information

Component Based Development in Software Engineering

Component Based Development in Software Engineering Component Based Development in Software Engineering Amandeep Bakshi, Rupinder Singh Abstract--In today s world, Component Based development is an active research area for more than a decade in software

More information

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis

Requirements Engineering Processes. Feasibility studies. Elicitation and analysis. Problems of requirements analysis Requirements engineering processes Requirements Engineering Processes The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the.

More information

Lecture 9: Requirements Modelling

Lecture 9: Requirements Modelling A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview

More information

Linking BPMN, ArchiMate, and BWW: Perfect Match for Complete and Lawful Business Process Models?

Linking BPMN, ArchiMate, and BWW: Perfect Match for Complete and Lawful Business Process Models? Linking BPMN, ArchiMate, and BWW: Perfect Match for Complete and Lawful Business Process Models? Ludmila Penicina Institute of Applied Computer Systems, Riga Technical University, 1 Kalku, Riga, LV-1658,

More information

Software Requirements, Third Edition

Software Requirements, Third Edition j Microsoft Software Requirements, Third Edition Karl Wiegers and Joy Beatty Contents Introduction Acknowledgments xxv xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO Chapter 1 The essential software

More information

Object-Oriented Design Guidelines

Object-Oriented Design Guidelines Adaptive Software Engineering G22.3033-007 Session 8 Sub-Topic 3 Presentation Object-Oriented Design Guidelines Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute

More information

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box

More information

A very short history of networking

A very short history of networking A New vision for network architecture David Clark M.I.T. Laboratory for Computer Science September, 2002 V3.0 Abstract This is a proposal for a long-term program in network research, consistent with the

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Service Oriented Analysis and Design (SOAD) in Practice Part 4 Adomas Svirskas Vilnius University October 2005 Agenda Service identification and definition Business process

More information

Lecture 03 (04.11.2013) Quality of the Software Development Process

Lecture 03 (04.11.2013) Quality of the Software Development Process Systeme hoher Qualität und Sicherheit Universität Bremen, WS 2013/14 Lecture 03 (04.11.2013) Quality of the Software Development Process Christoph Lüth Christian Liguda Your Daily Menu Models of Software

More information

Umbrella: A New Component-Based Software Development Model

Umbrella: A New Component-Based Software Development Model 2009 International Conference on Computer Engineering and Applications IPCSIT vol.2 (2011) (2011) IACSIT Press, Singapore Umbrella: A New Component-Based Software Development Model Anurag Dixit and P.C.

More information

Using UML Part Two Behavioral Modeling Diagrams

Using UML Part Two Behavioral Modeling Diagrams UML Tutorials Using UML Part Two Behavioral Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

Architecture Design & Sequence Diagram. Week 7

Architecture Design & Sequence Diagram. Week 7 Architecture Design & Sequence Diagram Week 7 Announcement Reminder Midterm I: 1:00 1:50 pm Wednesday 23 rd March Ch. 1, 2, 3 and 26.5 Hour 1, 6, 7 and 19 (pp.331 335) Multiple choice Agenda (Lecture)

More information

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management?

11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java. What is Project Management? 11.1 What is Project Management? Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 11: Managing the Software Process Project management encompasses all the

More information

IV. The (Extended) Entity-Relationship Model

IV. The (Extended) Entity-Relationship Model IV. The (Extended) Entity-Relationship Model The Extended Entity-Relationship (EER) Model Entities, Relationships and Attributes Cardinalities, Identifiers and Generalization Documentation of EER Diagrams

More information

Software Architecture Document

Software Architecture Document Software Architecture Document Natural Language Processing Cell Version 1.0 Natural Language Processing Cell Software Architecture Document Version 1.0 1 1. Table of Contents 1. Table of Contents... 2

More information

Introduction to programming

Introduction to programming Unit 1 Introduction to programming Summary Architecture of a computer Programming languages Program = objects + operations First Java program Writing, compiling, and executing a program Program errors

More information

ArchiMate. ArchiMate Made Practical. Modeling according to ArchiMate guided by a collection of good practices

ArchiMate. ArchiMate Made Practical. Modeling according to ArchiMate guided by a collection of good practices ArchiMate ArchiMate Made Practical Modeling according to ArchiMate guided by a collection of good practices ArchiMate Colofon Title : ArchiMate Made Practical Date : 01 April 2013 Version : 4.0 Change

More information

Formal Technical Inspection. Using CLIPS to Detect Network Intrusions - (CLIPNIDS)

Formal Technical Inspection. Using CLIPS to Detect Network Intrusions - (CLIPNIDS) Formal Technical Inspection Using CLIPS to Detect Network Intrusions - (CLIPNIDS) Submitted in partial fulfillment of the requirements of the degree of MSE Sripriya Marry CIS 895 MSE Project Computing

More information

Plan-Driven Methodologies

Plan-Driven Methodologies Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a

More information