Lesson 50 · Engineering practice

From requirements to design

Good software starts with the problem, not the code. Follow a small library-loan app from its users to a design: write what people need as user stories, sort the requirements into functional, non-functional (speed, cost, security) and constraints, then turn them into components, a data model and interfaces, and write it all down in a short design doc that weighs the alternatives.

12 min10 steps5 questionsBeginner

Fig 50 · Interactive

Loading figure…

or ← →

Check yourself

5 quick questions

Pick an answer to see why. Your score saves with your progress.

01Which of these is a well-formed user story?

A user story names who needs it, what they want and why: As a [who], I want [what], so that [why]. The others are a technology choice, a non-functional requirement and a design detail.

02"Search results appear in under 1 second" is which kind of requirement?

It says how well the system must work (its speed), not what it does. Speed, cost and security are typical non-functional requirements.

03Which of these is a constraint rather than a requirement?

A constraint is a fixed limit you do not get to choose, such as the deadline, the team or a required language. It rules some designs out before you start.

04In the design, why does the web app call borrow(member, book) on the loan service instead of writing to the database itself?

The loan service owns the rules (due dates, who may borrow). An agreed interface lets each part be built and changed separately, as long as the calls stay the same.

05Why choose SQLite over PostgreSQL for this small library?

Every choice is a trade-off. SQLite is simple to run but allows only one writer at any instant; PostgreSQL handles many writers but needs a server to look after. The design doc records the choice and when to revisit it.

Key terms

Glossary

Requirement: Something the system must do or a quality it must have, written so you can check whether it is met.
User story: A short need written from a user's view: As a [who], I want [what], so that [why].
Functional requirement: What the system must do, such as "members can borrow and return books".
Non-functional requirement: How well the system must work: its speed, cost, security, reliability and so on.
Constraint: A fixed limit on the solution that you do not get to choose, such as a deadline, a budget or a required language.
Component: A part of a system with one job, such as a web app, a service or a database.
Data model: The things a system stores (here Book, Member and Loan) and how they link to each other.
Interface: The agreed calls one component offers to others, such as borrow(member, book). Callers rely on it, not on what is inside.

Fine print

Notes and sources

The library app is an invented example. Its numbers (21-day loans, under $20 a month, 2 developers, 8 weeks) are requirements we chose for it, not facts about libraries.
The 1-second target comes from usability research: about 1 second is the limit for a user's flow of thought to stay uninterrupted (Nielsen, 1993).
Store passwords with a slow, salted password hash (such as Argon2id, scrypt or bcrypt), never as plain text or a fast hash (OWASP Password Storage Cheat Sheet).
SQLite allows any number of readers but only one writer at any instant; each write is short, so a small library with a few staff is well within what it handles. PostgreSQL is a client/server database whose MVCC lets many sessions read and write at the same time.
Real projects loop: building often uncovers new requirements, so the stories, the design and the doc change as you learn. The figure shows one pass, in order.

Quiz Unlocks after the last step.