peterbamuhigire/sdlc-planning

Platform Notes

• Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

SDLC Planning Skill

<!-- dual-compat-start -->

Use When

• Generate Planning & Management documentation for SDLC projects. Covers Project Vision & Scope, SDP, SCMP, QA Plan, Risk Plan, SRS, and Feasibility Study. Use when starting a new project, conducting project governance, or establishing the planning...
• The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

Do Not Use When

• The task is unrelated to sdlc-planning or would be better handled by a more specific companion skill.
• The request only needs a trivial answer and none of this skill's constraints or references materially help.

Required Inputs

• Gather relevant project context, constraints, and the concrete problem to solve; load templates only as needed.
• Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

Workflow

• Read this SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
• Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
• Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

Quality Standards

• Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
• Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
• Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

Anti-Patterns

• Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
• Loading every reference file by default instead of using progressive disclosure.

Outputs

• A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
• Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
• References used, companion skills, or follow-up actions when they materially improve execution.

References

• Use the templates/ directory when the task needs a structured deliverable.

<!-- dual-compat-end -->

Generate a complete Planning & Management documentation suite for software development projects. This skill produces 7 foundational documents that establish the project baseline before any code is written.

Load Order

1. Load world-class-engineering.
2. Load this skill to define the planning baseline and phase-entry gates.
3. Pair it with engineering-management-system, advanced-testing-strategy, and deployment-release-engineering when the plan must be executable.

Executable Planning Standard

Planning documents must define more than scope. They must define:

• critical flows and risk class
• measurable success criteria and service expectations
• delivery slices and release assumptions
• testing, observability, and rollback expectations
• ownership for decisions, operations, and follow-up

When to Use

• Starting a new SaaS project and need a governance baseline
• Establishing project planning documents for stakeholders or investors
• Conducting a feasibility study before committing resources
• Setting up configuration management and quality assurance processes
• Creating a software development plan for the team
• Building a risk management framework for an upcoming project
• Preparing a full-system SRS (not just requirements interview or Android-only)

When NOT to Use

• Gathering raw requirements via interview -- use project-requirements skill instead
• Planning a single feature (spec + implementation) -- use feature-planning skill
• Planning an Android companion app (PRD, SDS, API Contract) -- use mobile-saas-planning skill
• Writing design documents (SDD, architecture, database design) -- use sdlc-design skill
• Writing test plans with test cases -- use sdlc-testing skill
• Writing deployment or user documentation -- use sdlc-user-deploy skill

Document Inventory

| # | Document | File | Purpose | Audience | Length | |---|----------|------|---------|----------|--------| | 1 | Project Vision & Scope | templates/project-vision-scope.md | Establish the "why" and "what" | Stakeholders, sponsors, investors | 15-30 pages | | 2 | Software Development Plan | templates/software-development-plan.md | Management & technical approach | PM, dev leads, QA | 20-40 pages | | 3 | Configuration Management Plan | templates/configuration-management-plan.md | Change & version control processes | DevOps, dev leads, release mgrs | 15-25 pages | | 4 | Quality Assurance Plan | templates/quality-assurance-plan.md | Quality processes & standards | QA team, devs, PM | 15-25 pages | | 5 | Risk Management Plan | templates/risk-management-plan.md | Identify, assess, mitigate risks | PM, stakeholders, dev leads | 15-25 pages | | 6 | Software Requirements Spec | templates/software-requirements-spec.md | Full functional & non-functional requirements | Devs, QA, stakeholders, architects | 30-60 pages | | 7 | Feasibility Study Report | templates/feasibility-study-report.md | Viability analysis before commitment | Decision makers, investors, sponsors | 15-30 pages |

Generation Workflow

Generate documents in this order. Each builds on the previous.

Step 1: Gather context (use project-requirements skill if not done)
    |
Step 2: Feasibility Study Report (Go/No-Go decision)
    |
Step 3: Project Vision & Scope (approved vision)
    |
Step 4: Software Requirements Specification (full requirements)
    |
Step 5: Software Development Plan (how to build it)
    |
Step 6: Configuration Management Plan (how to manage changes)
    |
Step 7: Quality Assurance Plan (how to ensure quality)
    |
Step 8: Risk Management Plan (what can go wrong)

Prerequisites

Before generating any documents, gather or confirm:

| Input | Source | Required? | |-------|--------|-----------| | Project name & domain | User interview | Yes | | Target market & users | User interview | Yes | | Core feature list | project-requirements output or user | Yes | | Tech stack decisions | Project context or defaults | Yes | | Budget & timeline constraints | User or stakeholder | Recommended | | Existing system inventory | Codebase audit | If migrating | | Regulatory requirements | User or domain research | If applicable |

Cross-References to Existing Skills

Upstream Skills (use BEFORE this skill)

| Skill | Relationship | |-------|-------------| | project-requirements | Gathers raw requirements via guided interview. Feed its output (requirements.md, business-rules.md, user-types.md, workflows.md) into this skill's SRS and Vision documents. |

Parallel Skills (use ALONGSIDE this skill)

| Skill | Relationship | |-------|-------------| | feature-planning | For individual feature specs and implementation plans. This skill covers project-level planning; feature-planning covers feature-level planning. | | vibe-security-skill | Security baseline for all web applications. Reference in QA Plan and Risk Plan. |

Downstream Skills (use AFTER this skill)

| Skill | Relationship | |-------|-------------| | mobile-saas-planning | For Android companion app planning (PRD, SDS, API Contract). Uses this skill's SRS as input. | | multi-tenant-saas-architecture | Backend architecture patterns. Uses SDP and SRS as input. | | modular-saas-architecture | Pluggable module architecture. Uses SRS module inventory. | | saas-seeder | Bootstrap the SaaS template. Uses requirements from SRS. | | sdlc-design | Design documentation phase. Uses approved SRS as primary input. | | sdlc-testing | Testing documentation. Uses SRS requirement IDs for test case traceability. |

Future skills to add (identified from ISO/IEC 14764-2006): Software Maintenance Plan (Corrective/Adaptive/Perfective/Preventive maintenance types) and Post-Deployment Evaluation Report are not yet implemented as skills but should be generated at project close.

Available SDLC Skills

| Skill | Phase | Documents | |-------|-------|-----------| | sdlc-design | Design | SDD, Database Design, API Design, UI/UX Spec | | sdlc-testing | Testing | Test Plan, Test Cases, V&V Plan, Test Report, Peer Review |

Available SDLC Skills (continued)

| Skill | Phase | Documents | |-------|-------|-----------| | sdlc-user-deploy | Delivery | User Manual, Deployment Guide, Release Notes, Training Plan |

Adaptation Rules

SaaS vs Standalone

| Aspect | Multi-Tenant SaaS | Standalone App | |--------|-------------------|----------------| | Data isolation | Row-level via franchise_id | Not applicable | | Auth model | Dual auth (Session + JWT) | Single auth model | | Deployment | 3-env (dev/staging/prod) | May be simpler | | Scaling | Per-tenant growth planning | Single-instance scaling | | SRS sections | Include NFR-MT (multi-tenancy) | Omit multi-tenancy NFRs | | Risk register | Include tenant data leakage risks | Omit tenant-specific risks |

Android + Web vs Web-Only

| Aspect | Android + Web | Web-Only | |--------|---------------|----------| | SRS scope | Include mobile NFRs (offline, app store) | Web NFRs only | | SDP | Include Android build pipeline | Web pipeline only | | SCMP | Include Gradle + PHP configs | PHP configs only | | QA Plan | Include Android testing (Compose UI, JUnit 5) | Web testing only | | Risk Plan | Include app store rejection risks | Omit mobile risks |

MVP vs Full Product

| Aspect | MVP | Full Product | |--------|-----|--------------| | Vision scope | P0 features only | P0 + P1 + P2 features | | SDP phases | 2-3 phases | 5-8 phases | | SRS depth | Core modules only | All modules | | Feasibility | Focus on technical + economic | All five feasibility types | | Risk register | Top 10 risks | Comprehensive (20-30 risks) |

Output Structure

When generating documents for a project, create this structure:

docs/planning/
├── 01-feasibility-study.md
├── 02-project-vision-scope.md
├── 03-software-requirements-spec.md
├── 03-srs/
│   ├── functional-requirements.md
│   ├── non-functional-requirements.md
│   └── traceability-matrix.md
├── 04-software-development-plan.md
├── 05-configuration-management-plan.md
├── 06-quality-assurance-plan.md
└── 07-risk-management-plan.md

Each file must stay under 500 lines. Split into subdirectories as needed.

Phase Gate Exit Criteria

Every project passes through six risk-based milestones (Disciplined Agile, 2020). Each milestone has mandatory exit criteria verified before proceeding. These map to the six DA milestones.

| Gate | DA Milestone | Triggered By | Exit Criteria | |------|-------------|--------------|---------------| | G1 | Stakeholder Vision | End of Skill 01–03 | Vision documented; stakeholder register complete; scope agreed with Out of Scope listed; domain confirmed | | G2 | Proven Architecture | End of Skill 04 | Interface spec complete; architecture strategy selected; key risks identified; no unresolved [CONTEXT-GAP] tags | | G3 | Requirements Complete | End of Skill 05 | All FRs have GWT stubs; all NFRs have SMART metrics; every FR traced to business goal; zero [V&V-FAIL] tags | | G4 | Logic Validated | End of Skill 06–07 | All LaTeX formulas verified; attribute mapping complete; no conflicts in Section 3.4 | | G5 | Audit Passed | End of Skill 08 | Zero [V&V-FAIL], [GLOSSARY-GAP], [TRACE-GAP], [SMART-FAIL] tags; SRS approved by consultant | | G6 | Production Ready | Post-testing | Test plan complete; no open must-fix defects; Go/No-Go approved in phase exit meeting |

Anti-pattern: Advancing to the next gate without resolving all tags from the current gate propagates defects downstream. One unresolved [V&V-FAIL] at G3 typically generates 5–10 downstream rework items.

Quality Checklist

Run after generating all documents:

• [ ] All 7 documents generated (or justified why one was skipped)
• [ ] Each document stays under 500 lines (split if needed)
• [ ] Vision & Scope has measurable success metrics with numeric targets
• [ ] SRS has numbered requirement IDs (FR-MOD-001, NFR-PERF-001)
• [ ] SRS Section 1.2 includes an explicit ## Out of Scope subsection
• [ ] Every NFR is SMART: Specific, Measurable, Achievable, Relevant, Time-bound — flag [V&V-FAIL: SMART metric not defined] for any that are not
• [ ] Every SHALL requirement has an inline acceptance stub: **Acceptance:** Given [state], When [action], Then [outcome]
• [ ] Requirements are prioritized using MoSCoW; time-sensitive features additionally scored with Cost of Delay
• [ ] SDP references the correct tech stack with version numbers
• [ ] SCMP describes the actual Git branching strategy being used
• [ ] QA Plan references vibe-security-skill for security quality gates
• [ ] Risk Register includes at least 8 pre-populated SaaS-specific risks
• [ ] Feasibility Study ends with a clear Go/No-Go/Conditional recommendation
• [ ] All documents cross-reference each other where relevant
• [ ] Multi-tenant isolation addressed in SRS, QA Plan, and Risk Plan
• [ ] Deployment environments (Windows dev, Ubuntu staging, Debian prod) documented in SDP
• [ ] Release, rollback, and post-deploy observation assumptions are documented in the plan set
• [ ] No vague language ("user-friendly", "fast", "secure") -- all measurable
• [ ] Examples are tailored to the project's actual tech stack and domain

Anti-Patterns (What NOT to Do)

| Anti-Pattern | Why It Fails | Do This Instead | |-------------|-------------|-----------------| | Skip feasibility, jump to coding | Wastes resources on unviable projects | Always do feasibility first | | Copy-paste generic templates | Documents don't match your project | Customize every section to your context | | Write SRS without stakeholder input | Requirements will be wrong | Use project-requirements skill first | | No measurable success metrics | Can't tell if project succeeded | Define KPIs with specific numeric targets | | Ignore multi-tenant requirements | Data leakage between tenants | Always include NFR-MT requirements | | One massive document | Exceeds 500-line limit, hard to maintain | Split into index + sub-files | | No risk register | Risks become surprises | Pre-populate with common SaaS risks | | Skip configuration management | Deployment chaos, lost changes | Document branching, releases, migrations | | Write plans and never update them | Plans become stale and useless | Review and update at each phase gate | | Omit Out of Scope section from SRS | Scope creep is invisible | SRS Section 1.2 must include explicit ## Out of Scope subsection | | Vague NFRs without SMART metrics | Cannot verify or test non-functional requirements | Each NFR must be Specific, Measurable, Achievable, Relevant, Time-bound | | No Given-When-Then acceptance stubs | Requirements written without verification linkage | Add inline **Acceptance:** Given [state], When [action], Then [outcome] to every SHALL requirement | | Prioritize only by gut feel | High-value work delayed; delivery misaligned with business | Use Cost of Delay (CoD) for time-sensitive requirements alongside MoSCoW |

Template Files

Each template provides the complete structure, section-by-section guidance, example excerpts, anti-patterns, and a quality checklist.

1. Project Vision & Scope
2. Software Development Plan
3. Configuration Management Plan
4. Quality Assurance Plan
5. Risk Management Plan
6. Software Requirements Specification
7. Feasibility Study Report

References

• ../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.

---

Back to: Skills Repository Related: project-requirements | feature-planning | mobile-saas-planning Last Updated: 2026-03-15 (strengthened per Adjei 2023, Winston, Etter 2016, Cone 2023)