diff --git a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/templates/design.xmi b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
index 827c842..85fae34 100644
--- a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
+++ b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/guidances/templates/design.xmi
@@ -1,69 +1,110 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <org.eclipse.epf.uma:GuidanceDescription xmi:version="2.0"
-    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore"
-    xmlns:epf="http://www.eclipse.org/epf"
-    epf:version="1.2.0" xmi:id="-giTBOvJczHXweRzBQEo-7A"
-    name="new_template,_EOPcMAMUEdylNddAObilIA" guid="-giTBOvJczHXweRzBQEo-7A" changeDate="2007-06-22T10:44:44.614-0700">
-  <mainDescription>&lt;p> This template describes how the design can be organized to be understood from &#xD;
-  multiple perspectives. It also provides suggestions for how patterns and descriptions &#xD;
-  of small, reusable interactions can be used to minimize redundancy. &lt;/p>&#xD;
-&lt;p> It is important not to think of design as &amp;quot;a document.&quot; Design information &#xD;
-  that is worth keeping for some duration must have a long-lived form. But that &#xD;
-  form might be as a repository in a visual modeling tool, or as subdirectories &#xD;
-  of whiteboard diagrams captured with a digital camera, or as an actual document &#xD;
-  that provides structure for images taken from a myriad of sources. &lt;/p>&#xD;
-&lt;p> This template describes the information that should be conveyed. Typically, &#xD;
-  it works best to convey the information graphically (either with UML or another &#xD;
-  unambiguous notation), or at least in words, at an abstract level. You can enhance &#xD;
-  this with code examples, but best not to render the design solely at the code &#xD;
-  level. &lt;/p>&#xD;
+    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
+    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
+    epf:version="1.5.0" xmi:id="-giTBOvJczHXweRzBQEo-7A"
+    name="new_template,_EOPcMAMUEdylNddAObilIA" guid="-giTBOvJczHXweRzBQEo-7A" changeDate="2008-08-12T18:15:18.342-0700">
+  <mainDescription>&lt;p>&#xD;
+    This template describes how the design can be organized to be understood from multiple perspectives. It also provides&#xD;
+    suggestions for how patterns and descriptions of small, reusable interactions can be used to minimize redundancy.&#xD;
+&lt;/p>&#xD;
+&lt;p>&#xD;
+    It is important not to think of design as &quot;a document.&quot; Design information that is worth keeping for some duration must&#xD;
+    have a long-lived form. But that form might be as a repository in a visual modeling tool, or as subdirectories of&#xD;
+    whiteboard diagrams captured with a digital camera, or as an actual document that provides structure for images taken&#xD;
+    from a myriad of sources.&#xD;
+&lt;/p>&#xD;
+&lt;p>&#xD;
+    Designs are often organized into requirement realizations. A requirements realization is a part of the design that&#xD;
+    shows how one or more requirements is implemented.&#xD;
+&lt;/p>&#xD;
+&lt;p>&#xD;
+    This template describes the information that should be conveyed. Typically, it works best to convey the information&#xD;
+    graphically (either with UML or another unambiguous notation), or at least in words, at an abstract level. You can&#xD;
+    enhance this with code examples, but best not to render the design solely at the code level.&#xD;
+&lt;/p>&#xD;
 &lt;p>&#xD;
     The structure of the design is suggested in this template.&#xD;
 &lt;/p>&#xD;
-&lt;h1> Design structure &lt;/h1>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Describe the design from the highest level. This &#xD;
-  is commonly done with a diagram that shows a layered architecture.] &lt;/p>&#xD;
-&lt;h1> Subsystems &lt;/h1>&#xD;
-&lt;h2> [Sub-system1] &lt;/h2>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Describe the design of a portion of the system (a &#xD;
-  package or component, for instance). The design should capture both static and &#xD;
-  dynamic perspectives. &lt;/p>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> When capturing dynamic descriptions of behavior, look &#xD;
-  for reusable chunks of behavior that you can reference to simplify the design &#xD;
-  of the use-case realizations. &lt;/p>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> You can break this section down into lower-level subsections &#xD;
-  to describe lower-level, encapsulated subsystems.] &lt;/p>&#xD;
-&lt;h1> Patterns &lt;/h1>&#xD;
-&lt;h2> [Pattern1] &lt;/h2>&#xD;
-&lt;h3> Overview &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Provide an overview of the pattern in words in some &#xD;
-  consistent form. The overview of a pattern can include the intent, motivation, &#xD;
-  and applicability.] &lt;/p>&#xD;
-&lt;h3> Structure &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Describe the pattern from a static perspective. Include &#xD;
-  all of the participants and how they relate to one another, and call out the&amp;nbsp;relevant &#xD;
-  data and behavior.] &lt;/p>&#xD;
-&lt;h3> Behavior &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Describe the pattern from a dynamic perspective. Walk &#xD;
-  the reader through how the participants collaborate to support various scenarios.] &#xD;
+&lt;h1>&#xD;
+    Design structure&#xD;
+&lt;/h1>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Describe the design from the highest level. This is commonly done with a diagram that shows a layered architecture.]&#xD;
 &lt;/p>&#xD;
-Example &#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Often, you can convey the nature of the pattern better &#xD;
-  with an additional concrete example.] &lt;/p>&#xD;
-&lt;h1> Use-case realizations &lt;/h1>&#xD;
-&lt;h2> [Realization1] &lt;/h2>&#xD;
-&lt;h3> View of participants &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [Describe the participating design elements from a &#xD;
-  static perspective, giving details such as behavior, relationships, and attributes &#xD;
-  relevant to this use-case realization.] &lt;/p>&#xD;
-&lt;h3> Basic scenario &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [For the main flow, describe how instances of the design &#xD;
-  elements collaborate to realize the use case. When using UML, this can be done &#xD;
-  with collaboration diagrams (sequence or communication).] &lt;/p>&#xD;
-&lt;h3> Additional scenarios &lt;/h3>&#xD;
-&lt;p style=&quot;COLOR: #0000ff&quot;> [For other scenarios that must be described to convey &#xD;
-  an appropriate amount of information about how the use-case behavior will be &#xD;
-  realized, describe how instances of the design elements collaborate to realize &#xD;
-  the use case. When using UML, you can do this with collaboration diagrams (sequence &#xD;
-  or communication).] &lt;/p></mainDescription>
+&lt;h1>&#xD;
+    Subsystems&#xD;
+&lt;/h1>&#xD;
+&lt;h2>&#xD;
+    [Sub-system1]&#xD;
+&lt;/h2>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Describe the design of a portion of the system (a package or component, for instance). The design should capture both&#xD;
+    static and dynamic perspectives.&#xD;
+&lt;/p>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    When capturing dynamic descriptions of behavior, look for reusable chunks of behavior that you can reference to&#xD;
+    simplify the design of the use-case realizations.&#xD;
+&lt;/p>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    You can break this section down into lower-level subsections to describe lower-level, encapsulated subsystems.]&#xD;
+&lt;/p>&#xD;
+&lt;h1>&#xD;
+    Patterns&#xD;
+&lt;/h1>&#xD;
+&lt;h2>&#xD;
+    [Pattern1]&#xD;
+&lt;/h2>&#xD;
+&lt;h3>&#xD;
+    Overview&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Provide an overview of the pattern in words in some consistent form. The overview of a pattern can include the intent,&#xD;
+    motivation, and applicability.]&#xD;
+&lt;/p>&#xD;
+&lt;h3>&#xD;
+    Structure&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Describe the pattern from a static perspective. Include all of the participants and how they relate to one another,&#xD;
+    and call out the&amp;nbsp;relevant data and behavior.]&#xD;
+&lt;/p>&#xD;
+&lt;h3>&#xD;
+    Behavior&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Describe the pattern from a dynamic perspective. Walk the reader through how the participants collaborate to support&#xD;
+    various scenarios.]&#xD;
+&lt;/p>Example &#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Often, you can convey the nature of the pattern better with an additional concrete example.]&#xD;
+&lt;/p>&#xD;
+&lt;h1>&#xD;
+    Requirement&amp;nbsp;realizations&#xD;
+&lt;/h1>&#xD;
+&lt;h2>&#xD;
+    [Realization1]&#xD;
+&lt;/h2>&#xD;
+&lt;h3>&#xD;
+    View of participants&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [Describe the participating design elements from a static perspective, giving details such as behavior, relationships,&#xD;
+    and attributes relevant to this use-case realization.]&#xD;
+&lt;/p>&#xD;
+&lt;h3>&#xD;
+    Basic scenario&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [For the main flow, describe how instances of the design elements collaborate to realize the use case. When using UML,&#xD;
+    this can be done with collaboration diagrams (sequence or communication).]&#xD;
+&lt;/p>&#xD;
+&lt;h3>&#xD;
+    Additional scenarios&#xD;
+&lt;/h3>&#xD;
+&lt;p style=&quot;COLOR: #0000ff&quot;>&#xD;
+    [For other scenarios that must be described to convey an appropriate amount of information about how the use-case&#xD;
+    behavior will be realized, describe how instances of the design elements collaborate to realize the use case. When&#xD;
+    using UML, you can do this with collaboration diagrams (sequence or communication).]&#xD;
+&lt;/p></mainDescription>
 </org.eclipse.epf.uma:GuidanceDescription>
diff --git a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/plugin.xmi b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/plugin.xmi
index 421411a..950a443 100644
--- a/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/plugin.xmi
+++ b/libraries/EPF_Practices_Library/practice.tech.evolutionary_design.base/plugin.xmi
@@ -126,7 +126,7 @@
           </contentElements>
           <contentElements xsi:type="org.eclipse.epf.uma:Template" xmi:id="_EOPcMAMUEdylNddAObilIA"
               name="design" guid="_EOPcMAMUEdylNddAObilIA" presentationName="Design"
-              briefDescription="This is the informal template suggested for representing design.">
+              briefDescription="This is the informal template suggested for representing design.A requirements realization is a part of the design that shows how one or more&#xD;&#xA;requirements is implemented.">
             <presentation xmi:id="-giTBOvJczHXweRzBQEo-7A" href="uma://-giTBOvJczHXweRzBQEo-7A#-giTBOvJczHXweRzBQEo-7A"/>
           </contentElements>
           <contentElements xsi:type="org.eclipse.epf.uma:Checklist" xmi:id="_0XSzsMlgEdmt3adZL5Dmdw"