Problem Statement Template - DOC

Document Sample
Problem Statement Template - DOC Powered By Docstoc
					General Instructions

   1. Provide a cover page that includes the product name, customer name,
      team name, team member names, and the current date.
   2. Number the pages of the document.
   3. Number and label all figures. Refer to the figures by number in the text.
   4. All sections should have an introductory sentence or two.
   5. Do not use vague words and phrases such as may, might, could, possibly,
      should, assumed to be, some, a little, and a lot. Use strong, definite words
      and phrases such as shall, will, will not, can, and cannot.
   6. Watch your spelling, punctuation, and grammar. It is a reflection on your

Be sure that your document is

      Complete - No information is missing
      Clear - Every sentence's meaning must be clear to all parties
      Consistent – The writing style and notation is consistent throughout the
       document and the document does not contradict itself.
      Verifiable - All facts stated are verifiable

Be sure to use one the acceptable UML IDEs available at AUBG for drawing
UML diagrams: Rational Rose or Aonix Software through Pictures. Screenshots
of these packages in use must be presented.

Requirements Definition Template

The Problem Statement is developed by the project management and the client
as a mutual understanding of the problem to be addressed by the system. The
problem statement describes the current situation, the functionality it should
support, and environment in which the system will be deployed. It also defines
the deliverables expected by the client, together with delivery dates and a set of
acceptance criteria.


The audience for the Problem Statement includes the client, the users, the
project management, and the system analysts (i.e., the developers who
participate in the requirements).


1. Introduction
       1.1 Purpose of the system
       1.2 Scope of the system
       1.3 Objectives and success criteria of the project
       1.4 Definitions, acronyms, and abbreviations
       1.5 References
       1.6 Overview

2. Functional requirements - text

Functional requirements describe the high-level functionality of the system.

3. Nonfunctional requirements - text

Nonfunctional requirements describes user-level requirements that are not
directly related to functionality. This includes usability, reliability, performance,
supportability, implementation, interface, operational, packaging, and legal

       3.1 Usability
       3.2 Reliability
       3.3 Performance
       3.4 Supportability
       3.5 Implementation
       3.6 Interface
       3.7 Packaging
       3.8 Legal

4. Use Case Model (via Scenarios)

UML Use Case diagrams

5. Target environment

6. Deliverables and deadlines