White Paper & Technical Report

1.1 The White Paper
The white paper is an A4 document of no less than 9 pages and no more than 15 pages (10 being an optimal average) that is written for the general public, and that describes what your application does. This should reflect the important points about the system. The white paper is the part that both business and technical people will read to understand the application context, its usage, its main features, and its potential business value. It should cover the following (meant only as guidelines, and your team's project may break this up differently):

The vision (1-2pp): key features and major constraints for the system
The initial business case (2-3pp): existing competition (if any), business context, product impact, measurable business and financial criteria for project success, strategies to commercialize the application, financial plans
The technical details of the application (3-5pp): a very broad, simple, down-to-earth layman-oriented outline of the technologies involved and of the way your product is conceived and how it works (i.e., product requirements and architecture, adopted/needed technologies, limitations. Avoid giving away those critical details that could let someone else exploit your idea.
The future (3-5pp): How you would take the application from a prototype to the real finished product, i.e., what else needs to happen for this prototype to become finished and appear as a product available for purchase by customers.
The white paper needs to be very well written and to present a sensible and coherent idea. It should also include attractive images, and some design flair (e.g. imaginative layout), similar to the types of brochures produced commercially; it is not supposed to be an academic paper! Illustrations should be used both to help explain the product and to make it visually appealing. The white paper should also be comprehensive, it should not omit any of the main parts of the work you have done, and also it must address how the ideas are to be taken forward in the future plan. The future plan should not be restricted to technology, but should also include the financial plan, how to get working capital to start up, etc.





1.2 The Initial Technical Report
The Initial Technical Report is an A4 document of no less than 9 pages and no more than 15 pages (with 10 pages being an optimal average) that reports your initial technical decisions, findings, and analyses. The Initial Technical Report is restricted to the technical audience of the company that develops the software product. As such, it should cover the following (meant only as guidelines, and your team's project may break this up differently):

2-3pp - The critical use case model describes critical functionalities for system acceptance, driving design decisions.
2-3pp - The candidate system architecture describes significant decisions about the software components and their organization.
2-3pp - The Initial risk assessment: identifies, discusses, and prioritizes the most significant obstacles to successful project completion, and how you will mitigate, and/or avoid them.
2-3pp - The initial project plan: describes the sequence in which system functionalities will be specified, designed, and constructed. Includes schedule, milestones, and iterations for each phase.
2-3pp -The proof of concept: software development so far: achievements, problems, lessons learned, things that work as expected, things that will need to be changed and/or redone.


1.3 The Proof of Concept Software (Prototype--Webpage and DB)
The Proof of Concept (PoC) software is an initial, skeletal (and as such inherently incomplete) version of your system that you have developed to demonstrate that your idea is viable and works in practice.