Build a deck around decisions
Software engineering is a broad subject, so flashcards work best when they test distinctions and decisions rather than isolated vocabulary. A useful card asks for one answer: for example, what acceptance criteria do, or how an integration test differs from a unit test. If a card asks for a list of unrelated points, split it into smaller cards.
The deck below covers core ideas in requirements, development, testing and design. It is intended as a starting point for revision, not a substitute for your course notes or the terminology used by your programme. Some terms—such as “unit”—can be defined differently in different teams and texts. When your course gives a specific definition, use that wording.
To study each card, read the question and try to answer it before looking at the back. Then compare your answer with the key idea. Choose a grade based on how readily and accurately you recalled it: use the lowest grade if you could not retrieve the answer, and a higher one only if recall was clear. Recognising a sentence after reading it is not the same as recalling it unaided.
A focused revision deck from a software engineering board looks like this:
What is the main difference between a functional requirement and a non-functional requirement?
A functional requirement describes behaviour or a service the system must provide; a non-functional requirement specifies a quality attribute or constraint, such as performance or security.
All 18 cards
That is a MySummaries deck, filled with software engineering material. Yours is written from your own notes. Start free
Work through the answers, not just the wording
The first card asks you to distinguish behaviour from qualities and constraints. Try to name an example of each before reading the answer: “the user can reset a password” is functional; “reset requests must be protected against unauthorised use” concerns security. An example helps you test whether you understand a concept rather than merely recognise its label.
Cards 2–5 concern requirements. A use case describes an actor pursuing a goal; it is not simply a screen-by-screen interface description. Acceptance criteria make completion testable, while prioritisation helps decide what belongs in a delivery. Traceability is useful when a requirement changes: follow its links to see which designs, implementation work and tests may need attention. Be precise about MoSCoW: “Won’t have this time” sets a current scope boundary, not necessarily a permanent ban.
Cards 6–7 move to managing change. Version control gives a history of file changes; continuous integration is a practice of integrating changes frequently and checking them automatically. A repository does not, by itself, guarantee that a team integrates often or that its checks are useful. When revising, keep the tool (for example, Git) separate from the practice the team follows.
Cards 8–12 ask you to place tests at different levels. Unit, integration, system and acceptance tests answer different questions, although exact boundaries vary between organisations. Regression testing describes a purpose—checking for unintended breakage—not a single test level. A regression check might be a unit test, an integration test, or an end-to-end check. Practise explaining both the test’s scope and why it is being run.
Cards 13–18 cover development and design. In test-driven development, the test leads the change through red, green and refactor. Code review is a human examination of a proposed change; automated checks can support it but do not make the two identical. The design cards test relationships between ideas: responsibility, cohesion, iterative refinement, incremental delivery and the future cost of shortcuts. For iterative versus incremental development, a strong answer notes that a team may use both rather than treating them as competing labels.
Keep the high-value facts short
After a first pass, reduce the deck to the facts you need to retrieve quickly. This is not a replacement for the full cards: it is a compact check before a quiz, tutorial or assessment. Add a definition from your own notes if your course uses a more specific version, and remove anything that is not part of your learning objectives.
The Must not miss core for this deck is:
Recite each point in your own words, then give an example. If you cannot supply an example, return to the relevant cards and check whether the distinction is clear. Avoid turning the core into a longer set of notes: its job is to reveal gaps quickly.
Turn missed marks into another question
When you miss a card twice, do not just repeat its wording. Identify the confusion and make the next review test that exact distinction. For instance, if “integration” and “regression” keep blending together, ask what each describes: the former concerns components working together; the latter is the purpose of checking that a change has not broken existing behaviour. The correction should be brief enough to answer from memory.
A card waiting for a second attempt might read:
You confused a test level with a test purpose twice: what does an integration test examine, and what does regression testing try to detect?
Review the tray prompt before returning to the original cards. Then answer it in one or two sentences, with an example if needed. If you can do that reliably, keep the distinction in rotation; if not, rewrite the card so it asks one clearer question.
How MySummaries helps
Build a revision board from your own software engineering notes, then use it to generate flashcards for spaced repetition. That keeps definitions and examples tied to the material you are expected to learn. Start at MySummaries.