Presentation is loading. Please wait.

Presentation is loading. Please wait.

Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy Ir. Y.A.J.R. van de Vijver (NLR), AP5 Working Meeting,

Similar presentations

Presentation on theme: "Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy Ir. Y.A.J.R. van de Vijver (NLR), AP5 Working Meeting,"— Presentation transcript:

1 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 2 Contents Terminology Survey Results Standard Survey Results Survey Conclusions Proposal for a Requirement Development Strategy European Project Analysis (EMMA, FASTI, VICTORIA)

3 3 Concept Terminology Concept-related Terminology Operational Concept High-level Concept High-level Description of ATM Services and Environment Concept of Operations (Use) Operational/User Needs/Requirements Operational Procedures Airspace Organisation Functions and Processes Interactions and Information Flows Involved Actors Roles and Responsibilities SESAR EATM E-OCVM IEEE 1362

4 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 5 Needs and Requirements

6 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

7 7 Zachman Framework

8 8 Other Terminology SES and EASA-ETSO related Regulatory Requirement: –Poses constraint on a system developed in the context of SES based on Interoperability Regulations of the EC Community Specification (CS): –System has to comply with CS which is developed by the European standardisation bodies together with EUROCAE –Contains Implementation Rules (IRs) and Essential Requirements (ER) that must be met Compulsory ERs: –Seamless Operation –Safety –Civil-military Co-ordination, –Support of New Concepts of Operation –Environmental Constraints –Principles Governing the Logical Architecture –Principles Governing the Construction of Systems

9 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 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

11 11 ED78A Process (1)

12 12 ED78A Process

13 13 ED78A EC EUROCONTROL Regulatory Process Standardisation of ATM operational, functional requirements - Operational, functional requirement standards - OSEDs Concept of Operation EUROCONTROL EUROCAE Other inputs EUROCONTROL with industry participation EUROCAE with participation of CNS/ATM stakeholders EUROCAE Standards Standardisation of ATM products ICAO Panels & Worldwide consultation Regulations ICAO SARPS

14 14 ED78A OR

15 15 Survey Conclusions Terminology Useful to distinguish between: –High-level concept document –Concepts of Operation or Use Distinction between: –Stakeholder needs (user/raw requirements) –Formal requirements Standards General requirement development process can be divided into two major processes: –Requirements Elicitation or Capture Process –Requirements Analysis or Specification Process

16 16 Extended IEEE 1233 Process

17 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 18 Processes/Actors - Parallel Streams

19 19 Actors in OCV

20 20 Proposal for Requirement Development

21 21 Iterative Processes (in Phase V2)

22 22 Selection Process (in Phase V2)

23 23 Lifecycle 1 Study 2 Concept 3 Prototype 4 Final system

24 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

25 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 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 27 Conclusions and Recommendations Survey of Standards and Terminology leads Proposal for a Requirement Development Strategy Three major requirements management processes Requirements Capture Process Requirements Analysis Process Requirements 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 28 Questions?

Download ppt "Role of Requirements in Operational Concept Validation (RORI-OCV) Requirement Development Strategy Ir. Y.A.J.R. van de Vijver (NLR), AP5 Working Meeting,"

Similar presentations

Ads by Google