managing a secure requirements engineering flow within · pdf filemanaging a secure...

Test and Verification Solutions

Managing a secure requirements

engineering flow

within a complex product family

environment

in order to attain ISO26262 compliance

Delivering Tailored Solutions for

Hardware Verification and Software Testing

Presentation to ISO 26262 Practitioners Workshop

20th January 2016

Copyright TVS Limited | Private & Confidential |

Requirements Engineering

“Systematic and disciplined approach to the specification and management of requirements”

• Elicitation

• Validation and Negotiation

• Documentation

4

• Management


Elicitation

What • Requirement

“Statement of need, clearly and accurately stated”

• Types of requirements

“Functional requirement”

“Non-Functional Requirement”

Who • Stakeholders

• Identification

• Responsibilities

• Requirement Engineers


Documenting the Requirements

Natural Language • Discipline, Training, ontologies

MBSE • Tools, Training, Common understanding (ontologies)

Semi-formal notation • Highly recommended but not defined in the standard *

Configuration management • Tools, Discipline, Process, Variability management

Change management • Tools, Discipline, Process, Variability management


Validation and Negotiation

Requirements Quality Gateway • Review or Tool, boilerplates or modelling • Constraints and conflicts identified, negotiated and incorporated

DIA – Development Interface Agreement • Determines which work products delivered by which partner

• HARA Hazard Analysis and Risk Assessment decides which level of Safety

Communication • ReqIF proposes use of “HIS Exchange Process for Requirements” • Loss

• Complete set of data at both IF’s Tier 1 OEM etc-

• Data Integrity • Data correct at both IF’s Tier 1 OEM etc-> corruption, metadata, hierarchy, ontologies

• Security • Malicious or accidental data loss, corruption or theft

• Safety • Proof of Safety Culture and adherence from supplier to customer


Requirements Tracing

Join the Dots …. Simple!

Figure : Typical Requirements Tree


Management of product Family

Orthogonal data view

Figure : Typical Requirements Tree Figure : Typical Requirements Tree


Requirements ->test plan -> test results


Tooling ecoSystem

Copyright T&VS 2015. All rights reserved.

Change

management

Requirement

management

Requirement

Quality

management

Interoperability

Standards Configuration

management

Middleware

SW test tools HW test tools


Tool Choice Considerations

Complete ALM/PLM tools most effective and suited • May not consider all the domains required • May require some manual intervention • Data translation/movement may not suit secure solutions

Correct tool for the job • Different tool solutions suit different domains or work environments • Support of other tooling being used (at least no conflict)

Legacy tooling • Expensive to move • Extensive tailoring • Also expensive to stick together existing solutions

Costing • Multiple tools are expensive • Many ALM solutions have hidden extra costs • May be high on resource overheads to maintain or use tooling

Overkill • Don’t buy tools that have extras that you don’t use or need • If its small use Excel and good discipline and process!


Process

Requirements Database

Variant x

xml

Variant x

Target Spec

Variant x

Change

management

Refine

Refine


Auditability – Proving its been implemented

Requirements, need to be mapped to test and test to results


MetaData

Ensure all the information gathered is reproducible


Variant management

Reusability and management


Questions

?

? ?

managing a secure requirements engineering flow within · pdf filemanaging a secure...

Documents