<?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 Vision Document 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 firstname      "@@@ First Name @@@">
<!ENTITY surname        "@@@ Last Name @@@">
<!ENTITY copyrightyear  "@@@ Year @@@">
<!--}}}-->

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

<!--
The purpose of this document is to collect, analyze, and define high-level
needs and features of the System. It focuses on the capabilities needed by the
stakeholders, and the target users, and why these needs exist.  The details of
how the System fulfills these needs are detailed in the use-case and
supplementary specifications.
-->
<book lang="en"><!-- Vision Document {{{-->

  <!--
  This is the front matter definition of the Vision Document. 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>Vision Document</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><!--}}}-->

  <!--
  The introduction of the Vision document should provide an overview of the
  entire document. It should include the purpose, scope, definitions, acronyms,
  abbreviations, references, and overview of this Vision document.
  -->
  <chapter><!-- Introduction {{{-->
    <title>Introduction</title>

    <!--
    Specify the purpose of this Vision document. A generic purpose description
    has been inserted. Leave it as it is or change it according your needs.
    -->
    <section><!-- Purpose {{{-->
      <title>Purpose</title>

      <para>
        The purpose of this document is to collect, analyze, and define
        high-level needs and features of the &projectname;. It focuses on the
        capabilities needed by the stakeholders, and the target users, and why
        these needs exist. The details of how the &projectname; fulfills these
        needs are detailed in the use-case and supplementary specifications.
      </para>

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

    <!--
    A brief description of the scope of this Vision document; what Project(s)
    it is associated with, and anything else that is affected or influenced by
    this document.
    -->
    <section><!-- Scope {{{-->
      <title>Scope</title>

      <para>
      </para>

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

    <!--
    This section should provide the definitions of all terms, acronyms, and
    abbreviations required to properly interpret the Vision document.  This
    information may be provided by reference to the project Glossary.
    -->
    <section><!-- Definitions, acronyms and abbreviations {{{-->
      <title>Definitions, acronyms and abbreviations</title>

      <para>
      </para>

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

    <!--
    This section should provide a complete list of all documents referenced
    elsewhere in the Vision document.  Each document should be identified by
    title, report number (if applicable), date, and publishing organization.
    Specify the sources from which the references can be obtained. This
    information may be provided by reference to an appendix or to another
    document.
    -->
    <section><!-- References {{{-->
      <title>References</title>

      <para>
      </para>

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

    <!--
    This section should describe what the rest of the Vision document
    contains and explain how the document is organized.
    -->
    <section><!-- Overview {{{-->
      <title>Overview</title>

      <para>
      </para>

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

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

  <!--
  This chapter helps to position the possible product in the marketplace by
  describing where you think its place is in the market, the business
  opportunities and what problems it solves.
  -->
  <chapter><!-- Positioning {{{-->
    <title>Positioning</title>

    <!--
    Briefly describe the business opportunity being met by this project.
    -->
    <section><!-- Business opportunity {{{-->
      <title>Business opportunity</title>

      <para>
      </para>

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

    <!--
    Provide a statement summarizing the problem being solved by this project.
    -->
    <section><!-- Problem statement {{{-->
      <title>Problem statement</title>

      <para>

        <!--
        The following table can be used to summarize the problem. See the
        commented entries.
        -->

        <informaltable>
          <tgroup cols="2">
            <tbody>
              <row>
                <entry>The problem of</entry>
                <entry>
                  <!--
                  Describe the problem
                  -->
                </entry>
              </row>
              <row>
                <entry>affects</entry>
                <entry>
                  <!--
                  The stakeholders affected by the problem
                  -->
                </entry>
              </row>
              <row>
                <entry>the impact of which is</entry>
                <entry>
                  <!--
                  What is the impact of the problem?
                  -->
                </entry>
              </row>
              <row>
                <entry>A successful solution would be</entry>
                <entry>
                  <!--
                  List some key benefits of a successful solution
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>

      </para>

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

    <!--
    A product position statement communicates the intent of the application and
    the importance of the project to all concerned personnel.
    -->
    <section><!-- Product position statement {{{-->
      <title>Product position statement</title>

      <para>

        <!--
        Provide an overall statement summarizing at the highest level, the
        unique position the product intends to fill in the marketplace. The
        following format may be used (see the commented entries):
        -->

        <informaltable>
          <tgroup cols="2">
            <tbody>
              <row>
                <entry>For</entry>
                <entry>
                  <!--
                  Target customer
                  -->
                </entry>
              </row>
              <row>
                <entry>Who</entry>
                <entry>
                  <!--
                  Statement of the need or opportunity
                  -->
                </entry>
              </row>
              <row>
                <entry>The &projectname;</entry>
                <entry>
                  is a
                  <!--
                  Product category
                  -->
                </entry>
              </row>
              <row>
                <entry>That</entry>
                <entry>
                  <!--
                  Statement of key benefit; that is,- compelling reason to buy.
                  -->
                </entry>
              </row>
              <row>
                <entry>Unlike</entry>
                <entry>
                  <!--
                  Primary competitive alternative.
                  -->
                </entry>
              </row>
              <row>
                <entry>Our product</entry>
                <entry>
                  <!--
                  Statement of primary differentiation.
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>

      </para>

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

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

  <!--
  To effectively provide products and services that meet your stakeholders' and
  users' real needs, it is necessary to identify and involve all of the
  stakeholders as part of the Requirements Modeling process. You must also
  identify the users of the system and ensure that the stakeholder community
  adequately represents them. This chapter provides a profile of the
  stakeholders and users involved in the project and the key problems that they
  perceive to be addressed by the proposed solution. It does not describe their
  specific requests or requirements as these are captured in a separate
  stakeholder requests artifact. Instead it provides the background and
  justification for why the requirements are needed.
  -->
  <chapter><!-- Stakeholder and user descriptions {{{-->
    <title>Stakeholder and user descriptions</title>

    <!--
    Summarize the key market demographics that motivate your product decisions.
    Describe and position target market segments. Estimate the market's size
    and growth by using the number of potential users, or the amount of money
    your customers spend trying to meet needs that your product or enhancement
    would fulfill. Review major industry trends and technologies. Answer these
    strategic questions:
      * What is your organization's reputation in these markets?
      * What would you like it to be?
      * How does this product or service support your goals?
    -->
    <section><!-- Market Demographics {{{-->
      <title>Market Demographics</title>

      <para>
      </para>

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

    <!--
    Present a summary list of all the identified stakeholders.
    -->
    <section><!-- Stakeholder summary {{{-->
      <title>Stakeholder summary</title>

      <para>

        <!--
        Just add more rows to the table if necessary.
        -->

        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Name</entry>
                <entry>Represents</entry>
                <entry>Role</entry>
              </row>
            </thead>
            <tbody>
              <row>
                <entry>
                  <!--
                  Name the stakeholder type
                  -->
                </entry>
                <entry>
                  <!--
                  Briefly describe what they represent with respect to the
                  development.
                  -->
                </entry>
                <entry>
                  <!--
                  Briefly describe the role they are playing in the
                  development.For example, Ensure this... .
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </para>

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

    <!--
    Present a summary list of all the identified users.
    -->
    <section><!-- User summary {{{-->
      <title>User summary</title>

      <para>

        <!--
        Just add more rows to the table if necessary.
        -->

        <informaltable>
          <tgroup cols="3">
            <thead>
              <row>
                <entry>Name</entry>
                <entry>Description</entry>
                <entry>Stakeholder</entry>
              </row>
            </thead>
            <tbody>
              <row>
                <entry>
                  <!--
                  Name the user type
                  -->
                </entry>
                <entry>
                  <!--
                  Briefly describe what they represent with respect to the
                  system.
                  -->
                </entry>
                <entry>
                  <!--
                  List how the user is represented by the stakeholders.For
                  example, Represented by Stakeholder 1.1
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </para>

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

    <!--
    Detail the working environment of the target user. Here are some
    suggestions:
      * Number of people involved in completing the task? Is this changing?
      * How long is a task cycle? Amount of time spent in each activity? Is
        this changing?
      * Any unique environmental constraints: mobile, outdoors, in-flight,
        etc.?
      * Which systems platforms are in use today? Future platforms?
      * What other applications are in use? Does your application need to
        integrate with them?
    This is where extracts from the Business Model could be included to outline
    the task and workers involved etc.
    -->
    <section><!-- User environment {{{-->
      <title>User environment</title>

      <para>
      </para>

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

    <!--
    Describe each stakeholder in the system here by filling in the following
    table for each stakeholder. Remember stakeholder types can be as divergent
    as users, strategy departments and technical developers. A thorough profile
    should cover the following topics for each type of stakeholder.
    -->
    <section><!-- Stakeholder profiles {{{-->
      <title>Stakeholder profiles</title>

      <para>
      </para>


      <!--
      Add a new section for each stakeholder.
      -->
      <section>
        <!--
        Replace the '@@@'s and the text in between with the name of the
        stakeholder.
        -->
        <title>@@@ Stakeholder name @@@</title>

        <para>
          <informaltable>
            <tgroup cols="2">
              <tbody>
                <row>
                  <entry>Representative</entry>
                  <entry>
                    <!--
                    Who is the stakeholder representative to the project?
                    (optional if documented elsewhere). What we want here is
                    names.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Description</entry>
                  <entry>
                    <!--
                    Brief description of the stakeholder type.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Type</entry>
                  <entry>
                    <!--
                    Qualify the stakeholder's expertise, technical background,
                    and degree of sophistication that is, guru, business,
                    expert, casual user, etc.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Responsibilities</entry>
                  <entry>
                    <!--
                    List the stakeholder's key responsibilities with regards to
                    the system being developed that is, their interest as a
                    stakeholder.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Success Criteria</entry>
                  <entry>
                    <!--
                    How does the stakeholder define success? How is the
                    stakeholder rewarded?
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Involvement</entry>
                  <entry>
                    <!--
                    How the stakeholder is involved in the project? Relate
                    where possible to RUP workers that is, Requirements
                    Reviewer etc.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Deliverables</entry>
                  <entry>
                    <!--
                    Are there any additional deliverables required by the
                    stakeholder?  These could be project deliverables or
                    outputs from the system under development.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Comments / Issues</entry>
                  <entry>
                    <!--
                    Problems that interfere with success and any other relevant
                    information go here.
                    -->
                  </entry>
                </row>
              </tbody>
            </tgroup>
          </informaltable>
        </para>

      </section>

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

    <!--
    Describe each unique user of the system here by filling in the following
    table for each user type. Remember user types can be as divergent as gurus
    and novices. For example, a guru might need a sophisticated, flexible tool
    with cross-platform support, while a novice might need a tool that is easy
    to use and user-friendly. A thorough profile should cover the following
    topics for each type of user (add a new section for each profile):
    -->
    <section><!-- User profiles {{{-->
      <title>User profiles</title>

      <para>
      </para>

      <!--
      Add a new section for each user.
      -->
      <section>
        <!--
        Replace the '@@@'s and the text in between with the name of the user.
        -->
        <title>@@@User name@@@</title>

        <para>
          <informaltable>
            <tgroup cols="2">
              <tbody>
                <row>
                  <entry>Representative</entry>
                  <entry>
                    <!--
                    Who is the user representative to the project?  (optional
                    if documented elsewhere). This often refers to the
                    Stakeholder that represents the set of users, for example,
                    Stakeholder: Stakeholder1.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Description</entry>
                  <entry>
                    <!--
                    A brief description of the user type.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Type</entry>
                  <entry>
                    <!--
                    Qualify the user's expertise, technical background, and
                    degree of sophistication - that is, guru, casual user, etc.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Responsibilities</entry>
                  <entry>
                    <!--
                    List the user's key responsibilities with regards to the
                    system being developed - that is, captures details,
                    produces reports, coordinates work, etc.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Success Criteria</entry>
                  <entry>
                    <!--
                    How does the user define success? How is the user rewarded?
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Involvement</entry>
                  <entry>
                    <!--
                    How the user is involved in the project? Relate where
                    possible to RUP workers - that is, Requirements Reviewer,
                    etc.
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Deliverables</entry>
                  <entry>
                    <!--
                    Are there any deliverables the user produces and, if so,
                    for whom?
                    -->
                  </entry>
                </row>
                <row>
                  <entry>Comments / Issues</entry>
                  <entry>
                    <!--
                    Problems that interfere with success and any other relevant
                    information go here. These would include trends that make
                    the user's job easier or harder.
                    -->
                  </entry>
                </row>
              </tbody>
            </tgroup>
          </informaltable>
        </para>

      </section>

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

    <!--
    List the key problems with existing solutions as perceived by the
    stakeholder. Clarify the following issues for each problem:
      * What are the reasons for this problem?
      * How is it solved now?
      * What solutions does the stakeholder want?]
    It is important to understand the relative importance the stakeholder or
    user places on solving each problem. Ranking and cumulative voting
    techniques indicate problems that must be solved versus issues they would
    like addressed.
    -->
    <section><!-- Key stakeholder / User Needs {{{-->
      <title>Key Stakeholder / User Needs</title>

      <para>

        <!--
        Fill in the following table - if using ReqPro to capture the Needs, this
        could be an extract or report from that tool. Add more rows when necessary.
        -->
        <informaltable>
          <tgroup cols="5">
            <thead>
              <row>
                <entry>Need</entry>
                <entry>Priority</entry>
                <entry>Concerns</entry>
                <entry>Current Solution</entry>
                <entry>Proposed Solution</entry>
              </row>
            </thead>
            <tbody>
              <row>
                <entry>
                </entry>
                <entry>
                </entry>
                <entry>
                </entry>
                <entry>
                </entry>
                <entry>
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>
      </para>

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

    <!--
    Identify alternatives the stakeholder perceives as available. These can
    include buying a competitors' product, building a homegrown solution or
    simply maintaining the status quo. List any known competitive choices that
    exist, or may become available. Include the major strengths and weaknesses
    of each competitor as perceived by the stakeholder.
    -->
    <section><!-- Alternatives and competition {{{-->
      <title>Alternatives and competition</title>

      <para>
      </para>

      <!--
      Add a new section for each competitor.
      -->
      <section>
        <!--
        Replace the '@@@'s and the text in between with the name of the
        competitor.
        -->
        <title>@@@ Competitor @@@</title>

        <para>
          <!-- Description here. See above. -->
        </para>

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

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

  <!--
  This chapter provides a high level view of the product capabilities,
  interfaces to other applications, and systems configurations. This section
  usually consists of three subsections, as follows:
    * Product perspective
    * Product functions
    * Assumptions and dependencies
  -->
  <chapter><!-- Product overview {{{-->
    <title>Product overview</title>

    <!--
    This section of the Vision document should put the product in perspective
    to other related products and the user's environment. If the product is
    independent and totally self-contained, state it here. If the product is a
    component of a larger system, then this subsection should relate how these
    systems interact and should identify the relevant interfaces between the
    systems. One easy way to display the major components of the larger system,
    interconnections, and external interfaces is via a block diagram.
    -->
    <section><!-- Product perspective {{{-->
      <title>Product perspective</title>

      <para>
      </para>

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

    <!--
    Summarize the major benefits and features the product will provide. For
    example, a Vision document for a customer support system may use this part
    to address problem documentation, routing, and status reporting without
    mentioning the amount of detail each of these functions requires.  Organize
    the functions so the list is understandable to the customer or to anyone
    else reading the document for the first time.
    -->
    <section><!-- Summary of capabilities {{{-->
      <title>Summary of capabilities</title>

      <para>
        <!--
        A simple table listing the key benefits and their supporting features
        might suffice (see below). Add new rows for each benefit/feature pair.
        -->
        <informaltable>
          <tgroup cols="2">
            <thead>
              <row>
                <entry>Customer Benefit</entry>
                <entry>Supporting Features</entry>
              </row>
            </thead>
            <tbody>
              <row>
                <entry>
                  <!--
                  E.g.: Distributed support teams can work together to solve
                  problems.
                  -->
                </entry>
                <entry>
                  <!--
                  Replication server allows current database information to be
                  shared across the enterprise.
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>

      </para>

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

    <!--
    List each of the factors that affects the features stated in the Vision
    document. List assumptions that, if changed, will alter the Vision
    document. For example, an assumption may state that a specific operating
    system will be available for the hardware designated for the software
    product. If the operating system is not available, the Vision document will
    need to change.
    -->
    <section><!-- Assumptions and dependencies {{{-->
      <title>Assumptions and dependencies</title>

      <para>
      </para>

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

    <!--
    For products sold to external customers and for many in- house
    applications, cost and pricing issues can directly impact the applications
    definition and implementation. In this section, record any cost and pricing
    constraints that are relevant. For example, distribution costs, (# of
    diskettes, # CD-ROMs, CD mastering) or other cost of goods sold constraints
    (manuals, packaging) may be material to the projects success, or
    irrelevant, depending on the nature of the application.
    -->
    <section><!-- Cost and pricing {{{-->
      <title>Cost and pricing</title>

      <para>
      </para>

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

    <!--
    Licensing and installation issues can also directly impact the development
    effort. For example, the need to support serializing, password security or
    network licensing will create additional requirements of the system that
    must be considered in the development effort.
    Installation requirements may also affect coding, or create the need for
    separate installation software.
    -->
    <section><!-- Licensing and installation {{{-->
      <title>Licensing and installation</title>

      <para>
      </para>

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

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

  <!--
  List and briefly describe the product features. Features are the high-level
  capabilities of the system that are necessary to deliver benefits to the
  users. Each feature is an externally desired service that typically requires
  a series of inputs to achieve the desired result. For example, a feature of a
  problem tracking system might be the ability to provide trending reports. As
  the use-case model takes shape, update the description to refer to the use
  cases.

  Because the Vision document is reviewed by a wide variety of involved
  personnel, the level of detail should be general enough for everyone to
  understand. However, enough detail should be available to provide the team
  with the information they need to create a use-case model.

  To effectively manage application complexity, we recommend for any new
  system, or an increment to an existing system, capabilities are abstracted to
  a high enough level so 25-99 features result. These features provide the
  fundamental basis for product definition, scope management, and project
  management. Each feature will be expanded in greater detail in the use-case
  model.

  Throughout this chapter, each feature should be externally perceivable by
  users, operators or other external systems. These features should include a
  description of functionality and any relevant usability issues that must be
  addressed. The following guidelines apply:
    *	Avoid design. Keep feature descriptions at a general level. Focus on
      capabilities needed and why, (not how) they should be implemented.
    * If you are using the Requisite toolkit, all should be selected as
      requirements of type for easy reference and tracking.
  -->
  <chapter><!-- Product Features {{{-->
    <title>Product Features</title>

    <!--
    Add a new section for each feature.
    -->
    <section>
      <!--
      Replace the '@@@'s and the text in between with the name of the feature.
      -->
      <title>@@@ Feature @@@</title>

      <para>
      </para>

    </section>

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

  <!--
  Note any design constraints, external constraints or other dependencies.
  -->
  <chapter><!-- Constraints {{{-->
    <title>Constraints</title>

    <para>
    </para>

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

  <!--
  Define the quality ranges for performance, robustness, fault tolerance,
  usability, and similar characteristics that are not captured in the Feature
  Set.
  -->
  <chapter><!-- Quality ranged {{{-->
    <title>Quality ranges</title>

    <para>
    </para>

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

  <!--
  Define the priority of the different system features.
  -->
  <chapter><!-- Precedence and priority {{{-->
    <title>Precedence and priority</title>

    <para>
    </para>

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

  <!--
  At a high-level, list applicable standards, hardware or platform
  requirements, performance requirements, and environmental requirements.
  -->
  <chapter><!-- Other product requirements {{{-->
    <title>Other product requirements</title>

    <!--
    List all standards with which the product must comply. These can include
    legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN),
    platform compliance standards (Windows, Unix, etc.), and quality and safety
    standards (UL, ISO, CMM).
    -->
    <section><!-- Applicable standards {{{-->
      <title>Applicable standards</title>

      <para>
      </para>

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

    <!--
    Define any system requirements necessary to support the application.  These
    can include the supported host operating systems and network platforms,
    configurations, memory, peripherals, and companion software.
    -->
    <section><!-- System requirements {{{-->
      <title>System requirements</title>

      <para>
      </para>

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

    <!--
    Use this section to detail performance requirements. Performance issues can
    include such items as user load factors, bandwidth or communication
    capacity, throughput, accuracy, and reliability or response times under a
    variety of loading conditions.
    -->
    <section><!-- Performance requirements {{{-->
      <title>Performance requirements</title>

      <para>
      </para>

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

    <!--
    Detail environmental requirements as needed. For hardware- based systems,
    environmental issues can include temperature, shock, humidity, radiation,
    etc. For software applications, environmental factors can include usage
    conditions, user environment, resource availability, maintenance issues,
    and error handling, and recovery.
    -->
    <section><!-- Environmental requirements {{{-->
      <title>Environmental requirements</title>

      <para>
      </para>

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

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

  <!--
  This chapter describes the documentation that must be developed to support
  successful application deployment.
  -->
  <chapter><!-- Documentation Requirements {{{-->
    <title>Documentation Requirements</title>

    <!--
    Describe the purpose and contents of the User Manual. Discuss desired
    length, level of detail, need for index, glossary of terms, tutorial vs.
    reference manual strategy, etc. Formatting and printing constraints
    should also be identified.
    -->
    <section><!-- User Manual {{{-->
      <title>User Manual</title>

      <para>
      </para>

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

    <!--
    Many applications provide an on-line help system to assist the user. The
    nature of these systems is unique to application development as they
    combine aspects of programming (hyperlinks, etc) with aspects of technical
    writing (organization, presentation). Many have found the development of
    on-line help system is a project within a project that benefits from
    up-front scope management and planning activity.
    -->
    <section><!-- Online Help {{{-->
      <title>Online Help</title>

      <para>
      </para>

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

    <!--
    A document that includes installation instructions and configuration
    guidelines is important to a full solution offering. Also, a Read Me file
    is typically included as a standard component. The Read Me can include a
    "What's New With This Release" section, and a discussion of compatibility
    issues with earlier releases. Most users also appreciate documentation
    defining any known bugs and workarounds in the Read Me file.
    -->
    <section><!-- Installation Guides, Configuration, Read Me File {{{-->
      <title>Installation Guides, Configuration, Read Me File</title>

      <para>
      </para>

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

    <!--
    Today's state of the art applications provide a consistent look and feel
    that begins with product packaging and manifests through installation
    menus, splash screens, help systems, GUI dialogs, etc. This section defines
    the needs and types of labeling to be incorporated into the code.  Examples
    include copyright and patent notices, corporate logos, standardized icons
    and other graphic elements, etc.
    -->
    <section><!-- Labeling and Packaging {{{-->
      <title>Labeling and Packaging</title>

      <para>
      </para>

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

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

  <!--
  Features should be given attributes that can be used to evaluate, track,
  prioritize, and manage the product items proposed for implementation. All
  requirement types and attributes should be outlined in the Requirements
  Management Plan, however you may wish to list and briefly describes the
  attributes for features that have been chosen. Following sections represent a
  set of suggested feature attributes.
  -->
  <appendix><!-- Features Attributes {{{-->
    <title>Feature Attributes</title>

    <!--
    Set after negotiation and review by the project management team. Tracks
    progress during definition of the project baseline.
    -->
    <section><!-- Status {{{-->
      <title>Status</title>

      <para>

        <!--
        The following table can be used to report the status.
        -->
        <informaltable>
          <tgroup cols="2">
            <tbody>
              <row>
                <entry>Proposed</entry>
                <entry>
                  <!--
                  Used to describe features that are under discussion but have
                  not yet been reviewed and accepted by the "official channel",
                  such as a working group consisting of representatives from
                  the project team, product management and user or customer
                  community.
                  -->
                </entry>
              </row>
              <row>
                <entry>Approved</entry>
                <entry>
                  <!--
                  Capabilities that are deemed useful and feasible and have
                  been approved for implementation by the official channel.
                  -->
                </entry>
              </row>
              <row>
                <entry>Incorporated</entry>
                <entry>
                  <!--
                  Features incorporated into the product baseline at a specific
                  point in time.
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>

      </para>

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

    <!--
    Set by Marketing, the product manager or the business analyst. All
    requirements are not created equal. Ranking requirements by their relative
    benefit to the end user opens a dialog with customers, analysts and members
    of the development team. Used in managing scope and determining development
    priority.
    -->
    <section><!-- Benefit {{{-->
      <title>Benefit</title>

      <para>

        <informaltable>
          <tgroup cols="2">
            <tbody>
              <row>
                <entry>Critical</entry>
                <entry>
                  <!--
                  Essential features. Failure to implement means the system
                  will not meet customer needs. All critical features must be
                  implemented in the release or the schedule will slip.
                  -->
                </entry>
              </row>
              <row>
                <entry>Important</entry>
                <entry>
                  <!--
                  Features important to the effectiveness and efficiency of the
                  system for most applications. The functionality cannot be
                  easily provided in some other way. Lack of inclusion of an
                  important feature may affect customer or user satisfaction,
                  or even revenue, but release will not be delayed due to lack
                  of any important feature.
                  -->
                </entry>
              </row>
              <row>
                <entry>Useful</entry>
                <entry>
                  <!--
                  Features that are useful in less typical applications, will
                  be used less frequently, or for which reasonably efficient
                  workarounds can be achieved. No significant revenue or
                  customer satisfaction impact can be expected if such an item
                  is not included in a release.
                  -->
                </entry>
              </row>
            </tbody>
          </tgroup>
        </informaltable>

      </para>

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

    <!--
    Set by the development team. Because some features require more time and
    resources than others, estimating the number of team or person-weeks, lines
    of code required or function points, for example, is the best way to gauge
    complexity and set expectations of what can and cannot be accomplished in a
    given time frame. Used in managing scope and determining development
    priority.
    -->
    <section><!-- Effort {{{-->
      <title>Effort</title>

      <para>
      </para>

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

    <!--
    Set by development team based on the probability the project will
    experience undesirable events, such as cost overruns, schedule delays or
    even cancellation. Most project managers find categorizing risks as high,
    medium, and low sufficient, although finer gradations are possible. Risk
    can often be assessed indirectly by measuring the uncertainty (range) of
    the projects teams schedule estimate.
    -->
    <section><!-- Risk {{{-->
      <title>Risk</title>

      <para>
      </para>

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

    <!--
    Set by analyst and development team based on the probability the feature
    will change or the team's understanding of the feature will change. Used to
    help establish development priorities and determine those items for which
    additional elicitation is the appropriate next action.
    -->
    <section><!-- Stability {{{-->
      <title>Stability</title>

      <para>
      </para>

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

    <!--
    Records the intended product version in which the feature will first
    appear. This field can be used to allocate features from a Vision document
    into a particular baseline release. When combined with the status field,
    your team can propose, record and discuss various features of the release
    without committing them to development. Only features whose Status is set
    to Incorporated and whose Target Release is defined will be implemented.
    When scope management occurs, the Target Release Version Number can be
    increased so the item will remain in the Vision document but will be
    scheduled for a later release.
    -->
    <section><!-- Target Release {{{-->
      <title>Target Release</title>

      <para>
      </para>

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

    <!--
    In many projects, features will be assigned to "feature teams" responsible
    for further elicitation, writing the software requirements and
    implementation. This simple pull down list will help everyone on the
    project team better understand responsibilities.
    -->
    <section><!-- Assigned To {{{-->
      <title>Assigned To</title>

      <para>
      </para>

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

    <!--
    This text field is used to track the source of the requested feature.
    Requirements exist for specific reasons. This field records an explanation
    or a reference to an explanation. For example, the reference might be to a
    page and line number of a product requirement specification, or to a minute
    marker on a video of an important customer interview.
    -->
    <section><!-- Reason {{{-->
      <title>Reason</title>

      <para>
      </para>

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

  </appendix><!--}}}-->

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

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

