| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-i-m_UCiyvP_of5odu9C2Bw" |
| name="detailing_work_products,_F0wCwJklEd2Al9G_gP7uDg" guid="-i-m_UCiyvP_of5odu9C2Bw" |
| changeDate="2008-10-13T06:05:13.890-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| This guideline provides guidelines for detailing <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
 |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s (<a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
 |
| guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
 |
| guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>s and <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
 |
| guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s). For general detailing guidelines that are common to all method
 |
| elements, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/detailing_method_elements_general_B2500E20.html"
 |
| guid="_jLqqIOFIEdumFeaOJSgmnQ">Guideline: Detailing Method Elements (General)</a>.
 |
| </p>
 |
| <p dir="ltr">
 |
| <font size="4">Keep in mind the following guidelines when completing each of the&nbsp;</font>work product-specific text
 |
| fields (for guidelines regarding the common fields, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/detailing_common_method_element_fields_940D3CE0.html"
 |
| guid="_zVLrkJZwEd2ireJkqESkdQ">Guideline: Detailing Common Method Element Fields</a>):&nbsp;&nbsp;&nbsp;
 |
| </p>
 |
| <ul class="noindent">
 |
| <li>
 |
| <strong>Purpose</strong>: The Purpose field describes the reason for the method element.&nbsp;For example, for a
 |
| Work Product:&nbsp;&nbsp; 
 |
| <ul>
 |
| <li>
 |
| Why is the work product produced?&nbsp;
 |
| </li>
 |
| <li>
 |
| How will it be used?<em>&nbsp;</em>&nbsp;
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <p>
 |
| Do not repeat text already stated in other fields, such as the brief description or the main description.
 |
| </p>
 |
| </blockquote>
 |
| <ul class="noindent">
 |
| <li>
 |
| <p style="MARGIN-RIGHT: 0px">
 |
| <strong>Main description</strong>. This field is optional for work products.&nbsp;It contains a detailed
 |
| description of the work product if the Brief description&nbsp;and Purpose is insufficient.&nbsp;If
 |
| the&nbsp;work product&nbsp;has significant state, include&nbsp;a state machine (i.e., a description of the
 |
| states and their transitions) in the artifact's Main description.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p style="MARGIN-RIGHT: 0px">
 |
| <strong>Key Considerations</strong>: This field&nbsp;is optional.&nbsp; It contains useful material that does
 |
| not easily fit into any of the other sections, such as advice and guidance of a critical nature, as well as
 |
| warnings, cautions, pitfalls and dangers.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p style="MARGIN-RIGHT: 0px">
 |
| <strong>Impact of not having</strong>: List and briefly describe the consequences of not&nbsp;producing this
 |
| work product. Consider this from the delivery practitioners’ point of view. If the work product was not
 |
| available, what would be the impact to the execution of the project? What information would the practitioners
 |
| not have that they need? Write a short description of the impact.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <strong>Reason for not needing</strong>: List the conditions when the work product might not be needed, and why. Is
 |
| the information available somewhere else? Is it of secondary importance to other work products? Is the project
 |
| small enough that it is not relevant? Write a short description of the normal reasons why the work product may not
 |
| be needed.<br />
 |
| </li>
 |
| <li>
 |
| <strong>Guidance</strong>: Guidance can be associated to a task to provide further details about the work product.
 |
| The type of guidance that is usually associated with a work product includes checklists, examples and
 |
| templates.&nbsp;For information on these associations, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_method_content_elements_21A491E3.html"
 |
| guid="_XQqJkCAmEdy1y5bWsXfCCg">Guideline: Defining Method Content Elements</a>.&nbsp;<strong>&nbsp;</strong>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| For work-product-type-specific guidelines, see the following sections.
 |
| </p>
 |
| <h3>
 |
| Detailing artifacts
 |
| </h3>
 |
| <p>
 |
| The following fields are artifact-specific:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Brief outline:</strong> This field is optional.&nbsp;It describes the major sections or information topics
 |
| that are covered by the work product.&nbsp;This information&nbsp;should be generic,&nbsp;in other words,&nbsp;not
 |
| specific to any particular format or template.<br />
 |
| &nbsp;&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Selected representation</strong>: This field is optional.&nbsp;It is used when a particular representation
 |
| is decided on. For example, a particular company may mandate the use of a particular tool or format.&nbsp;<br />
 |
| </li>
 |
| <li>
 |
| <strong>Notation</strong>: This field is optional.&nbsp;It describes any notations used by the work product. Either
 |
| <strong>Brief outline</strong> or <strong>Notation</strong> should be provided, or both [*** I got this last
 |
| sentence from the template, but I am not sure what&nbsp;it means.&nbsp; Should it be "not both"? ***]&nbsp; This
 |
| field may also contain explanations of any diagrammatic or textual notations. Include notations that are important
 |
| or special terms, labels, headers, acronyms, etc. that are used in the artifact. Any items relating to how this is
 |
| implemented in a specific template should be included in the description for that template, not here. Note this
 |
| section should be general enough to apply regardless of the actual representation option selected, unless there are
 |
| multiple notations such as IDEF1X or UML, in which case an overview of each can be included (preferably as
 |
| contributions&nbsp;from the related techniques).<br />
 |
| &nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Representation options</strong>: This field is optional.&nbsp;Describe alternative representations for this
 |
| work product.<br />
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Detailing deliverables
 |
| </h4>
 |
| <p>
 |
| The following fields are deliverable-specific:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>External Description</strong>: This field is intended to be a description of the deliverable that the
 |
| client will read. It is usually copied into a Statement of Work or other agreement, or into sales and marketing
 |
| material with a client. The content of this field may require legal approval of some sort. Seek guidance from the
 |
| method authoring consultant. Keep to a description (what the deliverable is) rather than its use in an engagement.
 |
| Build on the purpose but differentiate between the what and the why of the deliverable. The description is about
 |
| what the deliverable is. The description must be understood by potential clients.
 |
| </li>
 |
| <li>
 |
| <strong>Packaging Guidance</strong>: This field is intended to give an overview of the notation for the
 |
| deliverable. For a root deliverable from which other will be derived, the packaging guidance should indicate the
 |
| preferred notations. Note the plural here in that there may be several notations. The packaging guidance should
 |
| provide a synopsis of them. For derived deliverables, variability can add details to notation and they can become
 |
| more focused. The packaging guidance must account for the availability (or not) of a complete set of input work
 |
| products. Depending on the configuration tailoring on a particular engagement, all input work product may not be
 |
| available. Be aware of the purpose and governance level of the deliverable being defined when outlining notation.
 |
| [*** Describing how the inputs are assembled into a deliverable including what particular sections may be relevant
 |
| and what the expected state of those inputs should be along. Explicit guidelines on the formatting may be better
 |
| included via a customization for that project of standard guidelines for a project that applies to all deliverables
 |
| as defined in the agreement. ***]
 |
| </li>
 |
| <li>
 |
| <strong>Deliverable Parts:</strong>&nbsp;Identify the work products that will be used to construct the deliverable.
 |
| </li>
 |
| </ul><br />
 |
| <h3>
 |
| Detailing outcomes
 |
| </h3>
 |
| <p>
 |
| The following fields are outcome-specific:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| None at this time.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
