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

16
EuSEC Tool Vendors’ Challenge Adie Ditchburn Jon Chard 19 Sep 2006

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

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

EuSEC Tool Vendors’ Challenge

Adie Ditchburn

Jon Chard

19 Sep 2006

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

2 © Telelogic AB

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

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

3 © Telelogic AB

SystemRequirements

AgreeRequirements

QualificationStrategy

Analyze&

Model

StakeholderRequirements

AcceptanceStrategy

AgreeRequirements

SystemModels

AnalysisResults

DeriveRequirements& Qualification

Strategy

Deriving System Requirements

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

4 © Telelogic AB

Understanding your requirements

• Don’t 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

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

5 © Telelogic AB

Functionalmodeling

Functionalmodeling

Functionalmodeling

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. Functionalmodeling

SponsorRequirements

DesignSpecification

SystemRequirements

Statementof need

e.g. Performancemodeling

Concept: Requirements and Modeling

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

6 © Telelogic AB

‘Tool Vendor Challenge’ CCC Layers of Requirements and Models

ChallengeStatement

Concept: Requirements and Modeling

Stakeholder Requirements

System Requirements

Sub-System Requirements

Constructed in DOORS

Functionalmodeling

Functionalmodeling

Functionalmodeling

Use Case modeling

Activitymodeling

Functionalmodeling

Constructed in TAU

Implementation

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

7 © Telelogic AB

DOORS and TAU Demonstrations

Demonstration of Requirements Structure in DOORS

Demonstration of SysML Modelling in TAU

Over to you Jon

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

8 © Telelogic AB

Requirements visualization and satisfaction through modelling in Tau with traceability to DOORS

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

9 © Telelogic AB

System black-box use cases in Tau SysML

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

10 © Telelogic AB

Example system block structure in Tau SysML

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

11 © Telelogic AB

Example configuration block internal structure diagram

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

12 © Telelogic AB

State machine description of subsystem block behaviour

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

13 © Telelogic AB

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

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

14 © Telelogic AB

Benefits of Information Traceability

• Greater confidencethat objectives are being met.

• Ability to manage changethrough ability to access change impact.

• Greater accountabilityof subordinate organisations/suppliers.

• Ability to track progress / statusparticularly in the formative stages of project.

• Ability to deliver valuethrough cost/benefit analysis.

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

15 © Telelogic AB

DOORS Demonstration

Demonstration of Production of Traceability Reports

Once again Jon

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

16 © Telelogic AB

Use of DOORS traceability analysis tools to show requirements satisfaction through SysML model.