<?xml version="1.0" encoding='UTF-8'?>

<!--
Copyright 2006 Niels Heirbaut. All rights reserved.

Redistribution and use in source (XML DocBook) and 'compiled' forms (SGML,
XML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are
permitted provided that the following conditions are met:

   1.  Redistributions of source code (XML DocBook) must retain the above
       copyright notice, this list of conditions and the following disclaimer
       as the first lines of this file unmodified.

THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
-->

<!--
This template can be used to create a Use-Case Specification as described in
the Rational Unified Process. Where applicable, comments will provide guidance
to the author. At the authors discretion these comments can be deleted.
-->

<!--{{{-->
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
 "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
[

<!--
Text entities. They are used to define document wide definitions. Replace the
'@@@ xxx @@@' definitions with the correct ones. If necessary custom text
entities should be added here.
-->
<!--{{{-->
<!ENTITY projectname    "@@@ Your Project @@@">
<!ENTITY projectacronym "@@@ Your Project Acronym @@@">
<!ENTITY usecasename    "@@@ Use-Case Name @@@">
<!ENTITY firstname      "@@@ First Name @@@">
<!ENTITY surname        "@@@ Last Name @@@">
<!ENTITY copyrightyear  "@@@ Year @@@">
<!--}}}-->

]>
<!--}}}-->

<!--
The following template is provided for a Use-Case Specification, which contains
the textual properties of the use case. This document is used with a
requirements management tool, such as Rational RequisitePro, for specifying and
marking the requirements within the use-case properties.

The use-case diagrams can be developed in a visual modeling tool, such as
Rational Rose. A use-case report, with all properties, may be generated with
Rational SoDA. For more information, see the tool mentors in the Rational
Unified Process.
-->
<book lang="en"><!-- Use-Case Specification {{{-->

  <!--
  This is the front matter definition of the Use-Case Specification. Most data
  is set through the text entities above. Only the history per revision has to
  be set by hand. See <revhistory> below.
  -->
  <bookinfo><!-- Front Matter {{{-->

    <title>&projectname;</title>
    <subtitle>Use-Case Specification: &usecasename;</subtitle>

    <author>
      <firstname>&firstname;</firstname>
      <surname>&surname;</surname>
    </author>

    <copyright>
      <year>&copyrightyear;</year>
      <holder>&firstname; &surname;</holder>
    </copyright>

    <revhistory>

      <!--
      For each revision a <revision> section has to be added.
      -->
      <revision>
        <revnumber></revnumber>
        <date></date>
        <authorinitials></authorinitials>
        <revremark></revremark>
      </revision>

    </revhistory>

  </bookinfo><!--}}}-->

  <chapter><!-- Use Case Name {{{-->
    <title>&usecasename;</title>

    <para>
    </para>

    <!--
    The description briefly conveys the role and purpose of the use case. A
    single paragraph will suffice for this description.
    -->
    <section><!-- Brief Description {{{-->
      <title>Brief Description</title>

      <para>
      </para>

    </section><!--}}}-->

  </chapter><!--}}}-->

  <chapter><!-- Flow of Events {{{-->
    <title>Flow of Events</title>

    <!--
    This use case starts when the actor does something. An actor always
    initiates use cases. The use case describes what the actor does and what
    the system does in response. It is phrased in the form of a dialog between
    the actor and the system.

    The use case describes what happens inside the system, but not how or why.
    If information is exchanged, be specific about what is passed back and
    forth. For example, it is not very illuminating to say that the actor
    enters customer information. It is better to say the actor enters the
    customer's name and address. A Glossary of Terms is often useful to keep
    the complexity of the use case manageable you may want to define things
    like customer information there to keep the use case from drowning in
    details. 

    Simple alternatives may be presented within the text of the use case. If it
    only takes a few sentences to describe what happens when there is an
    alternative, do it directly within the Flow of Events section. If the
    alternative flow is more complex, use a separate section to describe it.
    For example, an Alternative Flow subsection explains how to describe more
    complex alternatives. 

    A picture is sometimes worth a thousand words, though there is no
    substitute for clean, clear prose. If it improves clarity, feel free to
    paste graphical depictions of user interfaces, process flows or other
    figures into the use case. If a flow chart is useful to present a complex
    decision process, by all means use it!  Similarly for state-dependent
    behavior, a state-transition diagram often clarifies the behavior of a
    system better than pages upon pages of text. Use the right presentation
    medium for your problem, but be wary of using terminology, notations or
    figures that your audience may not understand. Remember that your purpose
    is to clarify, not obscure.
    -->
    <section><!-- Basic Flow {{{-->
      <title>Basic Flow</title>

      <para>
      </para>

    </section><!--}}}-->

    <section><!-- Alternative Flows {{{-->
      <title>Alternative Flows</title>

      <!--
      More complex alternatives are described in a separate section, referred
      to in the Basic Flow subsection of Flow of Events section. Think of the
      Alternative Flow subsections like alternative behavior - each alternative
      flow represents alternative behavior usually due to exceptions that occur
      in the main flow. They may be as long as necessary to describe the events
      associated with the alternative behavior. When an alternative flow ends,
      the events of the main flow of events are resumed unless otherwise
      stated.

      There may be, and most likely will be, a number of alternative flows in a
      use case. Keep each alternative flow separate to improve clarity. Using
      alternative flows improves the readability of the use case, as well as
      preventing use cases from being decomposed into hierarchies of use cases.
      Keep in mind that use cases are just textual descriptions, and their main
      purpose is to document the behavior of a system in a clear, concise, and
      understandable way.

      Add a section for each alternative flow.
      -->
      <section>
        <title>@@@ Alternative Flow @@@</title>

        <para>
        </para>

        <!--
        Alternative flows may, in turn, be divided into subsections if it
        improves clarity.

        Add a section for each alternative subflow.
        -->
        <section>
          <title>@@@ Alternative Subflow @@@</title>

          <para>
          </para>

        </section>

      </section>

    </section><!--}}}-->

  </chapter><!--}}}-->

  <!--
  A special requirement is typically a nonfunctional requirement that is
  specific to a use case, but is not easily or naturally specified in the text
  of the use case's event flow. Examples of special requirements include legal
  and regulatory requirements, application standards, and quality attributes of
  the system to be built including usability, reliability, performance or
  supportability requirements. Additionally, other requirements - such as
  operating systems and environments, compatibility requirements, and design
  constraints should be captured in this section.
  -->
  <chapter><!-- Special Requirements {{{-->
    <title>Special Requirements</title>

    <!--
    Add a section for each special requirement
    -->
    <section>
      <title>@@@ Special Requirement @@@</title>

      <para>
      </para>

    </section>

  </chapter><!--}}}-->

  <!--
  A precondition of a use case is the state of the system that must be present
  prior to a use case being performed.
  -->
  <chapter><!-- Preconditions {{{-->
    <title>Preconditions</title>

    <!--
    Add a section for each precondition.
    -->
    <section>
      <title>@@@ Precondition @@@</title>

      <para>
      </para>

    </section>

  </chapter><!--}}}-->

  <!--
  A postcondition of a use case is a list of possible states the system can be
  in immediately after a use case has finished.
  -->
  <chapter><!-- Postconditions {{{-->
    <title>Postconditions</title>

    <!--
    Add a section for each postcondition.
    -->
    <section>
      <title>@@@ Postcondition @@@</title>

      <para>
      </para>

    </section>

  </chapter><!--}}}-->

  <!--
  Extension points of the use case.
  -->
  <chapter><!-- Extension Points {{{-->
    <title>Extension Points</title>

    <!--
    Definition of the location of the extension point in the flow of events.
    -->
    <section>
      <title>@@@ Name of Extension Point @@@</title>

      <para>
      </para>

    </section>

  </chapter>

</book><!--}}}-->

<!-- vim: set ts=2 sw=2 fo+=t et ff=unix filetype=docbkxml fdm=marker: -->

