Application development documentation
Application development documentation
Reading Time: 5 minutes

Following are the list of documents which are necessary to prepare for the proper project execution. List of documents may change as per the project methodology or the process you are following and sometimes it depends on the type of project and it’s behaviour.

  • Vision Statement
  • Project Plan
  • Project Effort Estimation
  • Project Objectives, team Roles and responsibilities
  • Requirement Specification Document
  • User Experience Design Document
  • Iteration Plan Document
  • Application Architecture Document
  • Source code document
  • API Documentation
  • Working Papers
  • Change Request/Additional Request Document
  • Project Status Report
  • Quality Assurance Document
  • Release Plan
  • Maintenance and Help Guide
  • Product Admin User Documentation
  • Product End User Documentation

Vision Statement

The vision statement sets the direction for the project by specifying what will be accomplished. It defines the scope of the project. The main elements of a vision statement include:

  • Project goals – Projects start with an idea to solve a problem or take advantage of an opportunity. The goals of the project should align with the problems and opportunities identified. Goals express the expected outcomes from a project. Goals should be SMART: Specific, Measurable, Action-oriented, Realistic, and Timely.
  • Project scope – What is and is not included in the project?
  • High-level features or requirements. Are some features more important than others? One way of prioritizing features is to divide them into two classes: essential and desirable.
  • Major milestones and deliverables.

Here is a convenient template for developing an elevator statement for a product:

  • For (target customer)
  • Who (statement of need or opportunity)
  • The (product name) is a (product category)
  • That (key benefit, compelling reason to buy)
  • Unlike (primary competitive alternative)
  • Our product (statement of primary differentiation)

Example

For computer users of all ages who want to socialize and keep in touch with family, friends and associates, the MultiFace web site is a social networking web site that allows users to maintain multiple personas. Unlike traditional social networking web sites such as Facebook and MySpace, our product allows users to maintain separate and distinct identifies for different groups of family, friends and associates.

A good vision statement helps you make decisions regarding priorities and what to include and exclude.

Project Plan

These documents are usually created before the project starts and can be altered as the product evolves.

Project Effort Estimation

These documents are usually created before the project starts and can be altered as the product evolves.

Project Objectives, team Roles and responsibilities

Roles and responsibilities

information about project participants including a product owner, team members, and stakeholders. These details will clarify responsibilities and communicate the target release goals for each of the team members.

Team goals and objective

Project objective and team goals.

Assumptions

Create a list of technical or business assumptions that the team might have.

Requirement Specification Document

The software requirements specification lists the functional and non functional requirements along with any implementation constrains. The requirements document serves a diverse audience ranging from non-technical clients to programmers. To meet the needs of this diverse group, requirements are commonly expressed at progressive levels of detail. Most requirements documents will include a list of general product features as well as the detailed system behaviour needed to deliver these features. Detailed system behaviour is often expressed with use cases or usage scenarios.

List of functionalities

  • Functionality -1
    • Description
    • Wireframe
    • Mockup (optional)
    • Validations & Actions
    • Questions
  • Functionality-2
    • Description
    • Wireframe
    • Mockup (optional)
    • Validations & Actions
    • Questions
  • Functionality-3
    • Description
    • Wireframe
    • Mockup (optional)
    • Validations & Actions
    • Questions

User Experience Design Document

The UX documentation can be divided into stages. The research stage includes:

  • User personas
  • User scenario
  • Scenario map
  • User story map
  • UX style guide

On the stage of prototyping and designing, a UX designer often works with the deliverables and updates documentation on par with other team members, including product owner, UI designers, and development team. The most common documents produced at these stages are:

  • Site maps
  • User flow schemes or user journey
  • Wireframes
  • Mock-ups
  • Prototypes
  • Usability testing reports

Iteration Plan Document

An iteration plan defines the activities that will be performed during an iteration. There is one per iteration and they specify the detailed tasks for an iteration, and in some cases an assignment of tasks to individuals.

Application Architecture Document

Software architecture design documents include the main architectural decisions which are made by solution architect.

Solution details. Describe the contemplated solution by listing planned services, modules, components, and their importance.

Diagrammatic representation of the solution. Identify the diagrams that need to be created to help understand and communicate the structure and design principles.

Source code document

A source code document is a technical section that explains how the code works. While it’s not necessary, the aspects that have the greatest potential to confuse should be covered. The main users of the source code documents are software engineers.

Source code documents may include but are not limited to the following details:

  • Coding Standards to follow
  • Code comments and documentation
  • HTML generation framework and other frameworks applied
  • Type of data binding
  • Design pattern with examples (e.g. model-view-controller)
  • Security measures
  • Other patterns and principles

API Documentation

This type of documentation should contain the list of all available APIs with specs for each one.

This documentation informs developers how to effectively use and connect to the required APIs.

Working Papers

These documents exist to record engineers’ ideas and thoughts during project implementation. Working papers usually contain some information about an engineer’s code, sketches, and ideas on how to solve technical issues. While they shouldn’t be the major source of information, keeping track of them allows for retrieving highly specific project details if needed.

Change Request/Additional Request Document

This document can be an excel file which shows iteration wise change request and additional requests along with the estimated and actual time spent.

Project Status Report

This document can be an excel file which shows iteration wise budget vs actual hours spent.

Quality Assurance Document

Types of testing:

  • Unit/component testing
  • Integration testing
  • System testing
  • Performance & load testing
  • Production Readiness Testing
  • Black Box Testing
  • User Acceptance testing

There are different types of testing documents or a document should contain:

  • Quality management plan
  • Test strategy
  • Test plan
  • Test case specifications
  • Test checklists

Quality management plan sets the required standard for product quality and describes the methods to achieve this level. 

test strategy describes the software testing approach to achieve testing objectives. This includes information about team structure and resource needs along with what should be prioritized during testing. A test strategy is usually static as the strategy is defined for the entire development scope.

test plan describes what should be tested at a given moment. This document should contain:

  • The list of features to be tested
  • Testing methods
  • Timeframes
  • Roles and responsibilities (e.g. unit tests may be performed either by the QA team or by engineers)

test case specification is a set of detailed actions to verify each feature or functionality of a product.

Test checklist is a list of tests that should be run at a particular time. It represents what tests are completed and how many have failed.

Release Plan

The release plan is a high-level schedule that stretches for the duration of the project. There is one per project and it specifies the timing of iterations and a rough allocation of product features to iterations.

Iteration #1                                                                                mm/dd – mm/dd

Summary: <Brief statement describing what will be accomplished during this iteration.>

Features / Deliverables Estimated Effort Actual Effort
     
     
     
Totals:    

Maintenance and Help Guide

This document should describe known problems with the system and their solutions. It also should represent the dependencies between different parts of the system.

This document contains all the information which are related to maintenance of the project.

Product Admin User Documentation

Usually, administration docs cover installation and updates that help a system administrator with product maintenance.

Product End User Documentation

The documentation created for end-users should explain in the shortest way possible how the software can help solve their problems. Some parts of user documentation, such as tutorials and onboarding, in many large customer-based products are replaced with onboarding training.

The online form of user documentation requires technical writers to be more imaginative. Online end-user documentation should include the following sections:

  • FAQs
  • Video tutorials
  • Embedded assistance
  • Support Portals

If you have any questions or doubts, feel free to comment.

LEAVE A REPLY

Please enter your comment!
Please enter your name here