Use Cases

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 status.

In order to attribute changes to a specific developer it is neceessary to create a developers element. Within this element you should add a single person element for each develop who works on the project.

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 contexts element.

Common contexts used in an software development project are:

<contexts>
 <context id="code" title="Changes to the Code Base"/>
 <context id="docs" title="Changes to Documentation"/>
 <context id="admin" title="Changes to Project Administration"/>
 <context id="design" title="Changes to Design"/>
 <context id="build" title="Changes to Build"/>
</contexts> 
          
          

Actions that describe the changed in a release are placed within a changes.

The details of each release are enclosed within a release element, so you need to create that now.

Each release can have a notes 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.

During the development cycle for the release action elements should be added for each significant contribution to the release.

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 importance attribute to "high".

To generate a changelog from your status.xml file you need to request /changes.html or changes.pdf or whatever format you have enabled within Forrest using output plugins.

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 changes.rss.

You can generate a change log for a specific version by specifying a version number in the request, for example, changes_0.1.html.

A use case is enclosed within a useCase element. Each use case should be given a brief title to describe it.

Each use case should be described in terms of:

• The objective
• The expected results
• The justification

This information should be placed in the description 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.

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 step element which are chilren of a steps element.

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.

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 required="false" attribute to the step element.

Provide, within a result 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.

A fixme note is enclosed within a fixme 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:

• Enhancement - a nice to have ehancment that may or may not be implemented.
• Low - this is considered an important addition to the use case, but everything works without it.
• High - this is an important addition. Everything works without it, but having this implmeneted would improve the application considerably.
• 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.
• Blocker - this is preventing the correct operation of this use case and must be implmeneted ASAP

Although this step is optional, it is good practice to allways add a <fixme priority="blocker">Not yet implemented</fixme> element to all new steps. This is becuase these nodes will be used to build a functionality matrix later on.

Sometimes there will be alternative paths through each step. These can be described in an alternatives 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.

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.

Request http://localhost:8888/docs/developer/useCases.xml

An XDoc is created that describes the use cases

The source document for use cases is, by default, called useCases.xml and is located in the root of the projects xdocs directory.

The URL space docs/**/useCases.xml is reserved for the projectInfo plugin. A request to /docs/developer/useCases.xml results in the useCases.xml file being translated into an XDoc as per the usual forrest processing. See the input.xmap file fo this plugin,

Request http://localhost:8888/docs/user/useCases.xml

An XDoc is created that describes the use cases

The source document for use cases is, by default, called useCases.xml and is located in the root of the projects xdocs directory.

The URL space docs/**/useCases.xml is reserved for the projectInfo plugin. A request to /docs/user/useCases.xml results in the useCases.xml file being translated into an XDoc as per the usual forrest processing, see input.xmap for more details.

Request http://localhost:8888/docs/developer/featureMatrix/useCases.xml

An XDoc is created that lists the steps in each use case and identifies the status of each use case.

The source document for use cases is, by default, called useCases.xml and is located in the root of the projects xdocs directory.

The URL space docs/**/useCases.xml is reserved for the projectInfo plugin. A request to /docs/developer/featureMatrix/useCases.xml results in the useCases.xml file being translated into an XDoc as per the usual forrest processing. See the input.xmap file fo this plugin,