eCommerce Planning Phase

eCommerce Disposable Prototypes – A key control artifact in conveying application behavior to the client is to use a Disposable Prototype. Quickly developed to minimize development investment, a disposable prototype shows the client exactly how the application should behave and conveys that knowledge much better than specification documents. These two control artifacts should be used in concert.

eCommerce Business Requirements Document – This document is a high-level functional requirements document that conveys how the solution application should behave. This document is higher level and less specific than a Functional Specification, and it 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.

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

eCommerce Functional Specification – The eCommerce 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 three 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.

eCommerce Technical Specification – The eCommerce 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. A system diagram is typically provided in this document to illustrate the high-level application architecture.

eCommerce Project Schedule – The eCommerce 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. It is used by Jagged Peak to manage resources and tasks at a project level.

eCommerce Project Plan/Work Estimate – The eCommerce 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.

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

eCommerce Test Plan/Test Case – An eCommerce Test Plan and Test Case provide a systematic approach to Quality Assurance at 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 Delivery/Testing Phase. Bugs will be flushed out and addressed long before the application reaches Production using these control documents.

eCommerce System Documentation – This artifact is typically the technical control document of a project that has already begun or has development versions complete. This control artifact also 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.