This is a live list. I’ll keep adding to it as I figure out more good questions to ask. The idea isn’t to fill it up with thousands of questions, but find the most useful ones.

There’s just one golden rule when gathering requirements: “Don’t assume, ask.”

For example, it’s worth asking if people have single letter last names, because some do. And some don’t have surnames. Yes, Null is valid. But, this question is a lot less informative, and matters less than the ones that follow.

Consumer Constraints


This helps give an idea of what direction things might go in the future. For example, if it’s a consumer facing minimal feature, there’s a good chance we’ll extend that feature if the experiment works. Thus, the design needs to be extensible. Unless we’re doing a quick and dirty experiment, in which case your design decisions would change.

Usage Constraints


This helps give an idea of how slow or fast things ought to be. It’s important to ask these questions for quick and dirty experiments as well, so you don’t end up doing a wrong experiment, where users didn’t use the feature not because it wasn’t great, but because it was too slow.

Technical Constraints


The usage change question helps inform extensibility. If we expect things to grow exponentially, we’d need to design accordingly.

The bottleneck question is an interesting one - it’s not always useful, since you don’t have a design at hand, but it’s good to think of this. I find it helps me build intuition about systems.

There’s a lot more to system design - this checklist is just the first phase of gathering requirements.

Interested in learning more?

Things I Learned to Become a Senior Software Engineer

Everything I learned to become a senior software engineer. From good skills to have, to dealing with difficult engineering problems.


You can send yourself an email with this post.