Utility · sources and further reading
Resources
Design has fewer "official docs" than software does: much of it is professional convention. The references below are the stable, serious versions of everything this hub teaches. Same rule as every week: when a random tutorial disagrees with these, these win.
Reference documents
| Document | Use it for | Nature |
|---|---|---|
| Python Tutorial: More Control Flow Tools | break, continue, loop else, and function details; this week's core language reading | Official (PSF) |
| time module · random module | monotonic() vs time(); uniform() and friends | Official (PSF) |
| gpiozero: input devices API | Button's waits, events and debounce, precisely defined | Project docs |
| Software requirements specification | What the industry-scale version of this week's one-pager looks like (ISO/IEC/IEEE 29148 territory) | Encyclopedic |
| Pseudocode · Flowchart · Finite-state machine | The notations' histories, variants and formal versions | Encyclopedic |
| Structured programming | Why sequence, selection and repetition suffice; the history behind the construct table | Encyclopedic |
| Mountain Goat Software: user stories | The agile requirements style, from its best-known teacher | Practitioner reference |
Background reading, matched to the stages
| Stage | Read this for the ideas behind it |
|---|---|
| Requirements | The SRS article for the formal shape; user stories (and the INVEST checklist) for the agile shape; compare them against the course's one-page style |
| Pseudocode | Structured programming for why the construct set is complete; the control-flow chapter for every construct's exact Python behaviour |
| Flow & state | The flowchart and FSM articles; GRAFCET veterans can skim the FSM article's examples and translate them mentally |
| Design lab | The time module docs on clock kinds (the monotonic story, in the library's own words); Button's API for what the waits guarantee |
Reading order for a beginner: this hub, then the control-flow chapter, then the encyclopedic pieces when a notation's "why" itches. Automate the Boring Stuff ch. 2 (flow control) remains the gentlest second telling of the Python half.
Practice
- Trace tables, daily, until the midterm. Take any short program from Automate the Boring Stuff ch. 2 or the tutorial, cover the explanation, trace it by hand, then run it in the REPL and compare. Ten minutes a day; the delta between your table and the interpreter is your syllabus.
- Spec everyday machines. The homework exercise generalizes: any appliance with a button and a light is a requirements kata. Write five R-lines, then find the edge case your spec forgot (there is always one).
- Reverse-engineer specs. Take your Week 4 ladder scripts and write, after the fact, the requirements they satisfy. Where a behaviour resists being specified, you have found improvised logic worth redesigning.
- Read one real recipe critically. Pick a gpiozero recipe and write its pseudocode and its implicit requirements. Library examples make excellent translation practice in the reverse direction.
Drawing and writing tools
- Paper first. Hand-drawn flowcharts, state diagrams and trace tables, photographed into the repository, are fully acceptable evidence and the fastest medium at the bench and in exams.
- diagrams.net: free, browser-based, no account needed; flowchart and state-diagram shapes built in; exports PNG for the repo.
- Mermaid: diagrams as text inside Markdown, rendered by GitHub automatically; the natural next step once your
docs/folder is a habit, since text diagrams diff and merge like code. - Markdown tables (for requirements and traces): the GitHub formatting guide from Week 1 covers the pipe syntax in one minute.
Glossary
| Term | Meaning |
|---|---|
| Requirement | A single testable statement of behaviour or quality the system must have. |
| Functional / non-functional | A behaviour / a measurable quality or constraint on behaviour. |
| Acceptance criterion | The concrete pass/fail check paired with a requirement. |
| Specification (SRS) | The collected, agreed requirements; at industry scale, a formal document. |
| Constraint | A requirement about circumstances rather than behaviour: platform, tools, process. |
| Pseudocode | Structured plain-language logic: exact about control flow, silent about syntax. |
| Stepwise refinement | Descending from goal to coarse steps to detail, checking each level before the next. |
| Trace table / desk check | Hand-executing a design, one row per step, one column per variable. |
| Flag variable | A boolean that carries a fact from inside a loop to a decision after it. |
| Edge case | A boundary input or timing: too early, zero, twice, held down, never. |
| Flowchart | Control flow drawn: process boxes, decision diamonds, labelled arrows. |
| State / FSM | A named mode; a finite-state machine is states plus event-driven transitions. |
| break / continue | Exit the innermost loop / skip to its next lap. |
| Monotonic clock | A clock that only moves forward; the right clock for intervals. |
| Verification | Checking the built system against its requirements, one criterion at a time. |