Requirements and Trade-offs

Every design starts from two lists: what the system must do, and how well it must do it. Without them, two teams handed the same product build different systems, and neither can show the other is wrong. You will learn to sort a requirement into functional or non-functional, to name the quality a non-functional one constrains, to rewrite a vague requirement until a test could fail it, and to spot a design built for traffic nobody asked for. Turning those requirements into numbers belongs to estimation, and choosing the parts belongs to the topics after it.