---
name: software-engineering
description: "Software Engineering: 35 concepts, no maths assumed."
version: 1.0.0
author: Learn AI
license: CC-BY-4.0
metadata:
  hermes:
    tags: [Software, Engineering]
    related_skills: [llms-and-generative-ai, machine-learning, mathematical-foundations]
    source: https://basavapurushottam.com/learn-ai
---
# Software Engineering

35 concepts, written for an adult with no computer science and no mathematics past school arithmetic. Each concept is a file under `references/`; load one when it is the thing being asked about rather than reading the whole domain.


## When to Use

- The reader asks about software engineering and wants it explained from the ground up rather than summarised.

- A term below comes up and you want the plain-language account of it, with a worked example.

- You need to know what a concept rests on before teaching it — every reference lists its prerequisites.


## When NOT to Use

- The reader wants current events, papers or library documentation. This is a curriculum, not a news source, and it does not update itself.

- The reader wants code they can ship. Examples here are written to be understood, not deployed.


## How to Run

Open the file listed beside a concept in Quick Reference below. The files live in the `references` directory, are plain Markdown with no front matter and no dependencies — read the one you want and ignore the rest.


## Quick Reference


### Software Architecture

- `references/cohesion-and-coupling.md` — **Cohesion and Coupling**: Cohesion is how related a module's contents are; coupling is how dependent modules are…
- `references/database-as-architectural-pillar.md` — **Database as Architectural Pillar**: Treating the data store as a first-class architectural decision — its model, guarantees…
- `references/dependency-inversion.md` — **Dependency Inversion**: Depending on abstractions rather than concrete implementations, so high-level policy do…
- `references/hexagonal-architecture.md` — **Hexagonal Architecture**: Placing domain logic at the centre with all external interaction through ports implemen…
- `references/layered-architecture.md` — **Layered Architecture**: Organising a system into presentation, application, domain and infrastructure layers wi…
- `references/microservice-cost-tradeoffs.md` — **Microservice Cost Tradeoffs**: Weighing independent deployability and scaling against the distributed-system complexit…
- `references/ports-and-adapters.md` — **Ports and Adapters**: Ports are interfaces the core defines for what it needs; adapters are the outside imple…
- `references/rest-and-graphql.md` — **REST and GraphQL**: Two API styles: REST exposes resources over HTTP verbs, GraphQL exposes a schema client…
- `references/separation-of-concerns.md` — **Separation of Concerns**: Keeping distinct responsibilities in distinct places, so a change to one concern touche…
- `references/single-responsibility.md` — **Single Responsibility**: A module should have one reason to change, keeping its purpose narrow enough to state i…
- `references/the-ilities.md` — **The Ilities**: The non-functional qualities architecture actually trades between — maintainability, te…

### Software Testing

- `references/api-testing.md` — **API Testing**: Testing service interfaces directly — contracts, status codes, payloads, error handling…
- `references/accessibility-testing.md` — **Accessibility Testing**: Verifying software works with assistive technology and meets standards for contrast, st…
- `references/boundary-value-analysis.md` — **Boundary Value Analysis**: Testing at the edges of input ranges, where off-by-one and comparison errors concentrate.
- `references/contract-testing.md` — **Contract Testing**: Verifying that a provider and consumer agree on their interface, without running both t…
- `references/equivalence-partitioning.md` — **Equivalence Partitioning**: Dividing inputs into classes expected to behave identically, then testing one represent…
- `references/errors-of-process-vs-interpretation.md` — **Errors of Process vs Interpretation**: Two distinct failure classes: the analysis did not do what you intended, or it did and…
- `references/exploratory-testing-frameworks.md` — **Exploratory Testing Frameworks**: Structured approaches to unscripted testing — charters, tours and heuristics — that mak…
- `references/frontend-performance-testing.md` — **Frontend Performance Testing**: Measuring what users actually experience — load, interactivity and visual stability — r…
- `references/pairwise-testing.md` — **Pairwise Testing**: Covering all pairs of parameter values rather than all combinations, on the evidence th…
- `references/playwright-and-selenium.md` — **Playwright and Selenium**: Browser automation frameworks that drive a real browser to exercise an application as a…
- `references/property-based-testing.md` — **Property-Based Testing**: Asserting properties that must hold for all inputs and letting the framework generate c…
- `references/reference-testing.md` — **Reference Testing**: Pinning an entire output against a stored reference so any unintended change fails loudly.
- `references/security-testing.md` — **Security Testing**: Actively probing an application for vulnerabilities — injection, broken authorisation,…
- `references/shift-left-testing.md` — **Shift-Left Testing**: Moving testing earlier in the lifecycle so defects are found when they are cheap to fix.
- `references/test-planning.md` — **Test Planning**: Deciding what to test, at which level and to what depth, given risk and available effort.
- `references/visual-regression-testing.md` — **Visual Regression Testing**: Comparing rendered screenshots against approved baselines to catch unintended visual ch…

### Spec-Driven Development

- `references/acceptance-criteria.md` — **Acceptance Criteria**: Testable conditions defining when a requirement is satisfied, written before implementa…
- `references/engineering-intent-documents.md` — **Engineering Intent Documents**: A short artifact capturing the build direction between a raw idea and a formal specific…
- `references/product-requirements-documents.md` — **Product Requirements Documents**: A structured statement of what a product must do and for whom, from which technical des…
- `references/requirements-traceability.md` — **Requirements Traceability**: Maintaining links from each requirement through design, tasks, tests and code, so cover…
- `references/review-gates.md` — **Review Gates**: Explicit checkpoints where work must be approved before advancing, with defined criteri…
- `references/spec-drift.md` — **Spec Drift**: Implementation gradually diverging from the specification, so the document stops descri…
- `references/spec-to-code-pipeline.md` — **Spec-to-Code Pipeline**: The controlled path from specification through tasks and tests to implementation, with…
- `references/task-cards.md` — **Task Cards**: Small self-contained work items derived from a specification, each carrying enough cont…


## Pitfalls

- The concepts are ordered by what rests on what, not by difficulty. A later concept is not always harder; it is later because something else has to come first.

- Explanations avoid notation the reader has not met. If you reintroduce standard symbols, say what they mean, or you undo the thing this curriculum is for.


## Verification

`ls references/ | wc -l` should print 35.


---

From [Learn AI](https://basavapurushottam.com/learn-ai). Prose is licensed CC BY 4.0.
