To document a software project does not only require the systems or architecture documentation. In Software Architecture Documentation we list the four quadrants:

1. Process Documentation
2. Project Documentation
3. System Documentation
4. User Documentation

Here are some more examples on how to use the PDAC1 to provide project relevant information.

Developers may keep journals to track open questions and interesting findings. These journals may be open for all team members to find relevant information on project topics.

Besides the individual journals the team may write a team journal to plan and run iterations or sprints. The Doctypes for Agile Planning provide templates for these communication needs.

Use Doctypes for Teamwork to define checklists, processes, patterns, tools, and rules a team agrees upon. Writing them down makes them accessible for anyone - especially for new team members. Keep these documents short and to the point!

Doctypes for Project Management provides tools to communicate important project information with decisions, risks, open issues, and meeting minutes.

A glossary is helpful for most project and product documentations.

A project library collects relevant information for the project that is typically provided by external resources. These resources include books, website, blogs, or articles. The library is especially helpful to provide information about the domain or technology stack for new team members.

In order to create a glossary the team may need to do some domain crunching. Create a separate space to collect all information relevant for the domain.

Add things you learned about the domain that should be accessible beyond the scope of the current iteration or sprint of your team.

Different stakeholders have different information and communication needs.

Some stakeholder need information for a given topic. In this case the team may create a workspace to collaborate to create the requested document. After the information is delivered the space may be archived.