Direct answer: A global software project should maintain a business and requirements brief, user journeys, scope and acceptance criteria, architecture, API and data documentation, environment configuration, test plans, deployment and rollback procedures, an operations runbook and knowledge-transfer records. Documentation should evolve with the product rather than being reconstructed at the end.
Published 10 August 2026 · Reviewed by Guangzhou Tunda Software Co., Ltd.
Why documentation is part of delivery
Meetings are useful for discussion but cannot replace traceable decisions. When client, product, engineering and QA teams work across countries, English documentation standardises terminology, confirms boundaries, records reasoning and supports handover. A system should remain understandable through its code, configuration and records when people change.
Discovery and planning documents
- Project brief: business context, users, markets, problems and success criteria.
- Scope statement: what the first phase includes, excludes and still needs confirmation.
- User roles and journeys: permissions, primary flows and exceptions.
- Acceptance criteria: observable conditions for accepting each capability.
- Decision log: important choices, rationale, owners and effective dates.
Design and engineering documents
- System architecture: boundaries, modules, data flows, external dependencies and deployment relationships.
- API documentation: authentication, endpoints, parameters, examples, errors, permissions, rate limits and versions.
- Data dictionary: entities, field meanings, relationships, sensitivity and retention.
- Environment guide: local, test, staging and production configuration differences.
- Engineering rules: branching, commits, automated checks, review and merge requirements.
Integration-heavy projects can use the OpenAPI Specification so documentation, tests and client integrations share a common HTTP API definition.
Testing and release documents
- Test plan: scope, environments, data, ownership and entry or exit criteria.
- Release checklist: versions, configuration, database changes, dependencies and approvals.
- Deployment guide: sequence, secret handling, health checks and verification.
- Rollback plan: how application, configuration and data are restored.
- Known issues: limitations, workarounds and planned remediation.
Production and handover documents
- Operations runbook: monitoring, alerts, logs, backup and common recovery steps.
- Incident record: timeline, impact, root cause, repair and prevention.
- Access register: accounts, permission scope, owners and revocation—without plain-text passwords.
- Handover checklist: repositories, cloud accounts, certificates, domains, stores and contacts.
- Change log: features, fixes, configuration and compatibility changes by release.
A minimum viable document set
When time or budget is limited, maintain at least seven areas: requirements and acceptance, architecture overview, APIs, environments and deployment, test evidence, release and rollback, and account handover. Store documents in version control or a shared knowledge base and connect them to the releases they describe.
Tunda Software's English delivery capability
Tunda Software conducts product and technical collaboration in English and can deliver agreed English requirements, API, testing, deployment and operational materials. For existing-system handover, the team can first map the system and close documentation gaps before continuing development. Learn about our offshore development team service.
Frequently asked questions
Must every document be completed before development starts?
No. Documentation should evolve through discovery, design, development, testing and release, with clear owners and update points.
What should English API documentation contain?
At minimum: authentication, endpoints, parameters, request and response examples, errors, permissions, rate limits, versions and test environments.
Who should maintain technical documentation?
Each document needs an owner. Technical leadership maintains consistency while developers and testers update affected material when changes occur.