Requirements Miranda

If you can not afford a set of requirements one will be appointed to you.

We need to tell clients this loudly and at regular intervals when they expect us to work without direction. If you are too ignorant, lazy, uninvolved, distracted, stupid, or whatever to create a set of requirements that we can use to actually build you a product then we'll just help you out by telling you what we're building.

My best client right now is an appliance controls company who has a ton of work for myself and my primary partner. Most of what we're doing for them is porting old products designed in the '90s to new hardware platforms, but keeping the same pin-for-pin replacement functionality. (You'd be shocked how old the controls in "modern day" commercial ovens, refrigerators, dishwashers, etc. really are. Oy.) Often the original product requirements are lost, vague, misleading, incomplete, YaddaYaddaYadda. Usually the resulting mandate is to "make it work like the old one," even down to some of the bugs carried through from the original development effort. Sure thing; you betcha.

But it's not always possible to exactly reproduce the old product's behavior, especially when the box is hooked up to a network or gets some unknown stimulus from some undocumented source. Also, many of the old controls were designed to take advantage of some weirdness or other of the original microcontroller or some other piece of hardware, and that behavior isn't duplicated by the modern part (usually an Atmel AVR or something) used in the new design.

As an end to this, my partner usually creates an "As Built" document which describes the behavior of the new control and how it differs from the old control. Also, undocumented behavior from the old control is specified as being implemented or not and what differences there may be. Having the "As Built" document polishes up the leftover gaps from the shortened requirements phase, itself an artifact of the end customer not having his shit together. Remember, this isn't just ass-covering, it's a mechanism for documenting what is and isn't in the final product. The customer can whine any time he wants and pay for more work to make it act to his (revised) specification.

-- MartySchrader

CategoryRequirements