Throwaway Prototype
The key control artifact in conveying application behavior to the client is the use of a Throwaway Prototype. Why a throwaway prototype? Prototypes are supposed to be coded as quickly and cheaply as possible in order to minimize development investments in dead ends and to ensure that reviewers can still remember why they requested changes to the prototype. Quick, cheap development is not conducive to sustained quality and tends to be more expensive to repair than to simply throw away and rebuild. Our prototypes show the client exactly how the application should behave and convey that knowledge much better than Specification documents. These two control artifacts should be used in concert. This effort assumes 3 revisions of client feedback in the process.

Requirements Document
This document is a high-level functional requirements document that conveys how an application should behave. This document is higher-level and less specific than a Functional Specification and may be used in concert or in place of a Functional Specification. What determines whether a Requirements Document is useful depends on project size, client audience, use of Prototyping efforts and overall objective.

Use Cases / Data Model
If during the Planning Phase, a RUP Process Methodology is identified as the most-appropriate methodology for moving forward, Uses Cases will drive the requirements gathering process. Coupled with a Data Model (ER Diagram) and a prototype, Use Cases will contain and convey the application behavior.

Functional Specification
A Functional Specification document contains the specific application requirements to be developed from an application-behavior perspective. This document contains the functional requirements down to the form, field, business logic, navigation and control level. Coupled with a Technical Specification and a Throwaway Prototype, these 3 control artifacts contain the full set of application product requirements in the Planning Phase necessary to develop a custom application. Supplemental project control documentation or environmental documentation may be chosen to support the project efforts.

Technical Specification
A Technical Specification document contains specific application, platform and environment requirements necessary to support the product or application. This document contains application-specific technical requirements (e.g. The application needs to support 20 concurrent users), hardware requirements, software requirements, licensing requirements, data migration or integration requirements and finally a data model of the supported data structures. As well, a system diagram is typically provided in this document to illustrate the application architecture from a high level.

Project Schedule
A Project Schedule, typically a Microsoft Project Schedule GANTT chart, is the control document used to manage the project from a timeline perspective. This control artifact is project specific, not product specific, and is responsible for controlling whether the project is on time or not. As well, it can be used to manage resources tasks.

Project Plan / Work Breakdown Structure / Estimates Worksheet
A Project Plan is a project, not product, specific control artifact substantiating the reasoning behind project decisions. Things like function priority, scope-time-dollar priority, methodology substantiation, etc. are conveyed in this document. This document coupled with the Project Schedule control the project. The time included also contains the time it takes to staff the project properly and to manage that effort.

Environment Control Document
If a supplemental technical document is required to manage the development, testing and production environments, an Environment Control Document is used. Nearly all issues related application migration through different environments could be addressed and resolved by using this document. You will never hear, "Well this application worked in the Testing Environment, but not in Production”, if this control document is implemented properly.

Test Plan / Test Cases
A Test Plan and Test Cases provide a systematic approach to Quality Assurance and all stages of testing. These control documents should be created in the Planning Phase of a project, (in some cases, based on project timing, these deliverables will be created in the Development Phase), and then executed during the initial Stabilization/Testing Phase. Bugs will be flushed out and addressed long before the application reaches Production using these control documents.

System Documentation
This artifact is typically the technical control document of a project that has already begun or has development versions complete. As well this control artifact can be used if a full Technical Specification is not feasible from a cost or time perspective. A System Document contains a System Diagram & Overview, a Data model and Technical Requirements like Hardware & Software Requirements, Licensing Requirements and Third-party integration requirements.



Development Phases: Vision | Specification | Development | Stabilization