EuSEC Tool Vendors Challenge Adie Ditchburn Jon Chard 19 Sep 2006.

Slides:



Advertisements
Similar presentations
From the eyes of an Administrator A general overview of e-CFunds Administrative Site, including navigation and exploring the features of this powerful.
Advertisements

Slide 1 Configuration Management. Slide 2 Goal – Primary Objective To provide a logical model of the IT infrastructure by identifying,controlling, maintaining.
Software Requirements
Slide 1 Insert your own content. Slide 2 Insert your own content.
© 2005 by Prentice Hall Chapter 13 Finalizing Design Specifications Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 26 Legacy Systems.
Chapter 7 System Models.
Requirements Engineering Process
By D. Fisher Geometric Transformations. Reflection, Rotation, or Translation 1.
1 of 17 Information Strategy The Features of an Information Strategy © FAO 2005 IMARK Investing in Information for Development Information Strategy The.
© Telelogic AB Modeling DoDAF Compliant Architectures Operational Systems Technical.
© Telelogic AB [1] Sandia is a multiprogram laboratory operated by Sandia Corporation, a Lockheed Martin Company for the United States Department of Energys.
Overcoming Customer Constraints on Requirements Documents Presented by: Robert Smole Presented by: Robert Smole November 5, 2008 Sub-Optimization of Systems.
ATML Readiness For Use Phase II. Phase II Readiness For Use The ATML: Phase II will build on the Core phases, adding additional ATML components and features.
HL7 V2 Implementation Guide Authoring Tool Proposal
One Sky for Europe EUROCONTROL © 2002 European Organisation for the Safety of Air Navigation (EUROCONTROL) Page 1 FAA/Eurocontrol Technical Interchange.
1 Consultant Contract Program Collaboration Project ACEC-Mn/DOT Annual Conference March 2, 2010.
Coordinate Plane Practice The following presentation provides practice in two skillsThe following presentation provides practice in two skills –Graphing.
0 - 0.
ALGEBRAIC EXPRESSIONS
MULTIPLYING MONOMIALS TIMES POLYNOMIALS (DISTRIBUTIVE PROPERTY)
MULT. INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Addition Facts
Technical System Options
1 9 Moving to Design Lecture Analysis Objectives to Design Objectives Figure 9-2.
© 2009 IBM Corporation iEA16 Defining and Aligning Requirements using System Architect and DOORs Paul W. Johnson CEO / President Pragmatica Innovations.
Configuration management
Chapter 5 – Enterprise Analysis
Software Engineering - Specifications 1 Specifications Specification document must be clear, complete and correct.
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Defect testing Objectives
Testing Workflow Purpose
5.9 + = 10 a)3.6 b)4.1 c)5.3 Question 1: Good Answer!! Well Done!! = 10 Question 1:
Software Requirements
How to commence the IT Modernization Process?
1 Functional Strategy – IS & IT Geoff Leese November 2006, revised July 2007, September 2008, August 2009.
Lecture 8: Testing, Verification and Validation
Lecture 5: Requirements Engineering
1. 2 Captaris Workflow Microsoft SharePoint User Group 16 May 2006.
Lecture 8 Systems Analysis: Concept and Principles
Addition 1’s to 20.
Requirements Validation
Test B, 100 Subtraction Facts
Doubles Facts Doubles with Pictures Doubles without Pictures Pictures Only.
Week 1.
We will resume in: 25 Minutes.
1 PART 1 ILLUSTRATION OF DOCUMENTS  Brief introduction to the documents contained in the envelope  Detailed clarification of the documents content.
14-1 © Prentice Hall, 2004 Chapter 14: OOSAD Implementation and Operation (Adapted) Object-Oriented Systems Analysis and Design Joey F. George, Dinesh.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Requirement engineering.
Engineering System Design
Effective Requirements Management – an overview Kristian Persson Field Product Manager, Telelogic Asia/Pacific.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
SOFTWARE REQUIREMENTS Chapter 1 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia university based on.
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Outlines Overview Defining the Vision Through Business Requirements
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Software Engineering Lecture 10: System Engineering.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
Engineering, 7th edition. Chapter 8 Slide 1 System models.
DOORS Training Vince Pavlicek.
Software Requirements
Software Engineering (CSI 321)
UML profiles.
Presentation transcript:

EuSEC Tool Vendors Challenge Adie Ditchburn Jon Chard 19 Sep 2006

© Telelogic AB 2 Approach Discuss Method of Deriving Requirements –Structure –Role of Modelling Relationship of Models to requirements Demonstrate DOORS Structure –Database Level –Module Level Demonstrate Modelling using TAU –Use Case to System Level Activity Models –Logical System Structure Models Discuss Information Traceability Demonstrate Traceability in DOORS –Traceability Reports

© Telelogic AB 3 System Requirements Agree Requirements Qualification Strategy Analyze & Model Stakeholder Requirements Acceptance Strategy Agree Requirements System Models Analysis Results Derive Requirements & Qualification Strategy Deriving System Requirements

© Telelogic AB 4 Understanding your requirements Dont just list requirements, use structure to understand them Organise similar requirements into sections within documents Use structure to discover: –Context (overall situation in which the requirement occurs) Allows you to see the whole picture – Duplications (same requirement stated twice) Causes work to be performed twice Can lead to conflicting requirements Doubles your maintenance cost – Omissions (missing requirements) Unstated requirements become missing functionality Could cause shortcomings in non-functional areas such as performance, reliability, ease of use - that can not be re- engineered back into the system once developed

© Telelogic AB 5 Functional modeling Functional modeling Functional modeling Models Bridge Layers of Requirements Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer Modeling layer Requirements layer e.g Goal / Usage modeling e.g. Functional modeling Sponsor Requirements Design Specification System Requirements Statement of need e.g. Performance modeling Concept: Requirements and Modeling

© Telelogic AB 6 Tool Vendor Challenge CCC Layers of Requirements and Models Challenge Statement Concept: Requirements and Modeling Stakeholder Requirements System Requirements Sub-System Requirements Constructed in DOORS Functional modeling Functional modeling Functional modeling Use Case modeling Activity modeling Functional modeling Constructed in TAU Implementation

© Telelogic AB 7 DOORS and TAU Demonstrations Demonstration of Requirements Structure in DOORS Demonstration of SysML Modelling in TAU Over to you Jon

© Telelogic AB 8 Requirements visualization and satisfaction through modelling in Tau with traceability to DOORS

© Telelogic AB 9 System black-box use cases in Tau SysML

© Telelogic AB 10 Example system block structure in Tau SysML

© Telelogic AB 11 Example configuration block internal structure diagram

© Telelogic AB 12 State machine description of subsystem block behaviour

© Telelogic AB 13 Information Traceability INFORMATION TRACEABILITY: Understanding how high-level objectives are transformed into low-level goals. e.g. in business terms: Understanding how business vision interpreted as business objectives implemented as business processes e.g. in systems engineering: Understanding how user requirements satisfied by system requirements implemented as design artifacts implemented as components

© Telelogic AB 14 Benefits of Information Traceability Greater confidence that objectives are being met. Ability to manage change through ability to access change impact. Greater accountability of subordinate organisations/suppliers. Ability to track progress / status particularly in the formative stages of project. Ability to deliver value through cost/benefit analysis.

© Telelogic AB 15 DOORS Demonstration Demonstration of Production of Traceability Reports Once again Jon

© Telelogic AB 16 Use of DOORS traceability analysis tools to show requirements satisfaction through SysML model.