<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_YIYIYMM1EdmSIPI87WLu3g" name="design,_0XSzsMlgEdmt3adZL5Dmdw" guid="_YIYIYMM1EdmSIPI87WLu3g" changeDate="2006-09-15T15:28:43.942-0400" version="1.0.0">
  <mainDescription>&lt;p&gt;
    The items in this checklist represent good practices for creating and communicating a robust design. Try to address
    every item to the greatest extent possible to create the best design. It may not be possible to address every item, and
    some items may only be able to be addressed to a limited extent. In these cases, be sure that there are good reasons
    for only partially addressing an item, or not addressing an item at all.
&lt;/p&gt;
&lt;p&gt;
    Design can be performed every day. Use this checklist regularly to assure the design is robust, consistent, and
    understandable. Make the design good enough for the specific goals being addressed by using this checklist to identify
    areas that have been skipped, ignored, or not sufficiently addressed.
&lt;/p&gt;</mainDescription>
  <sections xmi:id="_cKSvsD6SEduAL-bCqar_dg" name="General" guid="_cKSvsD6SEduAL-bCqar_dg">
    <sectionDescription>&lt;p&gt;
    Do separate design elements have low coupling? Does each design element have high internal cohesion?
&lt;/p&gt;
&lt;p&gt;
    Does the design reflect the architectural objectives of the system?
&lt;/p&gt;
&lt;p&gt;
    Can the system be implemented from the information in the design? Has sufficient detail been included?
&lt;/p&gt;
&lt;p&gt;
    Is the design consistent? Does any part of the design contradict another part of it in such a way that puts the project
    at risk?
&lt;/p&gt;
&lt;p&gt;
    Is the design able to accommodate future changes?
&lt;/p&gt;
&lt;p&gt;
    Is the design appropriate to the experience level of other team members and stakeholders, neither too simple nor too
    advanced?
&lt;/p&gt;
&lt;p&gt;
    Is the design written in such a way, and is it structured well enough, so it can be maintained easily?
&lt;/p&gt;
&lt;p&gt;
    Does the design constrain the implementation only as much as is necessary?
&lt;/p&gt;
&lt;p&gt;
    Does the design describe all the behavior of the system for the requirements that are currently being addressed?
&lt;/p&gt;
&lt;p&gt;
    Can all parts of the design be traced back to the requirements? Can the requirements (for the current iteration) be
    traced to design elements?
&lt;/p&gt;
&lt;p&gt;
    Is there an unambiguous place or places&amp;nbsp;in the design where each behavior exists?
&lt;/p&gt;
&lt;p&gt;
    Are the use case flows that are currently being addressed described in the design?
&lt;/p&gt;
&lt;p&gt;
    Are&amp;nbsp;complex flows outside the Basic Flow&amp;nbsp;addressed, including exceptional cases?
&lt;/p&gt;
&lt;p&gt;
    Has the behavior described in the requirements that are currently being addressed&amp;nbsp;been distributed to the correct
    design elements?
&lt;/p&gt;
&lt;p&gt;
    Does the design provide enough information for test design? For example, are the collaborations between design elements
    clear enough to create integration tests?
&lt;/p&gt;
&lt;p&gt;
    Have redundant areas of the design been removed so the Implementation does not contain redundant code?
&lt;/p&gt;</sectionDescription>
  </sections>
  <sections xmi:id="__4O2AD6WEduAL-bCqar_dg" name="Organization and Clarity" guid="__4O2AD6WEduAL-bCqar_dg">
    <sectionDescription>&lt;p&gt;
    Does the design describe the system at the appropriate level of abstraction, given the objectives? This usually means
    the system is described at a number of different levels of&amp;nbsp;abstraction and perspectives.
&lt;/p&gt;
&lt;p&gt;
    Does the design use common vocabulary and terms from the business and technical domains?
&lt;/p&gt;
&lt;p&gt;
    Does the design describe the behavior of the elements unambiguously to the extent that developer tests can be created
    toverify the implementation?
&lt;/p&gt;
&lt;p&gt;
    Are the design's constructs, vocabulary, and semantics appropriate to the problem being solved? This usually means the
    customer's vocabulary is used, and elements of the design are referenced in a consistent manner.
&lt;/p&gt;
&lt;p&gt;
    Is the design organized in a way that team members can easily find the information they're looking for?
&lt;/p&gt;
Is the notation used to&amp;nbsp;describe the design&amp;nbsp;used consistently?&lt;br /&gt;
&lt;p&gt;
    Is the design organized in a way that helps team members modify it without contending for the same part of the design?
    That is, can mulitple people work on the design in parallel?
&lt;/p&gt;
&lt;p&gt;
    Are the names of elements within the design consistent and easy to interpret?
&lt;/p&gt;
&lt;p&gt;
    Does each design element represent a clearly defined abstraction?
&lt;/p&gt;
&lt;p&gt;
    Is the design as simple as it can be while fulfilling the objectives of the design and giving sufficient direction to
    implementers?
&lt;/p&gt;
&lt;p&gt;
    Is the design clear enough and contain enough detail so it can be implemented?
&lt;/p&gt;</sectionDescription>
  </sections>
  <sections xmi:id="_dahBcD6SEduAL-bCqar_dg" name="Architecture" guid="_dahBcD6SEduAL-bCqar_dg">
    <sectionDescription>&lt;p&gt;
    Is the architecture clearly called out in the design ? Can team members and stakeholders clearly identify the portion
    of the design that is the architecture?
&lt;/p&gt;
&lt;p&gt;
    Are architectural mechanisms (patterns) clearly defined in the design so they're reusable and understandable?
&lt;/p&gt;
&lt;p&gt;
    Are architectural mechanisms used appropriately? Are they applied in all applicable circumstances?
&lt;/p&gt;</sectionDescription>
  </sections>
  <sections xmi:id="_kWnQ4D6SEduAL-bCqar_dg" name="Subsystems" guid="_kWnQ4D6SEduAL-bCqar_dg">
    <sectionDescription>&lt;p&gt;
    Do all elements within a subsystem have private visibility? In other words, is the subsystem interface the&amp;nbsp;only
    way to access the behavior of elements inside the subsystem?
&lt;/p&gt;
&lt;p&gt;
    Is the interface for each subsystem clearly defined in the design?
&lt;/p&gt;
&lt;p&gt;
    Are the subsystem dependencies documented?&amp;nbsp;
&lt;/p&gt;</sectionDescription>
  </sections>
</org.eclipse.epf.uma:ContentDescription>