Just finished editing 25 papers on process control for FDA (Food and Drug Administration) regulated industries, so here are a few reflexive neuron firings.
The FDA requires that the user requirements be captured first, in a way that can be understood by both the user and the vendor of the required hardware or software, but with no vendor contribution. Once agreement has been reached, the vendor prepares a functional specification that can be understood by the user and the people who will build the thing that is proposed. When the functional specification is approved, the technical team prepares design requirements and builds what the user needs (they hope). When built, it is tested against the design specification, then the functional spec, and finally the user spec. The user signs off on the last tests to accept the product. This only works when everybody is on familiar ground, and all of the technical principles (if not the details) are understood. Otherwise, you enter a design, prototype, and feedback cycle until the user and the vendor can agree on what the vendor will provide. Only then can the user write requirements that don't require transmutation of elements or time travel. Concisely, the requirements must refer to feasible design properties. They can't be kept separate until it is known that the thing can be done. After that, the FDA process (V-Model) assures a win-win result, if you have the people and the time to handle the documentation and negotiations. All IMHO, of course. Bill Hawkins -----Original Message----- From: Magnus Danielson Sent: Wednesday, December 15, 2010 3:50 PM ------------%<-------------- You mix requirements and sketch of design-idea. Keep requirements and proposed design properties separate. Cheers, Magnus _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.