New IT staff often hear senior colleagues say things like “that is a hard requirement” or “put it in the backlog as a nice-to-have”, and nod along without being sure where the line sits. This beginner primer explains the difference between hard requirements and wishes, why the distinction shapes almost every technical decision, and gives you a mini-glossary to keep nearby. No prior experience is needed, only a willingness to ask what happens if a thing is missing.
The core idea in plain terms
Every project starts with more ideas than capacity. Time, money and attention are limited, so something has to give. A hard requirement is a condition that must be met for the work to count as successful. A wish, which many teams call a nice-to-have, improves the outcome but is not required for success. The skill is in telling them apart early, because a team that treats every wish as a requirement spends its budget on polish while the foundations remain unfinished.
Evidence matters here. A claim that “we need X” is stronger when it points to something observable: a contract clause, a security rule, a measured outage, a user who cannot complete a task. A claim backed by “it would be cool” belongs on the wish list, however enthusiastically it is made.
Mini-glossary for beginners
- Requirement: a statement of something the solution must do or a condition it must meet.
- Hard requirement: a requirement whose absence means the work has failed, such as a legal obligation or a security control.
- Wish (nice-to-have): a desirable extra that can be postponed or dropped without failing the project.
- Constraint: a limit on how you may deliver, such as budget, deadline or a platform you are told to use.
- Acceptance criterion: a test that tells you whether a requirement has been met.
- Trade-off: a choice in which gaining one benefit costs another.
- Backlog: an ordered list of work not yet done, with the most valuable items at the top.
- Scope creep: the slow growth of a project’s contents without a matching increase in time or money.
- Tie-breaker: a wish that decides between two options that both satisfy every hard requirement.
Why the split speeds up decisions
Consider two candidates for a monitoring service. Both pass every hard requirement: they run in your region, they keep logs for as long as your policy demands, and they cost less than the cap. One has a nicer colour theme; the other has a slightly faster search. Without the split, a committee could spend weeks comparing dozens of small differences. With it, the committee can say that both qualify, apply tie-breakers in ranked order, and decide in one sitting. The hard list works as a filter, and the wish list works as a sort.
How to find your hard requirements
- Ask what would force a rollback. If a missing feature would make you undo the whole change, it is hard.
- Look at obligations. Contracts, regulations and internal policies produce requirements that are not negotiable.
- Review past incidents. Failures reveal what the system has to protect.
- Interview the people who run it. Operators know which conditions keep them awake at night.
- Test the phrasing. If you cannot write an acceptance criterion for an item, it is probably too vague to be a requirement.
Reading roadmaps with this lens
Once you can sort requirements, planning documents become easier to read. A staged guide such as a roadmap for data science and engineering teams adopting MLOps is, among other things, an argument about order: which capabilities come first because everything else depends on them, and which come later because they refine what already works. When you read a roadmap, ask which stages are foundations (close to hard requirements) and which are enhancements (close to wishes). Your organisation’s answer may differ from the author’s, and that is a healthy sign that you are applying judgment.
The same lens helps when you read about the benefits of a practice. An overview such as how MLOps speeds up deployments and supports growth lists potential gains, but your task is to decide which gains your situation truly needs and which are pleasant side effects.
A short example from daily operations
Suppose your team must pick a way to store backups. Your hard requirements might be: backups are encrypted, a restore has been rehearsed successfully, and the oldest copy meets the retention period in policy. Wishes could include a friendly web console, integration with a chat tool, and a cheaper tier for rarely used data. A product that fails any hard requirement is out, regardless of how pleasant the console looks. Among those that pass, the wishes decide.
Decisions beyond IT
The same method applies to personal and family choices, particularly those with real stakes. Someone planning care abroad, for instance, might sort practical needs first, such as dates, language support and whether a relative can travel too. One educational website, BestCardiacHospitals, built for people abroad researching heart care, walks readers through sharing needs and then comparing options, and it flags on its own pages that the content is general learning material, not medical advice and not an emergency service. For an IT beginner, the transferable point is simple: define what you need before you compare offers, and leave specialised judgment to qualified people.
How wishes can graduate to requirements
Beginners sometimes assume the hard list is carved in stone. It is not. A wish becomes a requirement when evidence shows that its absence causes real harm: a regulator introduces a new rule, a customer makes a feature a condition of renewal, or a pilot shows that people cannot do their jobs without it. The reverse also happens. A requirement written years ago may no longer apply once the process around it has changed. Treat the hard list as a living document, and record each promotion or demotion with a date and a reason so that a newcomer can understand the history without asking around.
Frequent beginner mistakes
Calling a preference a requirement. Notice words like “should” and “would be nice”. They usually describe wishes.
Forgetting non-functional requirements. Availability, security and response time are easy to leave out because they are invisible when they work. They often make the hard list.
Ranking wishes by who asked. Seniority is not a measure of value. Use benefit, cost and reversibility.
Treating the first list as final. Requirements change as you learn. Review them at milestones and write down the reason for every change.
Where to go from here
Practise on a small decision this week: a tool you are choosing, a ticket you are scoping, even a purchase at home. Write the hard requirements first, test each one with “what happens if it is missing”, and rank everything else as tie-breakers. After a few rounds the habit becomes automatic, and the glossary terms stop feeling like jargon. You will find yourself asking sharper questions in meetings, and the answers will arrive sooner, since the list that truly matters stays small enough to remember without notes.