<?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="-Bmj1enfVOpp9ISbZJzisgQ" name="new_roadmap,_vN_pQGisEeG1s-OXvXxUUA" guid="-Bmj1enfVOpp9ISbZJzisgQ">
  <mainDescription>&lt;h3>&#xD;
    Overview&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Figure 4 introduces the concept of the V model and illustrates the scope of RDE. It depicts how Requirement Driven&#xD;
    Engineering (RDE) covers the whole engineering lifecycle from understanding stakeholder needs, translating and then&#xD;
    cascading these requirements to applicable teams, developing a solution, proving that intermediate designs/products&#xD;
    meet the appropriate level requirements, then finally proving that the product delivered to the customer meets their&#xD;
    needs.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Generic Requirements-Driven Engineering Overview&quot; src=&quot;resources/generic_rde_overview_fig4.jpg&quot; width=&quot;546&quot;&#xD;
    height=&quot;439&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    From the application of this approach on many complex systems projects, it is evident that RDE can contribute to a&#xD;
    successful project outcome by:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Proving that the requirements being cascaded down satisfy the requirements at the level above.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Proving that the design solution satisfies the requirements (at each level).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Proving that the delivered product(s) at each level conform to the requirements placed on their development (at&#xD;
        that level).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Proving that the final delivered product conforms to the user needs.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The process activities and tasks described in this document are conducted within a configuration management (CM)&#xD;
    framework. The main areas of CM are defined in Section 2.17.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The primary configuration items that must be developed and controlled are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Requirements Baseline.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design Baseline.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Product Baseline.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Only by rigorously analysing what is required can engineers and others understand what commitments are being made.&#xD;
    Commitments have to be expressly agreed and understood on both sides for them to be consistently met on time. RDE is a&#xD;
    process of ensuring that the needs of the stakeholder can be met expressly and demonstrably. This necessitates&#xD;
    explicit, unambiguous, related and traceable statements that define what is to be achieved at each stage of the product&#xD;
    lifecycle (concept, development, manufacture, in service support and retirement), within the context of:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        The decomposition of the product itself.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The development of the product in a concurrent iterative environment.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Management of change in that environment.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Many organizations will follow process standards, such as ISO-9001; development standards, such as EIA-632, EIA-732,&#xD;
    IEEE12207, DO-178B; or process improvement approaches such as CMMI. The needs of these standards must be taken into&#xD;
    account in developing processes.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 5 indicates the process activities (at each level) to be focused on with respect to the development milestones&#xD;
    defined in the Example Product Lifecycle (Figure 1).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;RDE Process in Context with Lifecycle Milestones&quot; src=&quot;resources/rde_process_fig5.jpg&quot; width=&quot;576&quot;&#xD;
    height=&quot;376&quot; />&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Systems, Software, and Mechanical&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Figure 6 shows a generic requirements cascade for systems development.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Generic Requirements Document Cascade&quot; src=&quot;resources/generic_req_document_cascade_fig6.jpg&quot; width=&quot;560&quot;&#xD;
    height=&quot;439&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In the requirements cascade shown in Figure 6, the agreed Customer Needs (or Contract) for the system and the top-level&#xD;
    requirements will be derived from an analysis of Stakeholder Needs and will be the source of all Stakeholder&#xD;
    Requirements. Using the Systems Engineering partitioning approach described in Section 2.4, a number of subsystems are&#xD;
    identified, and a System Requirements Document prepared for each, together with a single Systems Requirements Document&#xD;
    for each domain covering general system functions that apply at the overall level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The subsystems are divided into two areas, Structure and Systems / Software.. In many cases, the top-level manufacturer&#xD;
    is responsible for physical elements (Structures) and third-party suppliers (vendors) are responsible for the elements&#xD;
    that deliver functionality (Systems and Software). There is one Top Level Structure Requirements Document for each&#xD;
    major Structure, corresponding to the relevant X-SRD. System/Software element is defined by a set of System&#xD;
    Requirements Documents (SRDs – typically just one per system). At the bottom level are Component specifications that&#xD;
    will be issued to the supplier organization (in-house,whereas systems are manufactured by sub-contractors.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Although this division into Structures and Systems/Software is typical, it should not be regarded as rigid. Indeed, in&#xD;
    many cases, there is no separation at all. For example, a manufacturer of an embedded chip to be used in some other&#xD;
    system will probably not distinguish between the two, although the design and manufacture of the package will be done&#xD;
    by different disciplines from the design and manufacture of the chip.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is imperative that Interface Control Documents are compiled that define the interfaces between the domains.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that this cascade only shows requirements documents, it does not include design information or other related&#xD;
    information, such as verification and validation.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Process Detail - V Model&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    In order to develop the RDE concept further it is necessary to introduce more rigour to distinguish between process&#xD;
    steps and the artefacts that they manipulate. We will adopt the Process, Activity, Task, Step approach, where the&#xD;
    overall Process is decomposed into a number of Activities, each of which has a number of Tasks that in turn are&#xD;
    composed of a set of Steps.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Using the diagramming conventions defined in Section 17, we can expandFigure 4 and redraw it as shown in Figure 7. Note&#xD;
    that because we have now included general development activities and not just requirements we have renamed the left&#xD;
    hand side the &quot;Development Hierarchy&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Multiple levels of decomposition using the same process&quot; src=&quot;resources/multi_level_decomp_fig7.jpg&quot;&#xD;
    width=&quot;523&quot; height=&quot;396&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The representation in Figure 7 is the classic systems engineering “V-model”. Note that this is may appear as if a rigid&#xD;
    waterfall process is implied, however, this is not the case as the model simply shows that there are relationships&#xD;
    between the information and artefacts, but not necessarily on the basis of time. Therefore, it is equally relevant to a&#xD;
    traditional waterfall, iterative or agile development approach.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Development Levels&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    From Figure 7, because of the conventions adopted, we can see that there is at least one development process at each&#xD;
    level. At the top level, the process takes the user needs and creates the top-level system requirements (TLSRs)&#xD;
    together with further stakeholder or contractual technical documents based on an initial overall design of the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The next level, ‘Level-1’ takes the TLSRs and, based on a more detailed design, develops specific requirements for the&#xD;
    Major Components of the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At ‘Level-2’ there are several concurrent development processes, each corresponding to one of the major components.&#xD;
    These teams further decompose the design into lower level components and generate specific requirements for each one&#xD;
    that form the input requirements for the developments at ‘Level-3’. This process of decomposition continues until&#xD;
    specific components are identified that can be manufactured by the organization, its partners or its suppliers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that this scheme of levels and decomposition between levels does not imply a waterfall approach. There is nothing&#xD;
    in this diagram, or indeed this document, that should be taken as implying that one level of the development hierarchy&#xD;
    (left hand side of the “V”) must be completed before the next level is started. All that is necessary is that a level&#xD;
    must be able to provide sufficient information to the next level for the degree of risk involved in starting work at&#xD;
    that next level to be acceptable. In many cases, this does imply a waterfall, as the adopted risk reduction strategy is&#xD;
    to know as much as possible before continuing. The use of requirements management tools allows the maturity of&#xD;
    individual specification elements (requirements or design) to become approved – this is generally sufficient for&#xD;
    derivative work at the next level to continue.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The right hand side of the ‘V’ in Figure 7 indicates the composition of the Final Product by the successive delivery&#xD;
    and integration of items supplied from one level to the level above. At each level, there must be verification that&#xD;
    each delivered item satisfies the relevant requirements at that level. At the top level, there will be no integration&#xD;
    activities because the complete system is delivered, as at ‘Level-1’. It is necessary to check that the verification&#xD;
    activities undertaken at 'Level-1' show that the system satisfies the TLSRs and any other contractual technical&#xD;
    documents. However, the main activity at this top level is to prove that the system as delivered satisfies the User&#xD;
    Needs. This is the process of Product Validation and it replaces the process of product verification at this level.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    What Levels?&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    You may ask the question &quot;How do I decide what levels to use?&quot;. The answer, as so often in Systems Engineering, is &quot;It&#xD;
    depends&quot;. And what it depends on is abstraction. That is, the levels which should be used are driven primarily by the&#xD;
    abstraction levels needed. The abstraction level reflects the &quot;distance&quot; from a concrete solution. Thus a design&#xD;
    showing specific physical components is slightly more abstract than the implementation, whereas a statement such as &quot;We&#xD;
    wish to improve customer satisfaction&quot; is highly abstract.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For a simple system, it may sufficient to have a single level specifying stakeholder requirements, a single level for&#xD;
    system requirements, a single level of subsystems requirements. The first two would be single specifications, the last&#xD;
    would have one specification for each subsystem. This is because the difference in the levels of abstraction are small&#xD;
    enough to be manageable. In more complex systems, more levels would be needed. For example for aircraft, it is common&#xD;
    to have a requirements cascade similar to that shown in Figure 8.&#xD;
&lt;/p>&lt;br />&#xD;
&lt;p>&#xD;
    In this example, the Top-Level Business Requirements are the business-facing requirements gathered from stakeholders.&#xD;
    The Aircraft Requirements are the top-level capabilities required of the aircraft. This is typically a small set of&#xD;
    fewer than a hundred requirements. The next two levels reflect a functional decomposition – in the first, the top-level&#xD;
    aircraft requirements are allocated to major functional groups (typically five to twelve) and decomposed. In the second&#xD;
    level, these requirements are allocated (within each document) to systems and further decomposed. Each system then&#xD;
    manages its allocated requirements.&lt;br />&#xD;
    The reason this is done is that there is typically a large difference in abstraction level between the aircraft&#xD;
    requirements and those at the system level. The intermediate levels help in bridging this gap.&lt;br />&#xD;
    As an example, consider the following for a car :&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        At the car level, there is a requirement (problem statement) &quot;The driver shall be able to obtain journey&#xD;
        information&quot;.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        We can decompose this into more detailed requirements (problem statements, which would need to be agreed with the&#xD;
        owner of the car level requirement to ensure that they were acceptable) &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                The driver shall be able to see the vehicle’s speed.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The driver shall be able to obtain the vehicle’s location.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The driver shall be able to obtain the estimated time to the destination.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The driver shall be able to obtain guidance information.&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Each of these statements can be turned into a solution statement, for example: &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                The vehicle shall display the vehicle’s speed.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                On request, the vehicle shall display the vehicle’s location.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                On request, the vehicle shall display the estimated time to the destination.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                On request, the vehicle shall display obtain guidance information.&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        These requirements will be allocated to different systems, the first to the vehicle’s speedometer (part of the car&#xD;
        instrumentation system), and the others to the navigation system. Of course, they will be further decomposed. For&#xD;
        example, the last may decompose into: &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                The navigation system shall have knowledge of the road system.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The system shall inform the driver of the time and distance to the next junction.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The system shall inform the driver of the direction to take at the next junction.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                If the next junction is a roundabout (turning circle), then the system shall inform the driver of the exit&#xD;
                to take.&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                The system shall ignore junctions except those where the driver needs to take some action.&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The proposed model can easily be adapted, providing the essential concepts are maintained. As this is a natural way of&#xD;
    working and is used by all organizations in aerospace with whom we have worked (and those in other engineering and&#xD;
    manufacturing areas), we see no reason why it should change.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that the first decomposition is acting on problem statements. As soon as we start to allocate these requirements&#xD;
    to systems within the car, we need to take into account design. Decisions about what systems will be needed are the&#xD;
    essence of design and the allocation of requirements to those systems is an iterative process with design. In a sense,&#xD;
    the task of the designer is to decide what systems will be used to solve a problem and to allocate requirements to&#xD;
    those systems, taking into account all known and derived constraints and the needs for those systems to interact.&#xD;
    Therefore, the designer is also making choices about the best combination of systems, within constraints, to maximise&#xD;
    satisfaction of the requirements, knowing that, in practice, it is unlikely that all can be fully satisfied. Therefore,&#xD;
    there is a need for trade-off decisions.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is impossible to give a hard and fast rule to determine the necessary levels, partly because it is not possible to&#xD;
    provide a measure for abstraction. It is a difficult balance between having small enough abstraction gaps to be&#xD;
    manageable and having too many levels of documentation – each level takes time to create and increases the amount of&#xD;
    work involved in creation and maintenance.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Similarly, it is impossible to give strict rules for when you have decomposed to enough detail. As a guideline, if you&#xD;
    can build from the specification, then you have decomposed enough. Of course, different stakeholders will need to stop&#xD;
    at different levels. In the case of the navigation system, the user is interested in capability, performance,&#xD;
    usability, etc. The architect may decompose to blocks, which separate domain experts would then decompose further.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Activity at Each Level&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    From the preceding explanation, we can see that the development team at each level must undertake the following tasks:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Identify and agree the requirements from the level above that are the responsibility of that development team to&#xD;
        satisfy. These are referred to as the input requirements for that development team.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perform design activities and verify that the design satisfies the input requirements. The location of design&#xD;
        within a scheme whose primary focus is successive refinement of requirements should not be taken to mean that&#xD;
        design is unimportant, it is, of course, vital.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Based on the design and the input requirements create requirements for the level below and validate that each&#xD;
        requirement is well formed, that the set is complete and understandable, and that each requirement is traced back&#xD;
        to one or more of the input requirements. These requirements are then flowed down and allocated to one or more&#xD;
        lower level teams.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When the lower level teams have completed their work, it is necessary to check that the delivered items conform to&#xD;
        the requirements that were allocated to them.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Assemble the delivered components to produce the overall delivered item from that level and, if necessary, assemble&#xD;
        and verify intermediate integration products.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Verify that the overall product item for delivery from this level to the higher level conforms to the input&#xD;
        requirements that were the starting point for its design.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    Based on these six items we can define a set of six activities that each level of the development process must&#xD;
    undertake as shown in Figure 9.&lt;img alt=&quot;Internal Development Activities&quot;&#xD;
    src=&quot;resources/internal_dev_activities_fig9.jpg&quot; width=&quot;515&quot; height=&quot;320&quot; />&#xD;
&lt;/p>&lt;br />&#xD;
&lt;p>&#xD;
    Arrows show dependencies between the activities. These do not mean that there is strict sequence between the&#xD;
    activities. All the activities can operate concurrently to some extent. However, the dependencies control whether each&#xD;
    activity can be completed. Thus, it is impossible to complete the verification of the design before the input&#xD;
    requirements are agreed (since verifying the design necessitates proving that all the input requirements have been&#xD;
    satisfied by the design). Similarly, the output requirements cannot be validated until the input requirements and the&#xD;
    design are complete. The three product verification activities all depend upon the respective sets of requirements&#xD;
    against which verification is to be made. These verification activities can only be complete when the (sub-) products&#xD;
    they are intended to verify have been produced. However, this does not prevent the proper planning of the intended&#xD;
    verification activities.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    We emphasize that the information needed for each process must be available before the process is complete, but it is&#xD;
    not necessary to wait for an activity to start before the information is created. In particular:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Verification planning is best done in parallel with creating requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A pre-existing design will often be used rather than creating a new one.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    For the first example, the activity description for “Verify Own Product” (Section 10) includes the production of a&#xD;
    verification plan. If Figure 9 were interpreted as a flowchart, then this would imply that the Verification Plan would&#xD;
    only be produced at the time that the product is to be verified. However, carrying out this task in parallel with&#xD;
    writing the requirements has many benefits, for example, the act of creating the plan means that the requirements are&#xD;
    critically inspected and the availability of the plan allows test facilities to be prepared.&lt;br />&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Consolidating the Detail&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The process is essentially the same at each level, the output of one level becomes the input to the next. Also, as we&#xD;
    progress down the levels, the scope of each specification narrows as the levels become further decomposed, while the&#xD;
    detail in each specification increases.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Now we can combine Figure 7 and Figure 9 and produce Figure 10.&#xD;
&lt;/p>&lt;img alt=&quot;Multi-level development showing internal process activities&quot;&#xD;
src=&quot;resources/multi_level_dev_show_internal_activities_fig10.jpg&quot; width=&quot;554&quot; height=&quot;496&quot; />&lt;br />&#xD;
&lt;p>&#xD;
    Note that at the top level the process the process Validate Final Product replaces 1. This is because, at that level,&#xD;
    the product is being validated against the stakeholder’s requirements (User Needs). In addition, there is no “Verify&#xD;
    Integration Products” at the top level as this verification has been done at the lower level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    At the very bottom of the process, the result of the generic activity is the delivery of design to manufacturing,&#xD;
    rather than the creation of further requirements. Figure 11 shows this, we have left it off the overall diagrams for&#xD;
    clarity. At this level, the components produced would need to be linked into the manufacturing and supply chain.&#xD;
&lt;/p>&lt;img alt=&quot;Bottom Level Development Activities&quot; src=&quot;resources/bottom_level_dev_activities_fig11.jpg&quot; width=&quot;374&quot;&#xD;
height=&quot;166&quot; />&lt;br />&#xD;
&lt;p>&#xD;
    In practice, the requirements coming from the level above are not sufficient to ensure that a development team produce&#xD;
    a satisfactory result. Two further sources of requirements are vital to success as shown in Figure 12:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Requirements from the specialist domains, for example:&lt;br />&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                Certification&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Safety&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Supportability&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Producibility&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Design Guidelines and directives&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Requirements from other development teams (through interface documents).&#xD;
    &lt;/li>&#xD;
&lt;/ul>&lt;img alt=&quot;RDE Process showing transverse requirement sources&quot;&#xD;
src=&quot;resources/rde_process_show_transverse_req_fig12.jpg&quot; width=&quot;600&quot; height=&quot;481&quot; />&lt;br />&#xD;
&lt;p>&#xD;
    Requirements from specialist domains must be addressed at all levels and there is an overall responsibility on each&#xD;
    specialist domain to ensure that all requirements and regulations are satisfactorily addressed by the sum of specific&#xD;
    requirements included by each development team at each level.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The transverse requirements that come from one development team to others must be treated as a source of requirements&#xD;
    in the Agree Input Requirements activity. It is also necessary in the Generate and Validate Output Requirements&#xD;
    activity to check whether there is a need to generate transverse requirements and send them to one or more other teams.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Requirements from one development team that must be addressed by one or more other teams must be properly formulated&#xD;
    and agreed between the relevant teams. In addition to requirements that arise because of two systems interacting&#xD;
    directly, there are also indirectly imposed requirements. As an example, a Risk associated with a requirement for one&#xD;
    system may lead to the creation of another requirement to mitigate the risk, which could then be allocated to another&#xD;
    system. For example, in the field of medical devices it is assumed that software will fail, so safety-critical features&#xD;
    have to have either non-software implementation or backup.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This section has explained that the same development process applies at each level of decomposition. Once the&#xD;
    high-level decomposition has been made, there will be several instances of the development process at each level.&#xD;
&lt;/p>&lt;img alt=&quot;V-Model for Process&quot; src=&quot;resources/vmodel_process_fig13.jpg&quot; width=&quot;600&quot; height=&quot;433&quot; />&lt;br />&#xD;
&lt;p>&#xD;
    Figure 14 shows the V-model appropriate to the information architecture shown in Reference 1. The essential differences&#xD;
    are the presence of the ASR and the removal of Packages.&#xD;
&lt;/p>&lt;img alt=&quot;V-Model for Medium-Term Process&quot; src=&quot;resources/vmodel_medium_process_fig14.jpg&quot; width=&quot;600&quot;&#xD;
height=&quot;458&quot; />&lt;br />&#xD;
&lt;h3>&#xD;
    Tailoring the Process&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    TBD.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Outline of the Generic Process&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    In the previous section, we introduced the RDE process and showed that the same process could be applied at each level.&#xD;
    We refer to this process as the RDE Generic Process because it can be instantiated at each level and must be&#xD;
    instantiated many times at the lower levels. In this section, we describe the six activities of the RDE Generic Process&#xD;
    in more detail.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 15 is an expansion of Figure 9 and shows the RDE Generic Process in outline. Note that we have added four more&#xD;
    tasks to those in Figure 9 – these will be described below. Section 14.1 describes each activity of the overall process&#xD;
    in much more detail. The activities shown and their interdependence are identical to those shown in earlier figures. In&#xD;
    Figure 15 the context of the RDE&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Generic Process is expressed in general terms rather than the specific instances used in earlier diagrams. Each&#xD;
    activity has been allocated a number to ease cross-referencing of the details. In the following sections, each activity&#xD;
    is described in more detail and is decomposed into a set of Tasks.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;RDE Generic Process&quot; src=&quot;resources/rde_generic_process_fig15.jpg&quot; width=&quot;549&quot; height=&quot;387&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that a team working at a specific level of development executes each instance of the RDE Generic Process. The&#xD;
    horizontal dotted lines in Figure 15 indicate these levels. In the descriptions, the phrase “for this level” is used.&#xD;
    This should be interpreted to mean “for this team at this level”. Thus, for example, in an aircraft manufacturer, at&#xD;
    level -2 there could be three instances of the generic process: one each for Wing, Systems, and Fuselage and Empennage&#xD;
    and each team will have its own ‘Input Requirements for this level’, ‘Models for this level’ etc. The vertical dotted&#xD;
    line in Figure 15 indicates the boundary between a development team and its sources of “transverse” requirements. Some&#xD;
    of these come from specialist domains and some from other development teams. Note also that each development team can&#xD;
    potentially generate requirements for other teams, as indicated by the arrow from activity 3 to the box containing&#xD;
    ‘Requirements for other teams’.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Sections 5 to 10 introduce more details of the six activities of the RDE Generic Process. Sections 11 to 14 introduce&#xD;
    additional activities that complete the overall RDE process.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Mapping the Information Architecture to the RDE Process&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Before presenting a detailed description of the tasks in each activity, it is useful to prepare the ground with a&#xD;
    fuller look at the data context. The main activities of the RDE generic process were presented initially in Figure 15.&#xD;
    For simplicity, and to ease explanation, the internal data items were omitted. These have been added to the version of&#xD;
    the diagram shown in Figure 16 and are represented by square cornered rectangles. Nested rectangles group information&#xD;
    that serves a similar purpose. To make it clearer the composite data items have also been coloured pale blue (or pale&#xD;
    grey when printed). Interdependence between activities is indicated by showing the artefacts that one activity produces&#xD;
    and another uses.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;More details of the RDE generic process&quot; src=&quot;resources/more_rde_generic_process_fig16.jpg&quot; width=&quot;600&quot;&#xD;
    height=&quot;490&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 15 also clearly demarks the responsibility of each level and it introduces the tasks from Activity 7 that are a&#xD;
    crucial part in the agreement between levels, the agreement with the specialist domains and agreements between&#xD;
    development teams. Working from the data boxes in this diagram it is possible to derive a data model as shown in Figure&#xD;
    17.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;Information Model for RDE Generic Process&quot; src=&quot;resources/info_model_rde_generic_process_fig17.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;452&quot; />&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The large dotted rectangle indicates the data that will be directly addressed by each development team at each level.&#xD;
    There are potentially three components in the input requirements as suggested by the three tasks of Activity 1 and&#xD;
    there are potentially two components of the output requirements generated respectively by tasks 3.1 and 3.2. Figure 17&#xD;
    indicates that specialist domain requirements are derived from the relevant documents and standards from those domains.&#xD;
    It also shows that requirements are passed from one development area to another, through the inter-area requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In the process of transforming the input requirements to the output requirements, it is necessary to generate a design.&#xD;
    As the elements of the design will represent elements in the partitioning of the system, these elements should also be&#xD;
    present in the Product Breakdown Structure (PBS) of the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Figure 17 also indicates that the process creates validation information for the output requirements and verification&#xD;
    information for the design, any intermediate integration products and the final delivered product from this team.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that the model shown in Figure 17 is a logical model and it is not the intention to copy requirements from the&#xD;
    output requirements of one team to the input requirements of another. It indicates only that each team must be aware of&#xD;
    the complete set of requirements to which it must respond (the input requirements) and that these come from three&#xD;
    different places.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The lines connecting the rectangles in Figure 17 represent relationships between the linked items. Again, remember that&#xD;
    these are logical relationships, the physical relationship may be represented differently. Each relationship is&#xD;
    labelled to identify its nature. The direction of the arrows on indicates the way in which the name should be read. In&#xD;
    the Figure, Design Materials are regarded as Models. Thus the following relationships are shown:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Design Material for this level {completely} satisfies the Input Requirements for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design Verification data for this level {completely} verifies the Design Material for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Output Requirements from this level {completely} satisfies Input Requirements for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        {Some} Output Requirements from this level are derived from Design Material for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Requirements Validation data for this level {completely} validates the Output Requirements from this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Product Verification data for this level {completely} verifies the Input Requirements for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Integration Verification data for this level verifies {some aspects of } the Design Material for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Integration Verification data for this level verifies {some of the} Input Requirements for this level.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        {All} Requirements from specialist domains may be derived from Specialist Domain Requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        {All} Requirements from other teams come from Inter Area Requirements.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        {All} Requirements for other teams go to Inter Area Requirements.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The italicised words correspond to the relationship names used in Figure 17 and the words in curly brackets qualify the&#xD;
    extent of the relationship.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note that the Requirements for other teams generated as part of the Output Requirements by one team become Requirements&#xD;
    from other teams when they have been agreed as part of the Input Requirements for the team that will satisfy&#xD;
    them.&lt;br />&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
