forrest-site-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: r527368 [3/6] - in /forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo: ./ docs/developer/useCases/ docs/user/useCases/ images/ skin/ skin/images/ svn-log/ useCases/
Date Wed, 11 Apr 2007 02:03:34 GMT
Modified: forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/all.html
URL: http://svn.apache.org/viewvc/forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/all.html?view=diff&rev=527368&r1=527367&r2=527368
==============================================================================
--- forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/all.html (original)
+++ forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/all.html Tue Apr 10 19:03:32 2007
@@ -77,7 +77,7 @@
     |breadtrail
     +-->
 <div class="breadtrail">
-             
+
              &nbsp;
            </div>
 <!--+
@@ -245,14 +245,18 @@
 <div class="section">
 <a name="N1000B"></a><a name="Write+status.xml+File"></a>
 <h3 class="underlined_5">Write status.xml File</h3>
-<p>Status.xml if an XML file that records the actions that have been taken in each release
-      of a project. You can then generate a Change Log from that file using the projectInfo
-      plugin.</p>
+<p>
+        Status.xml if an XML file that records the actions that have been taken
+        in each release of a project. You can then generate a Change Log from
+        that file using the projectInfo plugin.
+      </p>
 <a name="N10014"></a><a name="Justification"></a>
 <h4>Justification</h4>
-<p>Provide a central location and a semi-structured format for recording
-        actions taken during project development. This file can then be used to 
-        generate various views on the changes in a release. For example:</p>
+<p>
+          Provide a central location and a semi-structured format for recording
+          actions taken during project development. This file can then be used
+          to generate various views on the changes in a release. For example:
+        </p>
 <ul>
           
 <li>Changes between releases</li>
@@ -270,38 +274,30 @@
 <strong>Create/open a status.xml file</strong>
 </li>
       
-      
 <li>
 <strong>Create a developer list</strong>
 </li>
-
-      
       
 <li>
 <strong>Create a contexts list</strong>
 </li>
       
-      
 <li>
 <strong>Create a changes element</strong>
 </li>
       
-      
 <li>
 <strong>Create a release element</strong>
 </li>
-
-        
+      
 <li>
 <strong>Create a notes element</strong>
 </li>
-
-        
+      
 <li>
 <strong>Add actions taken during the development cycle</strong>
 </li>
-
-        
+      
 <li>
 <strong>Generate the change log</strong>
 </li>
@@ -317,39 +313,48 @@
 <tr>
 <td>1. Create/open a status.xml file</td><td>
           
-<p>In your favourite XML editor either create a new file
-          or open an existing status.xml file. The default location of these files
-          within a Forrest content object is in the project root. This file should
-          conform to one of the status.xml schemas. The root element for this
-          document is <span class="codefrag">status</span>.</p>
+<p>
+            In your favourite XML editor either create a new file or open an
+            existing status.xml file. The default location of these files within
+            a Forrest content object is in the project root. This file should
+            conform to one of the status.xml schemas. The root element for this
+            document is <span class="codefrag">status</span>.
+          </p>
         
 </td><td>You have either a blank status.xml document or an existing one ready for editing.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>2. Create a developer list</td><td>
           
-<p>In order to attribute changes to a specific developer it is neceessary to create
-          a <span class="codefrag">developers</span> element. Within this element you should add a single
-          <span class="codefrag">person</span> element for each develop who works on the project.</p>
+<p>
+            In order to attribute changes to a specific developer it is
+            neceessary to create a <span class="codefrag">developers</span> element. Within this
+            element you should add a single <span class="codefrag">person</span> element for each
+            develop who works on the project.
+          </p>
         
 </td><td>Each developer is identified in the status.xml file.</td><td>Implemented</td>
 </tr>
-
-      
       
 <tr>
 <td>3. Create a contexts list</td><td>
           
-<p>Each action within a release is given a context to help classify changes.
-          When reports are created the context of an action is used to create a more
-          readable report in which similar actions are grouped together. You can
-          specify any contexts you like within the <span class="codefrag">contexts</span> element.</p>
+<p>
+            Each action within a release is given a context to help classify
+            changes. When reports are created the context of an action is used
+            to create a more readable report in which similar actions are
+            grouped together. You can specify any contexts you like within the
+            <span class="codefrag">contexts</span> element.
+          </p>
+
           
-<p>Common contexts used in an software development project are:</p>
+<p>
+            Common contexts used in an software development project are:
+          </p>
           
 <pre class="code">
+
 &lt;contexts&gt;
  &lt;context id="code" title="Changes to the Code Base"/&gt;
  &lt;context id="docs" title="Changes to Documentation"/&gt;
@@ -357,80 +362,97 @@
  &lt;context id="design" title="Changes to Design"/&gt;
  &lt;context id="build" title="Changes to Build"/&gt;
 &lt;/contexts&gt; 
+          
           </pre>
         
 </td><td>The status.xml file describes the sufficient contexts to group common
         actions together.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>4. Create a changes element</td><td>
           
-<p>Actions that describe the changed in a release are placed within
-          a <span class="codefrag">changes</span>.</p>
+<p>
+            Actions that describe the changed in a release are placed within a
+            <span class="codefrag">changes</span>.
+          </p>
         
 </td><td>Status.xml holds an changes element that will group all release 
         information.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>5. Create a release element</td><td>
           
-<p>The details of each release are enclosed within a <span class="codefrag">release</span> element,
-          so you need to create that now.</p>
+<p>
+            The details of each release are enclosed within a
+            <span class="codefrag">release</span> element, so you need to create that now.
+          </p>
         
 </td><td>You have the container for your current development release.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>6. Create a notes element</td><td>
-            
-<p>Each release can have a <span class="codefrag">notes</span> section. This is used
-            to provide descriptive text at the start of many reports. The notes
-            should describe the release in fairly high level detail, it should
-            not describe any change descriptions, these will be added in the 
-            next step.</p>
           
+<p>
+            Each release can have a <span class="codefrag">notes</span> section. This is used to
+            provide descriptive text at the start of many reports. The notes
+            should describe the release in fairly high level detail, it should
+            not describe any change descriptions, these will be added in the
+            next step.
+          </p>
+        
 </td><td>You have a user focussed description of the project and this release.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>7. Add actions taken during the development cycle</td><td>
-            
-<p>During the development cycle for the release <span class="codefrag">action</span> elements
-            should be added for each significant contribution to the release.</p>
-            
-            
-<p>If the change is of particular significance and you woul dlike it to appear
-            in the release notes generated by the projectInfo plugin you should set the
-            <span class="codefrag">importance</span> attribute to <span class="codefrag">"high"</span>.</p>
           
+<p>
+            During the development cycle for the release <span class="codefrag">action</span>
+            elements should be added for each significant contribution to the
+            release.
+          </p>
+
+          
+<p>
+            If the change is of particular significance and you woul dlike it to
+            appear in the release notes generated by the projectInfo plugin you
+            should set the <span class="codefrag">importance</span> attribute to
+            <span class="codefrag">"high"</span>.
+          </p>
+        
 </td><td>Each significant change in this development cycle is describe in a 
           <span class="codefrag">action</span> element.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>8. Generate the change log</td><td>
-            
-<p>To generate a changelog from your status.xml file you need to request
-            <span class="codefrag">/changes.html</span> or <span class="codefrag">changes.pdf</span> or whatever format
-            you have enabled within Forrest using output plugins.</p>
-            
-            
-<p>Note that the projectInfo plugin provides a special RSS output format
-            of. Technically, this should not be part of an input plugin and therefore
-            it may be moved at a later date. However, you will always be able to 
-            generate the RSS feed by requesting <span class="codefrag">changes.rss</span>.</p>
-            
-            
-<p>You can generate a change log for a specific version by specifying a 
-            version number in the request, for example, <span class="codefrag">changes_0.1.html</span>.</p>
           
+<p>
+            To generate a changelog from your status.xml file you need to
+            request <span class="codefrag">/changes.html</span> or <span class="codefrag">changes.pdf</span> or
+            whatever format you have enabled within Forrest using output
+            plugins.
+          </p>
+
+          
+<p>
+            Note that the projectInfo plugin provides a special RSS output
+            format of. Technically, this should not be part of an input plugin
+            and therefore it may be moved at a later date. However, you will
+            always be able to generate the RSS feed by requesting
+            <span class="codefrag">changes.rss</span>.
+          </p>
+
+          
+<p>
+            You can generate a change log for a specific version by specifying a
+            version number in the request, for example,
+            <span class="codefrag">changes_0.1.html</span>.
+          </p>
+        
 </td><td>Your project is able to generate a changelog.</td><td>Implemented</td>
 </tr>
     
@@ -441,16 +463,24 @@
 <div class="section">
 <a name="N10109"></a><a name="Write+Use+Case+Documentation"></a>
 <h3 class="underlined_5">Write Use Case Documentation</h3>
-<p>Write semi-structured use case documents so that they can be reused in a variety of ways.
-      This use case describews a process for writing such documents. This document is derived from
-      such a <a href="useCaseFeatures.source.xml">source document</a>.</p>
+<p>
+        Write semi-structured use case documents so that they can be reused in a
+        variety of ways. This use case describews a process for writing such
+        documents. This document is derived from such a
+        <a href="useCaseFeatures.source.xml">source document</a>.
+      </p>
 <a name="N10116"></a><a name="Justification-N10116"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project. It is very useful for describing what an applicaiton must
-        do and what patchs through the system can be taken.</p>
-<p>By bringing this information together in a semi-structured document we can use it in many
-        different ways. For example:</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project. It is very useful for describing
+          what an applicaiton must do and what patchs through the system can be
+          taken.
+        </p>
+<p>
+          By bringing this information together in a semi-structured document we
+          can use it in many different ways. For example:
+        </p>
 <ul>
           
 <li>Requirements Documentation</li>
@@ -471,43 +501,35 @@
 <li>
 <strong>Create/open a Use Case file</strong>
 </li>
-
       
 <li>
 <strong>Create a new use case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Describe the overall objective of the use case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Define each step in the Use Case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Descripbe the step</strong>
 </li>
-
-        
+      
 <li>
 <strong>Describe the expected results</strong>
 </li>
-
-        
+      
 <li>
 <strong>Add "fixme" notes</strong> (Optional)</li>
-
-        
+      
 <li>
 <strong>Add alternatives</strong> (Optional)</li>
-        
-        
+      
 <li>
-<strong>Write Implementation Notes</strong> (Optional)</li>          
+<strong>Write Implementation Notes</strong> (Optional)</li>
     
 </ol>
 <a name="N10163"></a><a name="Details-N10163"></a>
@@ -518,158 +540,180 @@
 </tr>
       
 <tr>
-<td>1. Create/open a Use Case file</td><td>In your favourite XML editor either create a new file
-        or open an existing use case file. The default location of these files
-        within a Forrest content object is <span class="codefrag">/content/documentation/useCases/**.xml</span>
+<td>1. Create/open a Use Case file</td><td>
+          In your favourite XML editor either create a new file or open an
+          existing use case file. The default location of these files within a
+          Forrest content object is
+          <span class="codefrag">/content/documentation/useCases/**.xml</span>
         </td><td>You have either a blank use case document or an existing one ready for editing.</td><td>
            Implemented with fixmes:-<br>
          High: 1<br>
 </td>
 </tr>
-
       
 <tr>
 <td>2. Create a new use case</td><td>
           
-<p>A use case is enclosed within a <span class="codefrag">useCase</span> element.
-          Each use case should be given a brief <span class="codefrag">title</span> to describe it.</p>
-
+<p>
+            A use case is enclosed within a <span class="codefrag">useCase</span> element. Each
+            use case should be given a brief <span class="codefrag">title</span> to describe it.
+          </p>
         
 </td><td>You have the container for your new use case.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>3. Describe the overall objective of the use case</td><td>
-            
-<p>Each use case should be described in terms of:</p>
-            
+          
+<p>
+            Each use case should be described in terms of:
+          </p>
+          
 <ul>
-              
+            
 <li>The objective</li>
-              
+            
 <li>The expected results</li>
-              
-<li>The justification</li>
             
+<li>The justification</li>
+          
 </ul>
-            
-<p>This information should be placed in the <span class="codefrag">description</span> element
-          of your use case. This node allows any XDoc markup and therefore you are
-          reasonably free to use whatever formatting or images are needed to convey the
-          important details most efficiently.</p>
           
+<p>
+            This information should be placed in the <span class="codefrag">description</span>
+            element of your use case. This node allows any XDoc markup and
+            therefore you are reasonably free to use whatever formatting or
+            images are needed to convey the important details most efficiently.
+          </p>
+        
 </td><td>You have a use case that is described sufficiently well for an average user of the end system
         to understand its purpose.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>4. Define each step in the Use Case</td><td>
-            
-<p>Each use case will be subdivided into one or more steps that must be carried out
-          in order to complete the task. Each of these steps is defined within a <span class="codefrag">step</span>
-          element which are chilren of a <span class="codefrag">steps</span> element.</p>
           
+<p>
+            Each use case will be subdivided into one or more steps that must be
+            carried out in order to complete the task. Each of these steps is
+            defined within a <span class="codefrag">step</span> element which are chilren of a
+            <span class="codefrag">steps</span> element.
+          </p>
+        
 </td><td></td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>5. Descripbe the step</td><td>
-            
-<p>Each step has a title and a description. The description should provide enough information
-            for a user to complete the task and for a developer to implement support for the user in that
-            task.</p>
+          
+<p>
+            Each step has a title and a description. The description should
+            provide enough information for a user to complete the task and for a
+            developer to implement support for the user in that task.
+          </p>
 
-            
-<p>In addition each step can be described as required or optional. By default a step is assumed
-            be required. To set it to optional add a <span class="codefrag">required="false"</span> attribute to the
-            <span class="codefrag">step</span> element.</p>
           
+<p>
+            In addition each step can be described as required or optional. By
+            default a step is assumed be required. To set it to optional add a
+            <span class="codefrag">required="false"</span> attribute to the <span class="codefrag">step</span>
+            element.
+          </p>
+        
 </td><td>A user will be able to follow instructions on how to carry out the step.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>6. Describe the expected results</td><td>
-            
-<p>Provide, within a <span class="codefrag">result</span> a brief description of the expected results from
-            this step. This should summarise what state the application will be in once this use case
-            has been performed.</p>
           
+<p>
+            Provide, within a <span class="codefrag">result</span> a brief description of the
+            expected results from this step. This should summarise what state
+            the application will be in once this use case has been performed.
+          </p>
+        
 </td><td>You will have provided enough information to allow developers to test the functionality and
           users to identify when a step has been succesfully completed.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>7. Add "fixme" notes<br>(Optional)</td><td>
-            
-<p>A fixme note is enclosed within a <span class="codefrag">fixme</span> element. It describes something that
-            remains to be done within this step. Each fixme has a priority attribute which can take one of
-            of the followin values:</p>
-
-            
+          
+<p>
+            A fixme note is enclosed within a <span class="codefrag">fixme</span> element. It
+            describes something that remains to be done within this step. Each
+            fixme has a priority attribute which can take one of of the followin
+            values:
+          </p>
+          
 <ul>
-              
+            
 <li>Enhancement - a nice to have ehancment that may or may not be implemented.</li>
-              
+            
 <li>Low - this is considered an important addition to the use case, but everything works without it.</li>
-              
+            
 <li>High - this is an important addition. Everything works without it, but having this implmeneted would
               improve the application considerably.</li>
-              
+            
 <li>Major - this is nor preventing work that utilises the use case, but it is considered a requirement
               for the next release since it adds key functionlaity.</li>
-              
-<li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
             
+<li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
+          
 </ul>
-
-            
-<p>Although this step is optional, it is good practice to allways add a 
-            <span class="codefrag">&lt;fixme priority="blocker"&gt;Not yet implemented&lt;/fixme&gt;</span>
-            element to all new steps. This is becuase these nodes will be used to build a 
-            functionality matrix later on.</p>
           
+<p>
+            Although this step is optional, it is good practice to allways add a
+            <span class="codefrag">&lt;fixme priority="blocker"&gt;Not yet
+            implemented&lt;/fixme&gt;</span> element to all new steps. This is
+            becuase these nodes will be used to build a functionality matrix
+            later on.
+          </p>
+        
 </td><td>Users will be able to understand to what degree a step is implemented and developers will be able to 
           see what remains to be done.</td><td>
            Implemented with fixmes:-<br>
 </td>
 </tr>
-
-        
+      
 <tr>
 <td>8. Add alternatives<br>(Optional)</td><td>
-            
-<p>Sometimes there will be alternative paths through each step. These can be described in an
-            <span class="codefrag">alternatives</span> element that allows free-form XDoc content. However, please be
-            careful, if an alternative is more than a simple variation you may want to consider a 
-            whole new use case for the alternative.</p>
           
+<p>
+            Sometimes there will be alternative paths through each step. These
+            can be described in an <span class="codefrag">alternatives</span> element that allows
+            free-form XDoc content. However, please be careful, if an
+            alternative is more than a simple variation you may want to consider
+            a whole new use case for the alternative.
+          </p>
+        
 </td><td>Minor variations in the path through a use case will be documented for your users.</td><td>Implemented</td>
 </tr>
-        
-        
+      
 <tr>
 <td>9. Write Implementation Notes<br>(Optional)</td><td>
-            
-<p>Developer implementation notes for each of the steps should be added either when writing the
-            initial use case or later during the development phases of the use case. These notes are for technical readers
-            and are intended to help those who come after the initial author to get a starting point when inspecting how
-            a feature is implemented. It is not intended that these notes will contain full implementation details, only an
-            overview should be provided.</p>
           
+<p>
+            Developer implementation notes for each of the steps should be added
+            either when writing the initial use case or later during the
+            development phases of the use case. These notes are for technical
+            readers and are intended to help those who come after the initial
+            author to get a starting point when inspecting how a feature is
+            implemented. It is not intended that these notes will contain full
+            implementation details, only an overview should be provided.
+          </p>
+        
 </td><td>A technical reader will be able to gain a baisc understanding of how each step is implemented in the 
           application.</td><td>Implemented</td>
-</tr>          
+</tr>
     
 </table>
 <a name="N10239"></a><a name="Generate+Use+Case+Documentation+for+Developers"></a>
 <h3 class="underlined_5">Generate Use Case Documentation for Developers</h3>
-<p>Generate a complete list of all use cases for a project in a format useful to 
-      developers of the application. This list is to include:</p>
+<p>
+        Generate a complete list of all use cases for a project in a format
+        useful to developers of the application. This list is to include:
+      </p>
 <ul>
         
 <li>a description of the use case</li>
@@ -682,20 +726,26 @@
         
 <li>details of common alternatives in each step</li>
         
-<li>implementation notes for each step</li> 
+<li>implementation notes for each step</li>
       
 </ul>
 <a name="N10257"></a><a name="Justification-N10257"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Unfortunately this use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</div>
+<div class="content">
+          Unfortunately this use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </div>
 </div>
 <a name="N10264"></a><a name="Summary-N10264"></a>
 <h4>Summary</h4>
@@ -717,8 +767,7 @@
 <td>1. Make HTTP request</td><td>
           
 <p>
-            Request
-            http://localhost:8888/docs/developer/useCases.xml
+            Request http://localhost:8888/docs/developer/useCases.xml
           </p>
         
 </td><td>
@@ -736,7 +785,10 @@
 </table>
 <a name="N10292"></a><a name="Generate+Use+Case+Documentation+for+Users"></a>
 <h3 class="underlined_5">Generate Use Case Documentation for Users</h3>
-<p>Generate a complete list of all use cases for a project. This list is to include:</p>
+<p>
+        Generate a complete list of all use cases for a project. This list is to
+        include:
+      </p>
 <ul>
         
 <li>a description of the use case</li>
@@ -752,15 +804,21 @@
 </ul>
 <a name="N102AD"></a><a name="Justification-N102AD"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Unfortunately the use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</div>
+<div class="content">
+          Unfortunately the use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </div>
 </div>
 <a name="N102BA"></a><a name="Summary-N102BA"></a>
 <h4>Summary</h4>
@@ -782,8 +840,7 @@
 <td>1. Make HTTP request</td><td>
           
 <p>
-            Request
-            http://localhost:8888/docs/user/useCases.xml
+            Request http://localhost:8888/docs/user/useCases.xml
           </p>
         
 </td><td>
@@ -802,13 +859,18 @@
 </table>
 <a name="N102EA"></a><a name="Generate+a+Functionality+Matrix"></a>
 <h3 class="underlined_5">Generate a Functionality Matrix</h3>
-<p>If a use case document is correcly marked up with <span class="codefrag">fixme</span> elements it is possible
-      to create a functionality matrix for each use case. This will show how complete the implementation
-      of a use case is.</p>
-<p>A table can be created which shows each of the steps in a use case, each step can be given a
-      count for the bumber of fixme items outstanding on each of the steps. Furthermore, since each
-      <span class="codefrag">fixme</span> is given a priority we can clearly indicate which use cases are operational an 
-      hich are not.</p>
+<p>
+        If a use case document is correcly marked up with <span class="codefrag">fixme</span>
+        elements it is possible to create a functionality matrix for each use
+        case. This will show how complete the implementation of a use case is.
+      </p>
+<p>
+        A table can be created which shows each of the steps in a use case, each
+        step can be given a count for the bumber of fixme items outstanding on
+        each of the steps. Furthermore, since each <span class="codefrag">fixme</span> is given a
+        priority we can clearly indicate which use cases are operational an hich
+        are not.
+      </p>
 <a name="N102FC"></a><a name="Summary-N102FC"></a>
 <h4>Summary</h4>
 <ol class="steps">
@@ -836,14 +898,16 @@
 </td><td>
           
 <p>
-            An XDoc is created that lists the steps in each use case and identifies the status
-            of each use case.
+            An XDoc is created that lists the steps in each use case and
+            identifies the status of each use case.
           </p>
         
 </td><td>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Not Implemented</div>
+<div class="content">
+              Not Implemented
+            </div>
 </div>
          Blockers: 1<br>
 </td>

Modified: forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/changeLogFeatures.html
URL: http://svn.apache.org/viewvc/forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/changeLogFeatures.html?view=diff&rev=527368&r1=527367&r2=527368
==============================================================================
--- forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/changeLogFeatures.html (original)
+++ forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/changeLogFeatures.html Tue Apr 10 19:03:32 2007
@@ -77,7 +77,7 @@
     |breadtrail
     +-->
 <div class="breadtrail">
-             
+
              &nbsp;
            </div>
 <!--+
@@ -187,14 +187,18 @@
 <div class="section">
 <a name="N1000B"></a><a name="Write+status.xml+File"></a>
 <h3 class="underlined_5">Write status.xml File</h3>
-<p>Status.xml if an XML file that records the actions that have been taken in each release
-      of a project. You can then generate a Change Log from that file using the projectInfo
-      plugin.</p>
+<p>
+        Status.xml if an XML file that records the actions that have been taken
+        in each release of a project. You can then generate a Change Log from
+        that file using the projectInfo plugin.
+      </p>
 <a name="N10014"></a><a name="Justification"></a>
 <h4>Justification</h4>
-<p>Provide a central location and a semi-structured format for recording
-        actions taken during project development. This file can then be used to 
-        generate various views on the changes in a release. For example:</p>
+<p>
+          Provide a central location and a semi-structured format for recording
+          actions taken during project development. This file can then be used
+          to generate various views on the changes in a release. For example:
+        </p>
 <ul>
           
 <li>Changes between releases</li>
@@ -212,38 +216,30 @@
 <strong>Create/open a status.xml file</strong>
 </li>
       
-      
 <li>
 <strong>Create a developer list</strong>
 </li>
-
-      
       
 <li>
 <strong>Create a contexts list</strong>
 </li>
       
-      
 <li>
 <strong>Create a changes element</strong>
 </li>
       
-      
 <li>
 <strong>Create a release element</strong>
 </li>
-
-        
+      
 <li>
 <strong>Create a notes element</strong>
 </li>
-
-        
+      
 <li>
 <strong>Add actions taken during the development cycle</strong>
 </li>
-
-        
+      
 <li>
 <strong>Generate the change log</strong>
 </li>
@@ -259,39 +255,48 @@
 <tr>
 <td>1. Create/open a status.xml file</td><td>
           
-<p>In your favourite XML editor either create a new file
-          or open an existing status.xml file. The default location of these files
-          within a Forrest content object is in the project root. This file should
-          conform to one of the status.xml schemas. The root element for this
-          document is <span class="codefrag">status</span>.</p>
+<p>
+            In your favourite XML editor either create a new file or open an
+            existing status.xml file. The default location of these files within
+            a Forrest content object is in the project root. This file should
+            conform to one of the status.xml schemas. The root element for this
+            document is <span class="codefrag">status</span>.
+          </p>
         
 </td><td>You have either a blank status.xml document or an existing one ready for editing.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>2. Create a developer list</td><td>
           
-<p>In order to attribute changes to a specific developer it is neceessary to create
-          a <span class="codefrag">developers</span> element. Within this element you should add a single
-          <span class="codefrag">person</span> element for each develop who works on the project.</p>
+<p>
+            In order to attribute changes to a specific developer it is
+            neceessary to create a <span class="codefrag">developers</span> element. Within this
+            element you should add a single <span class="codefrag">person</span> element for each
+            develop who works on the project.
+          </p>
         
 </td><td>Each developer is identified in the status.xml file.</td><td>Implemented</td>
 </tr>
-
-      
       
 <tr>
 <td>3. Create a contexts list</td><td>
           
-<p>Each action within a release is given a context to help classify changes.
-          When reports are created the context of an action is used to create a more
-          readable report in which similar actions are grouped together. You can
-          specify any contexts you like within the <span class="codefrag">contexts</span> element.</p>
+<p>
+            Each action within a release is given a context to help classify
+            changes. When reports are created the context of an action is used
+            to create a more readable report in which similar actions are
+            grouped together. You can specify any contexts you like within the
+            <span class="codefrag">contexts</span> element.
+          </p>
+
           
-<p>Common contexts used in an software development project are:</p>
+<p>
+            Common contexts used in an software development project are:
+          </p>
           
 <pre class="code">
+
 &lt;contexts&gt;
  &lt;context id="code" title="Changes to the Code Base"/&gt;
  &lt;context id="docs" title="Changes to Documentation"/&gt;
@@ -299,80 +304,97 @@
  &lt;context id="design" title="Changes to Design"/&gt;
  &lt;context id="build" title="Changes to Build"/&gt;
 &lt;/contexts&gt; 
+          
           </pre>
         
 </td><td>The status.xml file describes the sufficient contexts to group common
         actions together.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>4. Create a changes element</td><td>
           
-<p>Actions that describe the changed in a release are placed within
-          a <span class="codefrag">changes</span>.</p>
+<p>
+            Actions that describe the changed in a release are placed within a
+            <span class="codefrag">changes</span>.
+          </p>
         
 </td><td>Status.xml holds an changes element that will group all release 
         information.</td><td>Implemented</td>
 </tr>
       
-      
 <tr>
 <td>5. Create a release element</td><td>
           
-<p>The details of each release are enclosed within a <span class="codefrag">release</span> element,
-          so you need to create that now.</p>
+<p>
+            The details of each release are enclosed within a
+            <span class="codefrag">release</span> element, so you need to create that now.
+          </p>
         
 </td><td>You have the container for your current development release.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>6. Create a notes element</td><td>
-            
-<p>Each release can have a <span class="codefrag">notes</span> section. This is used
-            to provide descriptive text at the start of many reports. The notes
-            should describe the release in fairly high level detail, it should
-            not describe any change descriptions, these will be added in the 
-            next step.</p>
           
+<p>
+            Each release can have a <span class="codefrag">notes</span> section. This is used to
+            provide descriptive text at the start of many reports. The notes
+            should describe the release in fairly high level detail, it should
+            not describe any change descriptions, these will be added in the
+            next step.
+          </p>
+        
 </td><td>You have a user focussed description of the project and this release.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>7. Add actions taken during the development cycle</td><td>
-            
-<p>During the development cycle for the release <span class="codefrag">action</span> elements
-            should be added for each significant contribution to the release.</p>
-            
-            
-<p>If the change is of particular significance and you woul dlike it to appear
-            in the release notes generated by the projectInfo plugin you should set the
-            <span class="codefrag">importance</span> attribute to <span class="codefrag">"high"</span>.</p>
           
+<p>
+            During the development cycle for the release <span class="codefrag">action</span>
+            elements should be added for each significant contribution to the
+            release.
+          </p>
+
+          
+<p>
+            If the change is of particular significance and you woul dlike it to
+            appear in the release notes generated by the projectInfo plugin you
+            should set the <span class="codefrag">importance</span> attribute to
+            <span class="codefrag">"high"</span>.
+          </p>
+        
 </td><td>Each significant change in this development cycle is describe in a 
           <span class="codefrag">action</span> element.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>8. Generate the change log</td><td>
-            
-<p>To generate a changelog from your status.xml file you need to request
-            <span class="codefrag">/changes.html</span> or <span class="codefrag">changes.pdf</span> or whatever format
-            you have enabled within Forrest using output plugins.</p>
-            
-            
-<p>Note that the projectInfo plugin provides a special RSS output format
-            of. Technically, this should not be part of an input plugin and therefore
-            it may be moved at a later date. However, you will always be able to 
-            generate the RSS feed by requesting <span class="codefrag">changes.rss</span>.</p>
-            
-            
-<p>You can generate a change log for a specific version by specifying a 
-            version number in the request, for example, <span class="codefrag">changes_0.1.html</span>.</p>
           
+<p>
+            To generate a changelog from your status.xml file you need to
+            request <span class="codefrag">/changes.html</span> or <span class="codefrag">changes.pdf</span> or
+            whatever format you have enabled within Forrest using output
+            plugins.
+          </p>
+
+          
+<p>
+            Note that the projectInfo plugin provides a special RSS output
+            format of. Technically, this should not be part of an input plugin
+            and therefore it may be moved at a later date. However, you will
+            always be able to generate the RSS feed by requesting
+            <span class="codefrag">changes.rss</span>.
+          </p>
+
+          
+<p>
+            You can generate a change log for a specific version by specifying a
+            version number in the request, for example,
+            <span class="codefrag">changes_0.1.html</span>.
+          </p>
+        
 </td><td>Your project is able to generate a changelog.</td><td>Implemented</td>
 </tr>
     

Modified: forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/useCaseFeatures.html
URL: http://svn.apache.org/viewvc/forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/useCaseFeatures.html?view=diff&rev=527368&r1=527367&r2=527368
==============================================================================
--- forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/useCaseFeatures.html (original)
+++ forrest/site/pluginDocs/plugins_0_80/org.apache.forrest.plugin.input.projectInfo/docs/user/useCases/useCaseFeatures.html Tue Apr 10 19:03:32 2007
@@ -77,7 +77,7 @@
     |breadtrail
     +-->
 <div class="breadtrail">
-             
+
              &nbsp;
            </div>
 <!--+
@@ -226,16 +226,24 @@
 <div class="section">
 <a name="N1000B"></a><a name="Write+Use+Case+Documentation"></a>
 <h3 class="underlined_5">Write Use Case Documentation</h3>
-<p>Write semi-structured use case documents so that they can be reused in a variety of ways.
-      This use case describews a process for writing such documents. This document is derived from
-      such a <a href="useCaseFeatures.source.xml">source document</a>.</p>
+<p>
+        Write semi-structured use case documents so that they can be reused in a
+        variety of ways. This use case describews a process for writing such
+        documents. This document is derived from such a
+        <a href="useCaseFeatures.source.xml">source document</a>.
+      </p>
 <a name="N10018"></a><a name="Justification"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project. It is very useful for describing what an applicaiton must
-        do and what patchs through the system can be taken.</p>
-<p>By bringing this information together in a semi-structured document we can use it in many
-        different ways. For example:</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project. It is very useful for describing
+          what an applicaiton must do and what patchs through the system can be
+          taken.
+        </p>
+<p>
+          By bringing this information together in a semi-structured document we
+          can use it in many different ways. For example:
+        </p>
 <ul>
           
 <li>Requirements Documentation</li>
@@ -256,43 +264,35 @@
 <li>
 <strong>Create/open a Use Case file</strong>
 </li>
-
       
 <li>
 <strong>Create a new use case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Describe the overall objective of the use case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Define each step in the Use Case</strong>
 </li>
-
-        
+      
 <li>
 <strong>Descripbe the step</strong>
 </li>
-
-        
+      
 <li>
 <strong>Describe the expected results</strong>
 </li>
-
-        
+      
 <li>
 <strong>Add "fixme" notes</strong> (Optional)</li>
-
-        
+      
 <li>
 <strong>Add alternatives</strong> (Optional)</li>
-        
-        
+      
 <li>
-<strong>Write Implementation Notes</strong> (Optional)</li>          
+<strong>Write Implementation Notes</strong> (Optional)</li>
     
 </ol>
 <a name="N10065"></a><a name="Details"></a>
@@ -303,158 +303,180 @@
 </tr>
       
 <tr>
-<td>1. Create/open a Use Case file</td><td>In your favourite XML editor either create a new file
-        or open an existing use case file. The default location of these files
-        within a Forrest content object is <span class="codefrag">/content/documentation/useCases/**.xml</span>
+<td>1. Create/open a Use Case file</td><td>
+          In your favourite XML editor either create a new file or open an
+          existing use case file. The default location of these files within a
+          Forrest content object is
+          <span class="codefrag">/content/documentation/useCases/**.xml</span>
         </td><td>You have either a blank use case document or an existing one ready for editing.</td><td>
            Implemented with fixmes:-<br>
          High: 1<br>
 </td>
 </tr>
-
       
 <tr>
 <td>2. Create a new use case</td><td>
           
-<p>A use case is enclosed within a <span class="codefrag">useCase</span> element.
-          Each use case should be given a brief <span class="codefrag">title</span> to describe it.</p>
-
+<p>
+            A use case is enclosed within a <span class="codefrag">useCase</span> element. Each
+            use case should be given a brief <span class="codefrag">title</span> to describe it.
+          </p>
         
 </td><td>You have the container for your new use case.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>3. Describe the overall objective of the use case</td><td>
-            
-<p>Each use case should be described in terms of:</p>
-            
+          
+<p>
+            Each use case should be described in terms of:
+          </p>
+          
 <ul>
-              
+            
 <li>The objective</li>
-              
+            
 <li>The expected results</li>
-              
-<li>The justification</li>
             
+<li>The justification</li>
+          
 </ul>
-            
-<p>This information should be placed in the <span class="codefrag">description</span> element
-          of your use case. This node allows any XDoc markup and therefore you are
-          reasonably free to use whatever formatting or images are needed to convey the
-          important details most efficiently.</p>
           
+<p>
+            This information should be placed in the <span class="codefrag">description</span>
+            element of your use case. This node allows any XDoc markup and
+            therefore you are reasonably free to use whatever formatting or
+            images are needed to convey the important details most efficiently.
+          </p>
+        
 </td><td>You have a use case that is described sufficiently well for an average user of the end system
         to understand its purpose.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>4. Define each step in the Use Case</td><td>
-            
-<p>Each use case will be subdivided into one or more steps that must be carried out
-          in order to complete the task. Each of these steps is defined within a <span class="codefrag">step</span>
-          element which are chilren of a <span class="codefrag">steps</span> element.</p>
           
+<p>
+            Each use case will be subdivided into one or more steps that must be
+            carried out in order to complete the task. Each of these steps is
+            defined within a <span class="codefrag">step</span> element which are chilren of a
+            <span class="codefrag">steps</span> element.
+          </p>
+        
 </td><td></td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>5. Descripbe the step</td><td>
-            
-<p>Each step has a title and a description. The description should provide enough information
-            for a user to complete the task and for a developer to implement support for the user in that
-            task.</p>
+          
+<p>
+            Each step has a title and a description. The description should
+            provide enough information for a user to complete the task and for a
+            developer to implement support for the user in that task.
+          </p>
 
-            
-<p>In addition each step can be described as required or optional. By default a step is assumed
-            be required. To set it to optional add a <span class="codefrag">required="false"</span> attribute to the
-            <span class="codefrag">step</span> element.</p>
           
+<p>
+            In addition each step can be described as required or optional. By
+            default a step is assumed be required. To set it to optional add a
+            <span class="codefrag">required="false"</span> attribute to the <span class="codefrag">step</span>
+            element.
+          </p>
+        
 </td><td>A user will be able to follow instructions on how to carry out the step.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>6. Describe the expected results</td><td>
-            
-<p>Provide, within a <span class="codefrag">result</span> a brief description of the expected results from
-            this step. This should summarise what state the application will be in once this use case
-            has been performed.</p>
           
+<p>
+            Provide, within a <span class="codefrag">result</span> a brief description of the
+            expected results from this step. This should summarise what state
+            the application will be in once this use case has been performed.
+          </p>
+        
 </td><td>You will have provided enough information to allow developers to test the functionality and
           users to identify when a step has been succesfully completed.</td><td>Implemented</td>
 </tr>
-
-        
+      
 <tr>
 <td>7. Add "fixme" notes<br>(Optional)</td><td>
-            
-<p>A fixme note is enclosed within a <span class="codefrag">fixme</span> element. It describes something that
-            remains to be done within this step. Each fixme has a priority attribute which can take one of
-            of the followin values:</p>
-
-            
+          
+<p>
+            A fixme note is enclosed within a <span class="codefrag">fixme</span> element. It
+            describes something that remains to be done within this step. Each
+            fixme has a priority attribute which can take one of of the followin
+            values:
+          </p>
+          
 <ul>
-              
+            
 <li>Enhancement - a nice to have ehancment that may or may not be implemented.</li>
-              
+            
 <li>Low - this is considered an important addition to the use case, but everything works without it.</li>
-              
+            
 <li>High - this is an important addition. Everything works without it, but having this implmeneted would
               improve the application considerably.</li>
-              
+            
 <li>Major - this is nor preventing work that utilises the use case, but it is considered a requirement
               for the next release since it adds key functionlaity.</li>
-              
-<li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
             
+<li>Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP</li>
+          
 </ul>
-
-            
-<p>Although this step is optional, it is good practice to allways add a 
-            <span class="codefrag">&lt;fixme priority="blocker"&gt;Not yet implemented&lt;/fixme&gt;</span>
-            element to all new steps. This is becuase these nodes will be used to build a 
-            functionality matrix later on.</p>
           
+<p>
+            Although this step is optional, it is good practice to allways add a
+            <span class="codefrag">&lt;fixme priority="blocker"&gt;Not yet
+            implemented&lt;/fixme&gt;</span> element to all new steps. This is
+            becuase these nodes will be used to build a functionality matrix
+            later on.
+          </p>
+        
 </td><td>Users will be able to understand to what degree a step is implemented and developers will be able to 
           see what remains to be done.</td><td>
            Implemented with fixmes:-<br>
 </td>
 </tr>
-
-        
+      
 <tr>
 <td>8. Add alternatives<br>(Optional)</td><td>
-            
-<p>Sometimes there will be alternative paths through each step. These can be described in an
-            <span class="codefrag">alternatives</span> element that allows free-form XDoc content. However, please be
-            careful, if an alternative is more than a simple variation you may want to consider a 
-            whole new use case for the alternative.</p>
           
+<p>
+            Sometimes there will be alternative paths through each step. These
+            can be described in an <span class="codefrag">alternatives</span> element that allows
+            free-form XDoc content. However, please be careful, if an
+            alternative is more than a simple variation you may want to consider
+            a whole new use case for the alternative.
+          </p>
+        
 </td><td>Minor variations in the path through a use case will be documented for your users.</td><td>Implemented</td>
 </tr>
-        
-        
+      
 <tr>
 <td>9. Write Implementation Notes<br>(Optional)</td><td>
-            
-<p>Developer implementation notes for each of the steps should be added either when writing the
-            initial use case or later during the development phases of the use case. These notes are for technical readers
-            and are intended to help those who come after the initial author to get a starting point when inspecting how
-            a feature is implemented. It is not intended that these notes will contain full implementation details, only an
-            overview should be provided.</p>
           
+<p>
+            Developer implementation notes for each of the steps should be added
+            either when writing the initial use case or later during the
+            development phases of the use case. These notes are for technical
+            readers and are intended to help those who come after the initial
+            author to get a starting point when inspecting how a feature is
+            implemented. It is not intended that these notes will contain full
+            implementation details, only an overview should be provided.
+          </p>
+        
 </td><td>A technical reader will be able to gain a baisc understanding of how each step is implemented in the 
           application.</td><td>Implemented</td>
-</tr>          
+</tr>
     
 </table>
 <a name="N1013B"></a><a name="Generate+Use+Case+Documentation+for+Developers"></a>
 <h3 class="underlined_5">Generate Use Case Documentation for Developers</h3>
-<p>Generate a complete list of all use cases for a project in a format useful to 
-      developers of the application. This list is to include:</p>
+<p>
+        Generate a complete list of all use cases for a project in a format
+        useful to developers of the application. This list is to include:
+      </p>
 <ul>
         
 <li>a description of the use case</li>
@@ -467,20 +489,26 @@
         
 <li>details of common alternatives in each step</li>
         
-<li>implementation notes for each step</li> 
+<li>implementation notes for each step</li>
       
 </ul>
 <a name="N10159"></a><a name="Justification-N10159"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Unfortunately this use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</div>
+<div class="content">
+          Unfortunately this use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </div>
 </div>
 <a name="N10166"></a><a name="Summary-N10166"></a>
 <h4>Summary</h4>
@@ -502,8 +530,7 @@
 <td>1. Make HTTP request</td><td>
           
 <p>
-            Request
-            http://localhost:8888/docs/developer/useCases.xml
+            Request http://localhost:8888/docs/developer/useCases.xml
           </p>
         
 </td><td>
@@ -521,7 +548,10 @@
 </table>
 <a name="N10194"></a><a name="Generate+Use+Case+Documentation+for+Users"></a>
 <h3 class="underlined_5">Generate Use Case Documentation for Users</h3>
-<p>Generate a complete list of all use cases for a project. This list is to include:</p>
+<p>
+        Generate a complete list of all use cases for a project. This list is to
+        include:
+      </p>
 <ul>
         
 <li>a description of the use case</li>
@@ -537,15 +567,21 @@
 </ul>
 <a name="N101AF"></a><a name="Justification-N101AF"></a>
 <h4>Justification</h4>
-<p>A use case describes a unit of work. It is typically used in the design
-        stages of a software project, however, they can often be useful in creating
-        user documentaiton. Especially when they describe user interface functionality.</p>
+<p>
+          A use case describes a unit of work. It is typically used in the
+          design stages of a software project, however, they can often be useful
+          in creating user documentaiton. Especially when they describe user
+          interface functionality.
+        </p>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Unfortunately the use case document does not currently cover all functions
-        of the plugin since this functionlaity was added after many other features. Whilst you
-        are exploring this feature, why not add a use case to the plugin and submit a patch
-        so that those coming after you can enjoy more complete documentation.</div>
+<div class="content">
+          Unfortunately the use case document does not currently cover all
+          functions of the plugin since this functionlaity was added after many
+          other features. Whilst you are exploring this feature, why not add a
+          use case to the plugin and submit a patch so that those coming after
+          you can enjoy more complete documentation.
+        </div>
 </div>
 <a name="N101BC"></a><a name="Summary-N101BC"></a>
 <h4>Summary</h4>
@@ -567,8 +603,7 @@
 <td>1. Make HTTP request</td><td>
           
 <p>
-            Request
-            http://localhost:8888/docs/user/useCases.xml
+            Request http://localhost:8888/docs/user/useCases.xml
           </p>
         
 </td><td>
@@ -587,13 +622,18 @@
 </table>
 <a name="N101EC"></a><a name="Generate+a+Functionality+Matrix"></a>
 <h3 class="underlined_5">Generate a Functionality Matrix</h3>
-<p>If a use case document is correcly marked up with <span class="codefrag">fixme</span> elements it is possible
-      to create a functionality matrix for each use case. This will show how complete the implementation
-      of a use case is.</p>
-<p>A table can be created which shows each of the steps in a use case, each step can be given a
-      count for the bumber of fixme items outstanding on each of the steps. Furthermore, since each
-      <span class="codefrag">fixme</span> is given a priority we can clearly indicate which use cases are operational an 
-      hich are not.</p>
+<p>
+        If a use case document is correcly marked up with <span class="codefrag">fixme</span>
+        elements it is possible to create a functionality matrix for each use
+        case. This will show how complete the implementation of a use case is.
+      </p>
+<p>
+        A table can be created which shows each of the steps in a use case, each
+        step can be given a count for the bumber of fixme items outstanding on
+        each of the steps. Furthermore, since each <span class="codefrag">fixme</span> is given a
+        priority we can clearly indicate which use cases are operational an hich
+        are not.
+      </p>
 <a name="N101FE"></a><a name="Summary-N101FE"></a>
 <h4>Summary</h4>
 <ol class="steps">
@@ -621,14 +661,16 @@
 </td><td>
           
 <p>
-            An XDoc is created that lists the steps in each use case and identifies the status
-            of each use case.
+            An XDoc is created that lists the steps in each use case and
+            identifies the status of each use case.
           </p>
         
 </td><td>
 <div class="warning">
 <div class="label">Warning</div>
-<div class="content">Not Implemented</div>
+<div class="content">
+              Not Implemented
+            </div>
 </div>
          Blockers: 1<br>
 </td>



Mime
View raw message