Docs for Devs — Leadership, Development & the Seven SDDs

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:

A clear Creation Goal for the software under development,
An Engineering Team — This includes the Leadership Team and the Developer Team,
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,
An understanding of the Software Development Process that the team follows, from concept to completion, and
A Client profile — The company, stakeholders, and users.

Updating my Base System.

From the terminal, I update my system:

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:

The expected timeline from months to weeks,
The development team to one experienced developer and three AI Entities, and
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:

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
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
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

Command Palette