Ideation & Requirements#

Deciding what to actually build.

Before any schematic is drawn or component is selected, there’s a phase where the project takes shape — or fails to. This subsection covers the messy, important work of defining what a project needs to do, what constraints it must operate within, and when building hardware is even the right answer.

Most failed projects fail here, not at the layout stage. Ambiguous requirements, unexamined assumptions, and premature commitment to a solution are the leading causes of rework. Getting this phase right doesn’t guarantee success, but skipping it almost guarantees waste.

What This Section Covers#

• Problem Definition vs Solution Bias — Recognizing the tendency to jump to a circuit before understanding the actual need.
• Functional vs Non-Functional Requirements — Separating what the system must do from how well it must do it.
• Component Dependencies & Datasheet-Driven Requirements — Reading datasheets to discover what candidate components need, before those needs become surprises.
• Constraints: Size, Power, Cost & Environment — Identifying the boundaries every design must live within.
• Good Enough Criteria — Knowing when a design is sufficient and when to stop refining.
• When Software Beats Hardware — Deciding whether a problem is better solved in code or copper.
• Knowing When Not to Build — Evaluating whether custom hardware is the right answer at all.