https://bugs.eclipse.org/bugs/show_bug.cgi?id=240040
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><p> This template describes how the design can be organized to be understood from 
- multiple perspectives. It also provides suggestions for how patterns and descriptions 
- of small, reusable interactions can be used to minimize redundancy. </p>
-<p> It is important not to think of design as &quot;a document." Design information 
- that is worth keeping for some duration must have a long-lived form. But that 
- form might be as a repository in a visual modeling tool, or as subdirectories 
- of whiteboard diagrams captured with a digital camera, or as an actual document 
- that provides structure for images taken from a myriad of sources. </p>
-<p> This template describes the information that should be conveyed. Typically, 
- it works best to convey the information graphically (either with UML or another 
- unambiguous notation), or at least in words, at an abstract level. You can enhance 
- this with code examples, but best not to render the design solely at the code 
- level. </p>
+ 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><p>
+ This template describes how the design can be organized to be understood from multiple perspectives. It also provides
+ suggestions for how patterns and descriptions of small, reusable interactions can be used to minimize redundancy.
+</p>
+<p>
+ It is important not to think of design as "a document." Design information that is worth keeping for some duration must
+ have a long-lived form. But that form might be as a repository in a visual modeling tool, or as subdirectories of
+ whiteboard diagrams captured with a digital camera, or as an actual document that provides structure for images taken
+ from a myriad of sources.
+</p>
+<p>
+ Designs are often organized into requirement realizations. A requirements realization is a part of the design that
+ shows how one or more requirements is implemented.
+</p>
+<p>
+ This template describes the information that should be conveyed. Typically, it works best to convey the information
+ graphically (either with UML or another unambiguous notation), or at least in words, at an abstract level. You can
+ enhance this with code examples, but best not to render the design solely at the code level.
+</p>
<p>
The structure of the design is suggested in this template.
</p>
-<h1> Design structure </h1>
-<p style="COLOR: #0000ff"> [Describe the design from the highest level. This 
- is commonly done with a diagram that shows a layered architecture.] </p>
-<h1> Subsystems </h1>
-<h2> [Sub-system1] </h2>
-<p style="COLOR: #0000ff"> [Describe the design of a portion of the system (a 
- package or component, for instance). The design should capture both static and 
- dynamic perspectives. </p>
-<p style="COLOR: #0000ff"> When capturing dynamic descriptions of behavior, look 
- for reusable chunks of behavior that you can reference to simplify the design 
- of the use-case realizations. </p>
-<p style="COLOR: #0000ff"> You can break this section down into lower-level subsections 
- to describe lower-level, encapsulated subsystems.] </p>
-<h1> Patterns </h1>
-<h2> [Pattern1] </h2>
-<h3> Overview </h3>
-<p style="COLOR: #0000ff"> [Provide an overview of the pattern in words in some 
- consistent form. The overview of a pattern can include the intent, motivation, 
- and applicability.] </p>
-<h3> Structure </h3>
-<p style="COLOR: #0000ff"> [Describe the pattern from a static perspective. Include 
- all of the participants and how they relate to one another, and call out the&nbsp;relevant 
- data and behavior.] </p>
-<h3> Behavior </h3>
-<p style="COLOR: #0000ff"> [Describe the pattern from a dynamic perspective. Walk 
- the reader through how the participants collaborate to support various scenarios.] 
+<h1>
+ Design structure
+</h1>
+<p style="COLOR: #0000ff">
+ [Describe the design from the highest level. This is commonly done with a diagram that shows a layered architecture.]
</p>
-Example 
-<p style="COLOR: #0000ff"> [Often, you can convey the nature of the pattern better 
- with an additional concrete example.] </p>
-<h1> Use-case realizations </h1>
-<h2> [Realization1] </h2>
-<h3> View of participants </h3>
-<p style="COLOR: #0000ff"> [Describe the participating design elements from a 
- static perspective, giving details such as behavior, relationships, and attributes 
- relevant to this use-case realization.] </p>
-<h3> Basic scenario </h3>
-<p style="COLOR: #0000ff"> [For the main flow, describe how instances of the design 
- elements collaborate to realize the use case. When using UML, this can be done 
- with collaboration diagrams (sequence or communication).] </p>
-<h3> Additional scenarios </h3>
-<p style="COLOR: #0000ff"> [For other scenarios that must be described to convey 
- an appropriate amount of information about how the use-case behavior will be 
- realized, describe how instances of the design elements collaborate to realize 
- the use case. When using UML, you can do this with collaboration diagrams (sequence 
- or communication).] </p></mainDescription>
+<h1>
+ Subsystems
+</h1>
+<h2>
+ [Sub-system1]
+</h2>
+<p style="COLOR: #0000ff">
+ [Describe the design of a portion of the system (a package or component, for instance). The design should capture both
+ static and dynamic perspectives.
+</p>
+<p style="COLOR: #0000ff">
+ When capturing dynamic descriptions of behavior, look for reusable chunks of behavior that you can reference to
+ simplify the design of the use-case realizations.
+</p>
+<p style="COLOR: #0000ff">
+ You can break this section down into lower-level subsections to describe lower-level, encapsulated subsystems.]
+</p>
+<h1>
+ Patterns
+</h1>
+<h2>
+ [Pattern1]
+</h2>
+<h3>
+ Overview
+</h3>
+<p style="COLOR: #0000ff">
+ [Provide an overview of the pattern in words in some consistent form. The overview of a pattern can include the intent,
+ motivation, and applicability.]
+</p>
+<h3>
+ Structure
+</h3>
+<p style="COLOR: #0000ff">
+ [Describe the pattern from a static perspective. Include all of the participants and how they relate to one another,
+ and call out the&nbsp;relevant data and behavior.]
+</p>
+<h3>
+ Behavior
+</h3>
+<p style="COLOR: #0000ff">
+ [Describe the pattern from a dynamic perspective. Walk the reader through how the participants collaborate to support
+ various scenarios.]
+</p>Example 
+<p style="COLOR: #0000ff">
+ [Often, you can convey the nature of the pattern better with an additional concrete example.]
+</p>
+<h1>
+ Requirement&nbsp;realizations
+</h1>
+<h2>
+ [Realization1]
+</h2>
+<h3>
+ View of participants
+</h3>
+<p style="COLOR: #0000ff">
+ [Describe the participating design elements from a static perspective, giving details such as behavior, relationships,
+ and attributes relevant to this use-case realization.]
+</p>
+<h3>
+ Basic scenario
+</h3>
+<p style="COLOR: #0000ff">
+ [For the main flow, describe how instances of the design elements collaborate to realize the use case. When using UML,
+ this can be done with collaboration diagrams (sequence or communication).]
+</p>
+<h3>
+ Additional scenarios
+</h3>
+<p style="COLOR: #0000ff">
+ [For other scenarios that must be described to convey an appropriate amount of information about how the use-case
+ behavior will be realized, describe how instances of the design elements collaborate to realize the use case. When
+ using UML, you can do this with collaboration diagrams (sequence or communication).]
+</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
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"
