Project Documentation
Project documentation is one of the most important instruments to guarantee a smooth project execution. Since Specific-Group’s project handling takes place cross-border, proper documentation is particularly important to us.
The communication between our project managers and development team is done in English. Needless to say, we can provide our customers with all documents in German as well.
The following list provides a brief description of the key documents that are created throughout the project.
Software Requirements Document
The software requirements document describes the current situation of the business environment from the customer’s point of view as well as the desired results. Therefore, this document is usually written by the customer, but our project managers will gladly assist, if required. In most cases we will extend the software requirements document with internally relevant information.
Functional Specification
The further development of the software requirements document results in the functional specification. The functional specification contains the software requirements from the customer’s point of view as well as technical details for the implementation – ergo, a precise, technical requirements description for a systematic and successful development process.
SOW / Statement of Work
The SOW is prepared at the start of the project. It contains relevant information on the project execution:
- A list of the documents that serve as the basis for project implementation
- A list of project team members, their functions and range of activities (from both the customer’s side and Specific-Group’s)
- Communication arrangement within the project (how communication occurs and who communicates with whom)
- A description of the required infrastructure for project implementation (hardware & software, access to the customer’s system, if required)
- A description of the project’s potential risks
- A schedule of project meetings (optional)
- Overview of deadlines (e.g. milestones)
- A rough overview of quality parameters
- A schedule for the delivery of releases
- A description of how change requests are to be handled
- The criteria for the software to go live
- Definition of the process for approval
Ongoing Documentation
Ongoing documentation includes:
1. Release Notes: Describes the individual updates, builds, releases or versions of a program and its extensions. The release notes are created by the developers and include a list of software components, bug fixes and change requests, along with information about whether or not they were implemented in that respective release.
2. Database Model: All changes to the databases must be recorded. The developers implement the necessary adjustments.
3. Minutes: After each meeting with the customer, the project manager writes the minutes. The objective is the transparent presentation of project information and the distribution to everybody involved in the project.
4. Product Backlog: The product backlog contains the project tasks (stories) of the product to be developed. It includes a list of all the functionalities that the customer wants, plus technical dependencies. Before each implementation of 1-n stories within a predefined time frame (sprint), the product backlog elements are re-evaluated and prioritized.
5. Sprint Backlog: The sprint backlog contains all project tasks (stories) that are necessary to fulfill the goal of the sprint. Here, project tasks are subdivided into so-called issues.
6. Team Backlog: In the team backlog, the project master records team-related tasks and remarks. These tasks are recorded during the review meeting and the retrospective and dealt with in the course of the next project-planning meeting. Team backlog entries are not contingent upon the story and are purely team-related.
7. Impediment Backlog: All project impediments that are not team-related are entered into the impediment backlog.