System Model Meteor; Pre study report, unclassified part
Publish date: 2015-05-18
Report number: FOI-R--4080--SE
Pages: 36
Written in: Swedish
Keywords:
- Meteor
- requirement
- requirement analysis
- acceptance requirements
- model
- requirements
- verification
- validation
- V&V
- air-to-air missile
- missile technology
- modelling
- simulation
- model
- MERLIN
- GM-VV
- phenomena
- scenario
- system
- model
- user story
- weapons
Abstract
Requirements (unclassified) and a number of technical aspects on a system model of the Meteor air-to-air missile are described on a general level. This document is addressed to all stakeholders, in order to establish broadly stated requirements and an applicable methodology for the elicitation, development and definition of requirements. This document should be seen as a first attempt at a requirements definition. The air-to-air missile Meteor is introduced with the JAS 39C/D MS20. A real-time model for this missile requires that lucid and clear prioritizations are made in order to achieve a real-time model within a reasonable time for development. A general idea for a requirement methodology is described. Several general discussion questions regarding the Meteor system model are answered. Several recommended operational principles are described for the future work with the system model. The requirement and requirement methodology effort for this purpose is motivated. A great emphasis is put on a high level description of the requirements, in order to effectively (and efficiently) communicate requirement definitions between users and buyers, and developers and subject matter experts respectively. The requirement breakdown structure is divided into acceptance requirements, model requirements and implementation requirements. In acceptance requirements the model is seen as a product, in order for vocabulary and methods from the field of commercial technical product development to be applicable. Going from defined simulation scenarios in the acceptance requirements, model requirements are then elicited by describing type cases and distinguishing features which the model is expected to express. The resulting conceptual model description can then be translated into implementation requirements, where process and non-functional requirements also can be included. Acceptance requirements, user stories and non-functional requirements are defined for the actual model. Unclassified requirements only are defined in this report. A general solution is outlined and motivated. The MERLIN framework is recommended as the simulation framework of choice.