Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Tuesday, July 22, 2008

Requirements and ZBBs

I dislked "Requirements Engineering". Very often it is associated with projects that do not satisfy the customer. At the end, the engineers often blame the customer, saying "If only they had written more precise requirements".

This is a cop-out. It is the engineers' job to figure out the real customer needs and requirements. Or maybe the architects. Or marketing.

Here is an example of why I dislike "Requirements Lists". If you have requirements R1…R10, often people say "Let's restrict ourselves to the top three", and implement a mechanism or separate mechanisms that meet R1, R2, R3. They ignore the possibility of a mechanism that satisfies all of R1…R10, although possibly not as wel as the specific mechanism.

Or, there may be a single mechanism that satisfies R1 and R3…R10, but not R2. But it gets dropped, because we have arbitrarily excluded R4…R10 from consideration.

I.e. it is not so much the process of requirements that I dislike, as the simple minded prioritization thinking that is so often associated with it.