Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy...

Role of Requirements in Operational Concept Validation (RORI-OCV)Requirement Development Strategy

Ir. Y.A.J.R. van de Vijver (NLR), AP5 Working Meeting, Berlin, 28-Nov-2007

2

Contents

Terminology Survey Results

Standard Survey Results

Survey Conclusions

Proposal for a Requirement Development Strategy

European Project Analysis (EMMA, FASTI, VICTORIA)

3

Concept Terminology

Concept-related Terminology

Operational Concept

High-level ConceptHigh-level Description ofATM Services and Environment

Concept of Operations (Use)Operational/User Needs/RequirementsOperational ProceduresAirspace OrganisationFunctions and ProcessesInteractions and Information FlowsInvolved ActorsRoles and Responsibilities

SESAR

EATME-OCVM

IEEE 1362

4

Requirement Terminology

Requirement (IEEE, FAST, SESAR)

Condition or capability needed by user to solve problem or achieve objective

Condition or capability that must be met or possessed by system or system component to satisfy contract, standard, specification or other formal document imposed

5

Needs and Requirements

Operational Requirement

User Requirement Organisational Requirement

Stakeholder Needs

Technical Requirement

System Requirement

Functional Requirement Non-functional Requirement

Interface Requirement

Implementation Requirement

Physical Requirement

Design RequirementPerformance Requirement

System Specification

Requirement Specification

Functional Specification

Design, Behaviour, Characteristics, Verification

Operational Requirement

User Requirement Organisational RequirementUser Requirement Organisational Requirement

Stakeholder Needs


System Requirement


System Requirement





















R&DFocus

I mplementedConcept

I nitialI dea

Scope

Feasibility

Integration

Pre-Operational

Operational

V1

V2

V3

V4

V5

ATM NeedsV0

?

6

Architecture Frameworks

Enterprise Architecture (EA)Description of the structure and the behaviour of the

processes, information systems, personnel and sub-units in an organisation in line with the core goals and the strategic direction of the organisation

Service-oriented Architecture (SOA)Establishes an architectural model that aims to enhance

the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realisation of the strategic goals associated with service-oriented computing

9

Analysis of Software Standards

IEEE 1362 - Guide for IT System Definition, ConOps Bridges gap between user needs and developer technical

specification ConOps provides:

– Means of describing user operational needs– Description of system characteristics without user requiring

technical knowledge– Statement of user desires, visions, expectations (quantified

by developer in requirements analysis)– Description of possible/acceptable solution strategies and

design constraints

IEEE 830 - Software Requirements Specification Jointly prepared by supplier and customer (strong participation

of industry) Specifically mentions site adaptation requirements

IEEE 1233 - System Requirements Specification Shows interactions among various agents necessary to develop

a System Requirements Specification

10

Analysis of Hardware Standards

IEEE 15288 – Systems Engineering System life-cycle model for products/services Stakeholder requirements definition and analysis

ECSS E10/E40 – Systems/Software Engineering Concise prescriptions for suppliers Provide information on requirement-related issue, such as

traceability, wording, specification trees, documentation, and baselining

ED 79/12B/80 – Airborne Software/Systems/Hardware Engineering

Address safety-critical airborne applications ED 79 focuses on safety assessment (incl. requirements

capture) ED 12B describes high-level requirements that need to be

detailed at software level ED 80 is hardware equivalent of 12B with additional info on

requirements standards for capturing process Describes consequences for hardware requirements

12

ED78A Process

Co-ordinated Requirements Determination

Operational Services and Environment Information Capture

Operational Safety Assessment

Operational Performance Assessment

Interoperability Assessment

OSED

INTEROP

SPR

StakeholderAllocated

Requirements

Evidence of Analysis,

Co-ordination and Validation

15

Survey Conclusions

TerminologyUseful to distinguish between:

– High-level concept document– Concepts of Operation or Use

Distinction between:– Stakeholder needs (user/raw requirements)– Formal requirements

StandardsGeneral requirement development process can be

divided into two major processes:– Requirements Elicitation or Capture Process– Requirements Analysis or Specification Process

16

Extended IEEE 1233 Process

DevelopRequirements

Collection

Customer

EnvironmentTechnical

CommunityConstraint/Influence

TechnicalRepresentation

CustomerRepresentation

CustomerFeedback

Raw Requirement

TechnicalFeedback

ConceptDevelopment

ValidationCommunity

ValidationResults

OperationalFeedback

RequirementSet

17

Requirement Development Strategy

Produce an outline for an appropriate strategy related to requirements engineering in Operational Concept Validation and its evolution along the lines of the OCVSD and E-OCVM lifecycle model:

Based on findings of standards analysis

Ownership issues will be highlighted

Should not limit itself to a single existing model but should incorporate several aspects (variations or tailored solutions)

18

Processes/Actors - Parallel Streams

I mplementedConcept

I nitialI dea

Scope Feasibility Integration Pre-Operational Operational

V1 V2 V3 V4 V5

ValidateConcept

Principles

ValidateOperability

AcceptabilityUsability

ValidatePerformance

I ndustrialisationand Approval

I mplementation

ATM Needs

V0

DetermineATM Stakeholder

Needs

R&D Focus

CaseBuilding

Procedure/ HMIFeasibility

PerformanceAssessment

OC Description

RequirementsCapture

Refine ConOps / Procedures

(Many)Prototypes

Final Prototype

Refine Requirements

I nitial Procedures

VerifyRequirements

VerifyRefined

Requirements

Requirements Capture

SystemSpecification

Concept DevelopmentConcept Development

System DevelopmentSystem Development

19

Actors in OCV

System Development Team

Requirement Development Team

Concept Development Team

Validation Team

Scope Feasibility Integration Pre-Operational Operational

V1 V2 V3 V4 V5

ATM Needs

V0

Regulators

Decision MakersCustomers

Other ATM Stakeholders

Decision MakersCustomers

Other ATM Stakeholders

R&D to Industry Transition

ATM Stakeholders(Airports, Airlines,

ANSPs)

ATM Stakeholders(Airports, Airlines,

ANSPs)

20

Proposal for Requirement Development

SystemSpecification

RC1.0 RC2.0

RA1.0

V0 V1 V2 V3

ConceptDevelopment

SystemDevelopment

RA2.0 RA3.0

RequirementsManagement

Raw RequirementsInitial Requirements

Refined Requirements

RequirementsSpecification

Raw RequirementsInitial Requirements

Refined Requirements

RequirementsSpecification

High-level OCDInitial ConOps

Refined ConOpsFinal ConOps

High-level OCDInitial ConOps

Refined ConOpsFinal ConOps

Initial System RequirementsInitial Prototypes

Refined Prototypes

21

Iterative Processes (in Phase V2)

RA1.1 RA1.2

V2.1 V2.2 V2.3

ConceptDevelopment

SystemDevelopment

RA1.3

V2.n

RA2.0

RequirementsManagement

Reqs 1.0

Reqs and DJ F 1.1

Reqs and DJ F 1.2 Requirementsand DJ F 2.0Reqs and DJ F 1.3

Reqs 1.0

Reqs and DJ F 1.1

Reqs and DJ F 1.2 Requirementsand DJ F 2.0Reqs and DJ F 1.3

Prototype 1.0

Prototype 1.1

Prototype 1.2Prototype 2.0

Prototype 1.3

Prototype 1.0

Prototype 1.1

Prototype 1.2Prototype 2.0

Prototype 1.3

ConOps 1.0

ConOps 1.1

ConOps 1.2ConOps 2.0

ConOps 1.3

ConOps 1.0

ConOps 1.1

ConOps 1.2ConOps 2.0

ConOps 1.3

22

Selection Process (in Phase V2)

RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3

V2.n

RA2.0RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3

V2.n

RA2.0

RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3

V2.n

RA2.0RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3

V2.n

RA2.0

RA1.1

V2.1

RA1.1 RA1.2

V2.1 V2.2

RA1.1 RA1.2

V2.1 V2.2

RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3RA1.1 RA1.2

V2.1 V2.2 V2.3

RA1.3

23

Lifecycle

1 2 3 4Stakeholderrequirements

definition

Requirementsanalysis

Architecturaldesign

Detaileddesign

I mplementation

Subsystemverification

I ntegration

Verification

Validation

1 Study2 Concept3 Prototype4 Final system

24

EMMA Project

EMMA follows ED78A methodology:

technological enablers already available

main effort in tuning HMI and performance oriented simulations (V3)

verification described as validation of conformance with standards (ICAO MASPS and MOPS)

technical requirements are subset of operational requirements and interoperability requirements

D1.3.1 OSED

Air-Ground Operational Services and Environment

D1.3.1 OSED

Air-Ground Operational Services and Environment

D1.3.5 ORD

Operational Requirements

D1.4.1 INTEROP

High Level Air-Ground Functional

Architecture

D1.4.1 INTEROP

High Level Air-Ground Functional

Architecture

D1.4.2a TRD-Ground

Functions

Performance

Interface

Technical Requirements

D1.4.2a TRD-Ground

Functions

Performance

Interface


Functions

Performance

Interface


D1.4.2b TRD-Air

Functions

Performance

Interface


D1.4.2b TRD-Air

Functions

Performance

Interface


Functions

Performance

Interface


EMMA-1 Sub-projects

Specific Test Bed Adaptations

EMMA-1 Sub-projects

Specific Test Bed Adaptations

25

FASTI Project

Coordination of implementation and deployment of:Medium Term Conflict Detection (MTCD),Monitoring Aids (MONA), System Supported Coordination (SYSCO),across ECAC by 2012

Validation follows E-OCVM

FASTI Operational Concept (pre V3) in July 2006

Baseline description with operational requirements accompanied by implementation guidelines based on analysis of developmental systems of three ANSPs and the Eurocontrol PROVE implementation.

Operational concept is basis for elaboration of safety, performance, human factors, and operational requirements required for implementation.

26

VICTORIA Project

EU 5th framework project 2001 - 2004

Validation of standardised components and technologies for improved aircraft electronic systems

Core team of European aeronautics industries

Approach:Design new aircraft electronics

– Develop overall architecture– Capture component requirements– Capture interface requirements

Validate functionality– Develop validation platform– Develop test plan– Experiment with validation platform

27

Conclusions and Recommendations

Survey of Standards and Terminology leads

Proposal for a Requirement Development Strategy

Three major requirements management processesRequirements Capture ProcessRequirements Analysis ProcessRequirements Management Process

Central role of a programme manager or development strategy manager closely monitoring progress through the life cycle phases

BUT:Differences in system component maturity make it

difficult to exactly follow one strategy

28

Questions

??

Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy...

Documents

Transcript of Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy...