Feature Sets

You must define a system’s boundaries before designing it. Start by asking clarifying questions to understand the environment. For a parking lot, does it have multiple levels? What types of vehicles1 are supported? How does data enter the system?2 Is the service paid or free? Are there different tiers of user accounts?

Functional requirements define what the system does. These are the features the user interacts with.

Example: Tiny URL

Example: Financial Dashboard


Non-functional requirements define how the system performs. These are the -ilities that ensure the system is production-ready.

Determine the technical infrastructure that will support features once they’re defined. Always consider storing raw data rather than just processed summaries. We can’t predict future analytics needs. Raw data is paramount - it allows us the latitude to re-process information if we add new features later or face compliance audits. Using a standard SQL database yields immediate benefits:

When adding a feature to the scope, ask:

  1. Does this change the functional scope7?
  2. How does this impact non-functional requirements?8
  3. Do we have the raw data necessary to support this, or do we need to change our ingestion method?
  1. compact, large, electric 

  2. In a banking app, is data pushed or pulled by our service? 

  3. “Return all stocks with an open price >N and a close price <M” 

  4. financial or privacy regulations 

  5. like the stock price example 

  6. don’t reinvent the wheel 

  7. what it does 

  8. Will it slow the system down?