# Dev Teams and their Docs. ## Abstract. Project documentation serves as the single source of truth, ensuring that all team members and stakeholders are aligned throughout the Project Lifecycle. This post covers the Software Development Documents and the Software Development Teams. * * * ## An Introduction. I rely on structured, application specification documents to communicate clearly, reduce ambiguity, and ensure project continuity. The work splits into three layers: the **Software Development Documents** (the what), the **Software Development Teams** (the who), and the **Specification Process** (the how). By covering all three layers, I get a complete reference for the Client, who are the company, the stakeholders, and the target users. * * * ## The Big Picture. Effective documentation is more than a collection of files; they are strategic assets. These documents are comprehensive roadmaps, written through iterative refinements, ensuring that the final docs are technically robust, strategically aligned with business objectives, and delivers genuine value to the Client. The Leadership Team owns the Software Development Documents, and the Developer Team executes against them — but both teams work in concert because the documents mean nothing without the final deliverable — the software — they describe. * * * ## Prerequisites. Before I engage with the software development documents, I need: 1. A clear **Creation Goal** for the software under development, 2. An **Engineering Team** — This includes the Leadership Team and the Developer Team, 3. Familiarity with all seven **Software Development Documents** — Business Modelling Document, Business Requirements Document, Product Requirements Document, Context Requirements Document, User Experience Document, User Interface Document, and Software Specifications Document, 4. An understanding of the **Software Development Process** that the team follows, from concept to completion, and 5. A Client profile — The company, stakeholders, and users. * * * ## Updating my Base System. From the terminal, I update my system: ```bash sudo apt clean && \ sudo apt update && \ sudo apt dist-upgrade -y && \ sudo apt --fix-broken install && \ sudo apt autoclean && \ sudo apt autoremove -y ``` * * * ## Section 1: The Software Development Documents Project documentation serves as the single source of truth during development, ensuring that all team members and the Client are aligned throughout the Project Lifecycle. There are seven Software Development Documents, each with a distinct author, purpose, and outcome. The Leadership Team creates these Software Development Documents, and the Developer Team uses them as their definitive guides during implementation. ### Business Modelling Document The Business Modelling Document is primarily authored by the Systems Analyst and Business Analyst to provide a visual representation of the business processes and organisational structures that the software is intended to support. By mapping out these workflows, the Business Modelling Document ensures that the technical solution aligns with real-world operations. Key outcomes of this phase include: * Detailed process flow diagrams, * Organisational charts, and * Business domain models. These artifacts serve as a critical reference for the Leadership Team to ensure strategic alignment with the Client, and for developers to gain the necessary business context before diving into technical implementation. * **Author(s):** Systems Analyst, Business Analyst * **Purpose:** To visualise the business processes and organisational structures the software will support * **Outcomes:** Process flow diagrams, organisational charts, and business domain models * **Parties Responsible:** Leadership Team (for alignment) and Developer Team (for context) ### Business Requirements Document Authored by the Systems Analyst, the Business Requirements Document defines the high-level business goals and the essential outcomes the solution must achieve to be considered successful. It focuses on the "what" rather than the "how," outlining: * Business requirements, * Success criteria, and * Project constraints. The Business Requirements Document acts as a foundational agreement between the Project Manager, who uses it to define project scope, and the Client, who provides formal approval to ensure their business needs are accurately captured. * **Author(s):** Systems Analyst * **Purpose:** To define the high-level business goals and essential outcomes the solution must achieve * **Outcomes:** Business requirements, success criteria, and project constraints * **Parties Responsible:** Project Manager (for scope) and Client (for approval) ### Product Requirements Document The Product Requirements Document is developed by the Project Manager to detail the specific features and functionality required in the final product. It bridges the gap between high-level business goals and technical execution by providing: * Feature lists, * User stories, and * Functional requirements. This document is the primary guide for the Developer Team during implementation and serves as the benchmark for the QA Team to verify that the software meets all specified functional criteria. * **Author(s):** Project Manager * **Purpose:** To detail the specific features and functionality required in the final product * **Outcomes:** Feature lists, user stories, and functional requirements * **Parties Responsible:** Developer Team (for implementation) and QA Team (for testing) ### Context Requirements Document The Context Requirements Document is a collaborative effort between the Systems Analyst and Systems Architect designed to define * The system's environment, * External interfaces, and * Boundaries. It provides a clear picture of how the software interacts with other systems and data sources through data flow diagrams and external system interface specifications. This documentation is vital for the Systems Architect and the Full Stack Developers to ensure seamless connectivity and data integrity across the broader technical ecosystem. * **Author(s):** Systems Analyst, Systems Architect * **Purpose:** To define the system's environment, external interfaces, and boundaries * **Outcomes:** Data flow diagrams and external system interface specifications * **Parties Responsible:** Systems Architect and Full Stack Developers ### User Experience Design The User Experience Design encompasses the overall experience a user has with a product, including: * Usability, * Accessibility, and * Satisfaction. It considers all aspects of the user's interaction with the product. User Experience Design involves research and testing to understand user needs, while focusing on the holistic user experience. The user experience is focused on the encounter being a transformative event. The primary outcomes include improved usability, usefulness, and desirability of a product. These outcomes are achieved through research, testing, and iterative User Experience Design processes that focus on the user's needs and interactions. A successful User Experience Design provides usable, enjoyable, and accessible products that enhances the overall user experience and satisfaction. The focus is on understanding the user needs and creating User Experience Designs that are intuitive and effective. This leads to User Interface Designs that apply these understandings as creative, functional, and visually appealing opportunities to develop a relationship with the user. * **Author(s):** UI/UX Designer * **Purpose:** To define the overall user experience, usability, and accessibility of the product * **Outcomes:** Research findings, usability testing results, and experience design specifications * **Parties Responsible:** UI/UX Designer and Front-End Developers (for building) ### User Interface Design The User Interface Design focuses on the visual elements and interactivity of a product, such as layout, colours, and buttons. It aims to create an engaging, and aesthetically pleasing, User Interface Designs. Effective UI Design contributes significantly to a positive user experience. A well-executed User Interface Design can enhance user satisfaction and engagement, making it easier for users to achieve their goals, while also enhancing the visual and interactive aspects of the product. The User Interface Design defines the visual language and design, wireframe layout, and interaction patterns of the product. The primary outcomes include wireframes, high-fidelity mock-ups, and interactive prototypes. This design provides a blueprint for front-end developers to build the user interface, and for the QA team to validate the user experience against the intended design standards. * **Author(s):** UI/UX Designer * **Purpose:** To define the visual language, wireframe layout, and interaction patterns of the product * **Outcomes:** Wireframes, high-fidelity mock-ups, and interactive prototypes * **Parties Responsible:** UI/UX Designer, Front-End Developers (for building) and QA Team (for validation) ### Software Specifications Document The Software Specifications Document is authored by the Systems Architect to provide the deep technical details required for the actual construction of the software solution. It translates functional requirements into technical blueprints, including: * Class diagrams, * Database schemas, and * API and webhook definitions. The Software Specifications Document is the definitive technical guide for the Developer Team, ensuring that the system is built with a robust, scalable, and maintainable architecture. * **Author(s):** Systems Architect * **Purpose:** To provide the deep technical details required for the actual construction of the system * **Outcomes:** Class diagrams, database schemas, and API and webhook definitions * **Parties Responsible:** Developer Team * * * ## Section 2: The Software Development Teams Software projects are led and executed by two complementary groups that, together, form the complete Software Development Teams. ### The Leadership Team Software projects are led by a small group who, collectively, make up the software Leadership Team: * The **Project Manager**, who interfaces between the Client and the Leadership Team, * The **Business Analyst**, who suggests business needs and solutions to the Leadership Team, * The **Systems Analyst**, who suggests the project functionalities to the Leadership Team, * The **Systems Architect**, who suggests the project infrastructure and framework to the Leadership Team. #### Project Manager * **Tasks:** Project scheduling, resource allocation, risk management, and Client communication * **Responsibilities:** Ensuring project delivery within time and budget constraints; managing stakeholder expectations * **Outcomes:** Project plans, status reports, and successful delivery of the final product * **Contributions:** Provides the organisational framework and Client-facing interface that keeps the project moving forward * **Software Development Document Ownership:** Author of the Product Requirements Document; coordinates the creation of all seven Software Development Documents #### Business Analyst * **Tasks:** Analysing business processes, identifying opportunities for improvement, and documenting business requirements * **Responsibilities:** Ensuring that the proposed solutions align with the business goals and provide value to the Client; attends the same meetings as, and works closely with, the Project Manager * **Outcomes:** Business cases, process models, and Client analysis * **Contributions:** Provides the business context and justification for project initiatives, ensuring strategic alignment * **Software Development Document Ownership:** Co-author of the Business Modelling Document with the Systems Analyst #### Systems Analyst * **Tasks:** Requirement gathering, business process modelling, and functional gap analysis * **Responsibilities:** Bridging the gap between business needs and technical specifications; ensuring functionality meets user requirements * **Outcomes:** Business Requirements Documents, use cases, and functional workflows * **Contributions:** Ensures the software solves the right problems and provides tangible value to the Client * **Software Development Document Ownership:** Author of the Business Modelling Document and Business Requirements Document; co-author of the Context Requirements Document #### Systems Architect * **Tasks:** System design, technology stack selection, and defining integration patterns * **Responsibilities:** Ensuring the scalability, security, and maintainability of the technical solution * **Outcomes:** Software Specifications Documents, architectural diagrams, and infrastructure plans * **Contributions:** Provides the technical blueprint and structural integrity required for a robust and future-proof system * **Software Development Document Ownership:** Author of the Software Specifications Document; co-author of the Context Requirements Document #### Purpose of the Leadership Team Together, the Leadership Team: * Defines the requirements, * Builds a flexible development strategy, * Creates the documents that are used during the last chapter of the Project Lifecycle. | Responsibility | Tasks | Outcomes | Contributions | | --- | --- | --- | --- | | **Collective** | Strategic planning, cross-functional coordination, and final approval of project milestones | A unified project vision and a comprehensive set of guiding documentation | Establishes the foundation for the Software Development Teams to build upon with clarity and confidence during the last chapter of the Project Lifecycle | ### The Developer Team The Developer Team receives the Software Development Documents from the Leadership Team and transforms those specifications into working software. Each member has a defined role in the build process: * **Development Manager:** Manages the developers; responsible for code quality, sprint execution, and technical mentorship * **Full Stack Developers:** Responsible for implementing front-end and back-end logic, database management, and API and webhook integration — guided primarily by the Software Specifications Document, Product Requirements Document, User Interface Document, and Context Requirements Document * **QA Manager:** Manages the testing team; responsible for the overall quality assurance strategy and release readiness — validates against the Business Requirements Document, Product Requirements Document, and User Interface Document * **Security Engineer:** Responsible for implementing security controls, performing vulnerability assessments, and ensuring data protection — informed by the Context Requirements Document and Software Specifications Document * **QA/Test Engineers:** Responsible for writing test plans, executing manual/automated tests, and reporting bugs — cross-references against the Product Requirements Document and User Interface Document * **DevOps Engineer:** Responsible for CI/CD pipelines, environment stability, and deployment automation — guided by the Context Requirements Document and Software Specifications Document * **Product Manager:** Responsible for the product vision, roadmap, and prioritising the product backlog based on market needs — works with the Product Requirements Document and User Experience Document * **UI/UX Designer:** Responsible for creating intuitive and engaging user interfaces and ensuring a seamless user experience — author of the User Experience Document and User Interface Document * * * ## Section 3: The Software Development Process My process is built upon Agile methodologies, specifically leveraging the Scrum framework to ensure iterative delivery, transparency, and rapid adaptation to changing requirements. I operate in fixed-length sprints, beginning with sprint planning and concluding with a sprint review and retrospective. This approach allows me to maintain a high velocity while ensuring that the most valuable features are delivered first. The Software Development Documents created by the Leadership Team feed directly into each phase of the process. The Developer Team executes against these documents throughout the Project Lifecycle. ### Development The development phase is where the technical implementation occurs, guided by the Product Requirements Document and Software Specifications Document. * **Sprint Execution:** Software Developers work on prioritised backlog items. Daily stand-ups synchronise activities and identify blockers. * **Code Standards & Peer Review:** All code must adhere to project-specific style guides. Peer reviews are mandatory to ensure code quality, knowledge sharing, and adherence to architectural patterns. * **Incremental Integration:** Code is integrated into the main branch at the end of each day to avoid integration hell and ensure the code is always in a deployable state. * **Responsible:** Development Manager, Developers. * **Software Development Documents in Play:** Product Requirements Document, Software Specifications Document, User Interface Document ### Security Security is not a final step but a continuous thread woven throughout DevSecOps and the Project Lifecycle. * **Secure Coding Practices:** Developers follow OWASP guidelines to prevent common vulnerabilities like SQL injection and XSS. * **Vulnerability Scanning:** Automated tools scan dependencies and source code for known vulnerabilities during the build process. * **Access Control & Encryption:** Implementation of robust authentication (OAuth2/OIDC), role-based access control (RBAC), encryption at rest, and encryption in transit. * **Responsible:** Systems Architect, Security Engineer, Developers. * **Software Development Documents in Play:** Context Requirements Document, Software Specifications Document ### Testing Quality is verified through a multi-layered testing strategy to ensure functional correctness and performance. * **Automated Testing:** Includes Unit Tests (logic verification), Integration Tests (component interaction), and End-to-End (E2E) Tests (user flow simulation). * **Manual QA:** Exploratory testing to identify edge cases and UI/UX inconsistencies that automated tools might miss. * **User Acceptance Testing (UAT):** The final validation step where stakeholders verify that the software meets the business requirements defined in the Business Requirements Document. * **Responsible:** QA Team, Developers (for Unit Tests), Client (for UAT). * **Software Development Documents in Play:** Business Requirements Document, Product Requirements Document, User Interface Document ### Deployment I utilise automated pipelines to ensure reliable and repeatable releases. * **Continuous Integration (CI):** Every commit triggers an automated build and test suite. * **Continuous Deployment (CD):** Successful builds are automatically deployed to staging environments for validation, followed by a controlled promotion to production. * **Infrastructure as Code (IaC):** Server configurations and cloud resources are managed via scripts to ensure environment parity. * **Responsible:** DevSecOps Engineer. * **Software Development Documents in Play:** Context Requirements Document, Software Specifications Document ### Maintenance Post-launch activities focus on stability, performance, and evolution. * **Monitoring & Alerting:** Real-time tracking of system health, error rates, and performance metrics (e.g., latency, throughput). * **Incident Management:** A structured process for responding to, and resolving, production issues based on severity. * **Feedback Loop:** User feedback and analytics are fed back into the Product Backlog for future sprint planning. * **Responsible:** Product Manager, QA Manager, QA/Test Engineers. * **Software Development Documents in Play:** All seven Software Development Documents, as maintenance may revisit any document. ### Average Project Metrics While every project is unique, an average mid-sized software product (e.g., a custom enterprise web application or a feature-rich mobile app) typically follows these parameters: * **Timeline:** 3 to 6 months from inception to initial production release. * **Discovery & Planning:** 2 to 4 weeks. * **Development (MVP):** 2 to 4 months (8 to 12 sprints). * **UAT & Final Hardening:** 1 to 3 weeks. * **Team Size:** 10 to 15 people. * **Leadership:** 3 to 4 members (Project Manager, Business/Systems Analyst, Architect). * **Execution:** 6 to 10 Developers (Front-end, Back-end, Full-stack). * **Quality & Ops:** 2 to 3 members (QA Engineers, DevOps/Security). This structured approach minimises risk, optimises resource utilisation, and maximises the likelihood of delivering a product that exceeds Client expectations. However, an optimised AI workflow has severely reduced: 1. The expected timeline from months to weeks, 2. The development team to one experienced developer and three AI Entities, and 3. The expectations of delivering quality software with support for continuous security updates. Quality software is problematic unless an experienced Project Manager or an experienced Software Developer fully commits to becoming an AI Generalist, who: * Learns how to fine-tune and post-train AI models with open weights and permissive licenses, * Adopts AI models, engineering tools, frameworks, processes, ideologies, and other AI concepts, and * Understands the underlying AI infrastructure, is prepared to learn new AI technologies as they drop, and is willing to constantly follow a field where the goalpost is regularly moved. * * * ## The Results The integrated framework gives me a complete, single-source reference covering three layers: 1. **The Seven Software Development Documents** — Business Modelling Document, Business Requirements Document, Product Requirements Document, Context Requirements Document, User Experience Document, User Interface Document, and Software Specifications Document, each with its defined author, purpose, outcomes, and responsible parties, owned by the Leadership Team and executed by the Developer Team 2. **The Software Development Teams** — the Leadership Team (Project Manager, Business Analyst, Systems Analyst, Systems Architect) and the Developer Team (Development Manager, Full Stack Developers, QA Manager, Security Engineer, QA/Test Engineers, DevOps Engineer, Product Manager, UI/UX Designer), each with defined tasks, responsibilities, contributions, and Software Development Document ownership 3. **The Software Development Process** — Agile/Scrum and the Project Lifecycle through Development, Security, Testing, Deployment, and Maintenance phases, with average project metrics for sizing * * * ## An Analysis Bringing the Software Development Documents definitions, the team roles, and the process together reveals several insights: * **The Software Development Documents and the Roles are tightly coupled.** The Business Modelling Document is authored by the Systems Analyst and Business Analyst. The Business Requirements Document is authored by the Systems Analyst. The Product Requirements Document is authored by the Project Manager. The Context Requirements Document is authored by the Systems Analyst and Systems Architect. The User Experience Document and User Interface Document is authored by the UI/UX Designer. The Software Specifications Document is authored by the Systems Architect. The role definitions in the team section map directly to the authorship in the Software Development Documents section, which means the integrated view gives me a clear responsibility matrix. * **The Process completes the picture.** The Development phase is guided by the Product Requirements Document, Software Specifications Document, and User Interface Document. The Security phase maps to the Context Requirements Document and Software Specifications Document. The Testing phase validates against the Business Requirements Document, Product Requirements Document, and User Interface Document. The Deployment phase follows the Context Requirements Document and Software Specifications Document. Each Software Development Document feeds into a specific stage of the Project Lifecycle, and knowing which document to reach for at each phase is the practical value of understanding these descriptions. * **The Software Development Documents are a precursor, not the destination.** The Leadership Team creates these documents so the Developer Team can build working software. The documents define what to build and why, but the final product - the computer program - itself is the real outcome. I must never lose sight of the Software Development Documents being a map, with included waypoints, of my journey toward the final intent: a fully functional, client-approved, software application. * * * ## In Conclusion This integrated document provides a comprehensive framework for navigating the complexities of modern software development. By clearly defining the seven Software Development Documents, the Leadership Team and Developer Team roles and responsibilities, and the rigorous Project Lifecycle, I establish a foundation for transparency and accountability. The transition from high-level business modelling in the Business Modelling Document to granular technical specifications in the Software Specifications Document, executed within Agile/Scrum sessions throughout the Project Lifecycle, ensures that the final software is not only technically robust but also strategically aligned with business objectives. The creation of the Software Development Documents by the Leadership Team is simply a precursor to the real work: building the software programs themselves. Until next time: Be safe, be kind, be awesome, kia kaha!! * * * ## Document Details: Documents for Developers **Document Subtitle:** Team Roles & Developer Documents **Document Version:** v0.5.2 **Document Author(s):** Brian King **Document Attributions:** Not applicable **Hashtags:** #SDDs #SoftwareDevelopment #BMD #BRD #PRD #CRD #UXD #UID #SSD #LeadershipTeam #DeveloperTeam #Agile #Scrum #DevSecOps #SoftwareEngineering **SEO Title:** Documents for Developers — Leadership, Development & the Seven SDDs **SEO Description:** A complete guide covering the seven Software Development Documents (SDDs), Leadership Team and Developer Team roles, and the Agile/Scrum Software Development Process lifecycle. **Document Creation Date:** Saturday, 15 August 2026 **Last Update:** Saturday, 15 August 2026 © Copyright 2020-2026 DigitalCoreNZ. All rights reserved.