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
Technical Requirement
System Requirement
Technical Requirement
System Requirement
Functional Requirement Non-functional Requirement
Interface Requirement
Implementation Requirement
Physical Requirement
Design RequirementPerformance 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
System Specification
Requirement Specification
Functional Specification
Requirement Specification
Functional Specification
Design, Behaviour, Characteristics, Verification
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
Technical Requirements
Functions
Performance
Interface
Technical Requirements
D1.4.2b TRD-Air
Functions
Performance
Interface
Technical Requirements
D1.4.2b TRD-Air
Functions
Performance
Interface
Technical Requirements
Functions
Performance
Interface
Technical Requirements
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
??
Top Related