[whats_a_quasar]

This is the only one I have reservations about. It is also part of the engineer's job to understand the customer, understand what they need, and negotiate the requirements (within reason). It's hard (impossible?) for the customer to fully design exactly what they need, and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet

[c_o_n_v_e_x]

>and it works much better to the engineers to build something with continuous customer input than to build rigidly to a spec sheet

Continuous input is a tried and true method of blowing out both budgets and timelines on building anything physical.. hardware, rockets, chemical plants, etc.

[tonyarkles]

Working at a hardware company with a software company founder (which I’ve done multiple times now) can be a frustrating experience. People used to being able to casually say “hey I want to add this new feature” and getting “$40,000 and 12-week shipping delay” as a response are generally not happy. One project I worked on shipped board v2.17; the requirements were changing so quickly that we often needed to do significant board redesigns before we’d even sent the current design to the prototyping shop. It was… fun.

[firewolf34]

You're describing the (albeit quite common) situation where requirements were not conclusive enough and need to be revised throughout lifetime of development, which can be natural as you begin to understand the problem space as you work within it. But the key is that the requirements should be as conclusive and accurate to resolving your problem as they possibly can be, at any given point in time.

In the "frictionless environment, ideal world" scenario - requirements should always be completed as close to the letter as possible and no further.

In the practical scenario, requirements should be written as close to perfect as can be achieved where perfect is defined as what is necessary to resolve your problem space, limited by your understanding of the problem space.

[beckingz]

Except that requirements cost time to develop, so perfect requirements have significantly more cost than good enough requirements.

Also, requirements tend to evolve as customers grow, so requirements will change over time and become less perfect, causing that investment to depreciate.

[tonyarkles]

I agree completely. In the physical goods world, though, it’s not a continuous function. At points along the way, there is a very clear cost step response. Requirements evolving is totally fine and expected, but you need to periodically say “The current set is good enough, let’s build it and ship it”. Trying to do continuous delivery on manufactured items is the road to madness.

My general approach to this is to try to reasonably anticipate things that could be coming down the pipe and, if possible, do the bare minimum to cheaply support the next prototype. As an example, if the product has a GPS receiver and a microcontroller and could conceivably need to do dual-receiver down the road, I’ll have a quick look for spare Tx/Rx pins on the microcontroller and just route those out to blank pads. Two benefits:

- when product management asks, we have a way to build a prototype using existing parts

- if there aren’t any spare pins to break out like that, I can raise it as a potential design red flag early. It’s not necessarily a show stopper, but it contributes situational awareness for when the next big step cost might show up down the road.

[firewolf34]

I love when you guys do that. Then when I'm hacking around w/ your machine, I can get ahold of those spare pads :)