<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-ohWBVoEzaU7wSzN_peWXAQ" name="new_roadmap,_bfRb4GisEeG1s-OXvXxUUA" guid="-ohWBVoEzaU7wSzN_peWXAQ">
  <mainDescription>&lt;h3>&#xD;
    Policies&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    We propose the following Policies for the implementation of RDE:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        All requirements from all stakeholders shall be captured and maintained.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        All requirements from all stakeholders shall be analysed and understood.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        All requirements from all stakeholders shall be controlled and managed.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        All changes to requirements shall be managed.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Those requirements that constitute Key Requirements shall be identified.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The requirements shall form the basis for the engineering plans and the design including lower level designs.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The qualification and acceptance criteria shall be determined.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The requirements and their qualification and acceptance criteria shall be agreed with all interested parties.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A requirements traceability audit trail shall be maintained throughout the development activities.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Systems Engineering Approach&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    A System is defined to be an integrated composite of people, products, services and processes that provide a capability&#xD;
    to satisfy a stated need or objective.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Systems engineering is defined to be an interdisciplinary approach and means to enable the realisation of successful&#xD;
    systems, taking into account the lifecycle, the customer and stakeholder needs, and the processes and technical&#xD;
    management of design and engineering projects.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Systems engineering (SE) is the branch of engineering concerned with the development of large and complex systems,&#xD;
    where such a system is understood to be an assembly or combination of interrelated elements working together to achieve&#xD;
    a common objective. The products of organizations using this process can be described as complex systems.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A large system may involve 20-30 different groups of specialists such as design engineers, stress engineers or project&#xD;
    managers. Each discipline has its own tools, languages and specialist knowledge.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    SE techniques establish the confidence that the system has been developed in a sufficiently disciplined manner to limit&#xD;
    the likelihood of errors that could affect stakeholder requirements and system safety. If used in its fullest sense, SE&#xD;
    methods can also be utilised to ensure that the product is developed in an economic and timely manner. For this to&#xD;
    happen, SE must be integrated with the Product Lifecycle Management process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In summary, SE generates the technical specification, candidate solutions and design and product evidence in a&#xD;
    controlled environment. Time-scales, cost, resources etc are then factored in to develop the most suitable solution for&#xD;
    final implementation. The development work must also respect the organization’s lifecycle control mechanisms. The&#xD;
    development milestones of the Example Product Lifecycle, shown in Figure 1 identify an example subset.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Example Product Lifecycle&quot; src=&quot;./resources/example_product_lifecycle.jpg&quot; width=&quot;575&quot; height=&quot;439&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that this lifecycle example should not be taken as implying a waterfall process. This is explained further later&#xD;
    in the document.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Top Level Objectives of Systems Engineering Approach&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The Top Level project objectives of a SE approach are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        To provide a consistent, repeatable, and auditable approach to developing high quality systems.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To ensure ‘customer and stakeholder’ needs are understood and realised.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To reduce the product development lifecycle by early identification of all requirements and by supporting&#xD;
        Concurrent Engineering at all levels of development.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To contribute to the certification and ‘sell off’ of the system and its sub components (Structures and Systems&#xD;
        etc).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To facilitate ‘Trade Offs’ between Project Time, Cost and Quality (Specifications).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To reduce product development rework and risks – right first time!&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        To reduce the communication ‘effort’ between all parties on the project.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    SE is more specifically defined by the capabilities and objectives described below.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Communications&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the communication between an organization and its customers, partners and suppliers.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to support the design and product review process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to apply a consistent approach to the writing of requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to give all teams early visibility of all information.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the measuring of progress.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Interface to other Engineering Disciplines&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to support a common interface to specialist domains such as Safety, Supportability, Certification, ‘the&#xD;
        business’, Risks etc.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability of the process to facilitate ‘tailoring’ to the specific domain – e.g. structures or systems.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the certification of a system.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Re-use&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the ‘re-use’ of requirements for future projects.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to provide a common way of working (repeatability of process) for projects and Centres of Competence.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to provide the reference process model for continuous improvement activities and training.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Integration&#xD;
&lt;/h4>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the activities involved when integrating product and programme needs.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the Integration of the products.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Requirements Engineering&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Meeting the requirements on a project defines success. Failing to engineer or manage the correct requirements at any&#xD;
    level decreases the probability of meeting the stakeholder needs.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements that are over and above what is necessary to meet the stakeholder needs lead to an over-specification of&#xD;
    the product, with subsequent increased recurring and non-recurring costs.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Omitted requirements lead to an under-specification of the product, with resultant stakeholder dissatisfaction and&#xD;
    subsequently increased costs to rectify the situation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Incorrect requirements lead to mis-specification, with resultant stakeholder dissatisfaction and subsequently increased&#xD;
    costs to rectify the situation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements engineering is largely defined by:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to elicit/generate requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to document the requirements (in context).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to ensure the right requirements are being used as a basis for design.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to translate capability requirements into functional behaviour.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to cascade requirements down from top-level system specifications / programme directives to the appropriate&#xD;
        level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the agreement of the requirements between parties (between levels and between transverse&#xD;
        requirement authorities and development teams).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to be able to prove that the requirements output from the Design (to lower level teams) meet the&#xD;
        requirements that were input to the design.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Design&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    Overview&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Design is a creative process of:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        defining an overall architectural approach.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        deciding exactly which underlying systems and subsystems are necessary.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        apportioning the characteristics (requirements) of the overall system to subsystems.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        proving that the design meets the requirements, at a particular level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        defining interfaces between subsystems&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Note that this process takes into account, indeed relies on, emergent properties of the combination of subsystems to&#xD;
    create characteristics of the overall system that are not present in the subsystems individually.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    CAVEAT: Each specialist domain should follow the existing documented design process for that domain. It is not the&#xD;
    purpose of this document to define how each specialist domain ’designs’. Similarly, this document does not cover&#xD;
    specific verification process and procedures.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Partitioning&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Because large systems are difficult to manage, a common technique employed is to divide a single large system into&#xD;
    smaller systems. An architectural design will be created from the top-level customer specifications that will identify&#xD;
    systems or sub-systems that comprise the functionality of the overall large system. Consequently, there is a&#xD;
    relationship between the levels and the associated architectural design. This design will allow engineers/designers to&#xD;
    define a Product Breakdown Structure (PBS) or sometimes referred to as Bill of Materials (BoM).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    System Engineers will define the underlying systems and subsystems ensuring that these entities contribute to deliver&#xD;
    the functionality required by the top-level customer.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 2 shows a typical decomposition of a product into lower levels.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;The Concept of levels and partitioning&quot; src=&quot;resources/concept_level_and_partitioning.jpg&quot; width=&quot;472&quot;&#xD;
    height=&quot;312&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each level is typically the responsibility of a specific development team and there must be agreement between the&#xD;
    levels to define the responsibilities of each level. Thus there exists a form of ‘customer-supplier’ relationship&#xD;
    between levels with the upper level acting in the role of customer for the work done by the one or more suppliers at&#xD;
    the lower level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The customer-supplier relationship involves agreement and negotiation on:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The requirements that will be satisfied by the supplier;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The way in which the supplier intends to respond to the requirements (i.e. the proposed products);&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The way in which the products developed will be verified on delivery;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The agreement of evidence that the delivered products are satisfactory.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    These agreements evolve over time in the sequence implied by the above list. In addition to the formal agreement on&#xD;
    these issues, there will also be the need to have a common understanding of the domain knowledge and other background&#xD;
    information that, although not contractually binding, is nevertheless vital. In the description of the RDE process that&#xD;
    follows, the term “specification” indicates a document that contains:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A well organised structure in terms of headings and sub-headings;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Appropriate descriptive information that provides context and background for the intended development;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &quot;Contractual&quot; statements that may be requirements, means of compliance, test procedures etc.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Logical vs. Physical Architecture&#xD;
&lt;/h4>&#xD;
&lt;h5>&#xD;
    Logical Architecture&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    The logical architecture provides a description of the solution and defines the interfaces. The logical architecture&#xD;
    defines the processes (the activities and functions) that are required to provide the desired capabilities. The logical&#xD;
    architecture is the result of the preliminary analysis. Many different processes must work together and share&#xD;
    information to provide a capability. The processes can be implemented via software, hardware, or firmware. The logical&#xD;
    architecture is independent of technologies and implementations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is important to understand that logical architecture is a precursor to physical architecture. In other words, the&#xD;
    physical implementation must provide the desired capabilities, not the other way around. Too often, this is not done&#xD;
    and an inordinate amount of time and money are spent devising a technical solution without fully understanding the&#xD;
    logical architecture. Failure to do so is an exercise in futility.&#xD;
&lt;/p>&#xD;
&lt;h5>&#xD;
    Physical Architecture&#xD;
&lt;/h5>&#xD;
&lt;p>&#xD;
    The physical architecture describes the structure for the implementation. The physical architecture is the&#xD;
    instantiation of the logical architecture into detailed physical assemblies. The physical architecture is the result of&#xD;
    the detailed design process. The physical architecture will provide the realization of the desired capabilities.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Where the logical architecture describes the functionality needed of the system to provide the capabilities that the&#xD;
    stakeholders expect, the physical architecture defines how the logical architecture will be allocated to the&#xD;
    subsystems, components that are needed to provide the desired capabilities.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Verification and Validation&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Verification and validation covers:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Product verification: Ability to prove that the product meets the requirements, at a particular level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Product validation (product verification at the top level).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design verification: Ability to provide evidence that a proposed design will meet the requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Requirement validation: Ability to provide evidence that requirements at tone level satisfy those at a higher level&#xD;
        (at the top level, this is showing that the defined requirements express the stakeholder needs).&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Impact Analysis&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Specialist Domains&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The specialist domains are those that consider specific concerns that nonetheless can affect all aspects of a system.&#xD;
    We believe that these can be treated in a generic manner, as they will tend to analyse the stakeholder needs and the&#xD;
    results of the “mainstream” development at each level and impose requirements upon it. For example, the presence of a&#xD;
    requirement might lead to the identification of a risk, which in turn could lead to the definition of other&#xD;
    requirements for mitigation and fallback. We will use Risk Management as the archetype.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The specialist domains represent a source of requirements that must be considered at each level of development. It may&#xD;
    be necessary to introduce several requirements to satisfy a single requirement from one of these domains. Further,&#xD;
    these requirements may not all be addressed at the same level or by the same team. It is the responsibility of the&#xD;
    specialists within each team and the overall domain specialist to ensure that a complete set of requirements is&#xD;
    introduced to satisfy each specialist requirement or regulation. Figure 3 (derived from DO-178B) shows a typical&#xD;
    approach to how the specialist domains, in particular Safety, work with development throughout the development&#xD;
    lifecycle.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Interaction of Specialist Domains and Development (example from aircraft manufacture)&quot;&#xD;
    src=&quot;resources/interaction_domains_development.jpg&quot; width=&quot;565&quot; height=&quot;464&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that the specialist domains identified will vary between organizations. Those given are typical of aircraft&#xD;
    manufacture, similar specialisms would be found in other areas&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Risk Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Risk Management is largely defined by the ability to identify and facilitate the closeout of assumptions and&#xD;
    non-compliances. Risks are often divided into categories. The following is a typical set (derived from that&#xD;
    historically used in UK Defence Procurement):&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Political: risk that the project is cancelled as it no longer meets political needs (equivalent to stakeholder&#xD;
        needs changing).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Commercial: risk that commercial agreement cannot be reached with suppliers.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Technical: risk that the project cannot be delivered for technical reasons.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Managerial: risk that the requirements and constraints on the project cannot be balanced.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Financial: risk that the project will go over-budget.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Programme: risks on the programme to which this project belongs.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Industrial: risk that the system cannot be manufactured.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Safety Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Performance Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Data Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Environmental Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Change Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Analysis and Modeling&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Configuration Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The four main areas of Configuration Management (CM) are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Configuration Identification.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Configuration Control (including change management).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Configuration Audits.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Configuration Status Accounting.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Configuration management is largely defined by:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Ability to facilitate changes in a controlled manner.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate the defining of configuration items.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate configuration audits.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to facilitate configuration status accounting activities.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to capture the history of changes over time (with rationale).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Ability to perform impact/traceability and sensitivity analysis.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Project Management&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
