Software Engineering Foundations

Software Requirements Specification

Required. Produce an SRS or equivalent for a real software system. Functional and non-functional requirements, use case or user story format, acceptance criteria, constraints, and scope definition — all documented to a standard a reviewer who did not attend your planning meetings could implement from. A senior software engineer or engineering manager challenges the completeness: they present an undisclosed scenario and ask which requirements govern it, requiring real-time reasoning about scope and ambiguity. No equipment needed — a text editor and GitHub are sufficient.

Software Architecture Design Document

Required. Architecture document for the same system as seq 10 (or a comparable real system): component diagram, data model, API contracts, technology choices with trade-off rationale, and ADRs for the two most significant non-obvious decisions. Architecture must explicitly reference specific requirements from seq 10. A senior engineer with system design experience presents an undisclosed constraint (a new requirement, a failure scenario) and asks how the architecture handles it. draw.io is free for diagrams. Builds directly on requirements specification.

Software Test Plan and Coverage Analysis

Elective. A complete test plan for a real software system: test strategy, scope, test cases with expected outcomes linked to specific requirements or acceptance criteria, and coverage analysis. Coverage report generated by pytest-cov, JaCoCo, Istanbul, or equivalent — all free. A senior engineer or QA lead challenges coverage gaps: presents a named scenario and asks which test case would catch the defect, requiring reasoning about coverage completeness rather than just reading the report.

Deployment Plan and Operations Runbook

Elective. A deployment runbook for a real software system: step-by-step deployment procedure, rollback procedure, environment configuration checklist, health check verification, and incident response decision tree. The runbook must be independently executable by someone who has never deployed this system — that is the proof standard. A senior engineer or DevOps practitioner does a live review: they ask what happens if step N fails and what the observable symptoms of each failure mode are. GitHub Actions (free for public repos) is sufficient infrastructure.

Engineering Design Review

Elective. Participate in a real engineering design review as author or reviewer: prepare design documents, present to reviewers who have not seen the design, receive written critique, and produce a revision note documenting decisions made and rationale for decisions rejected. The review record (agenda, critique, revision note) is the proof — not the design artifact alone. This step is the adversarial verification component of the path: the undisclosed challenge is the reviewers' questions. A solo project design review recorded with a peer acting as reviewer also qualifies.

Free, browser-based diagramming tool for architecture diagrams, component diagrams, and data flow diagrams. No install required. Exports to PNG, SVG, and PDF. Use for the architecture document (component diagram, data model, API contract diagrams). The standard free alternative to Visio or Lucidchart.

Free, standardised architecture documentation template used widely in professional practice. Provides structure for requirements context, architecture decisions, deployment diagrams, and quality requirements. Use as the template for the software architecture document — reviewers who know arc42 can evaluate your work against a recognised standard.

Free CI/CD platform for public repositories. Use for the deployment runbook step — a runbook for a system deployed via GitHub Actions is immediately verifiable by any reviewer. Workflow YAML files are the configuration artifact and the Actions run log is auditable.

Free professional SRS template with guidance on functional requirements, non-functional requirements (FURPS+ framework), constraints, and scope definition. Use for the requirements specification step — structured templates catch requirements gaps that free-form documents miss.