The Problem With Requirements Gathering

By Henry Newman

I am constantly discussing requirements gathering with people that seemingly want to look at only part of the requirements rather than the whole end-to-end workflow. Each group in the architecture wants to look only at its own requirements.

For example, server folks want to look at how many cores are needed and how much memory is required, often not looking at memory per core or memory bandwidth requirements, nor the number and types of PCIe buses needed. The I/O and file system people often do not think about the amount of memory needed for file system cache, the layout of the server in terms of buses, and the number and types of connections. On top of this, the application requirements from the users and the workflow is often not well understood nor even described well. How can anyone develop an architecture without a good understanding of how resources will be consumed?

This leads me to think the problem stems from organizational behavior. We all seem to want to play in our own sand (SAN) box (forgive the pun), and yet everyone expects the resulting system to meet the requirements of both the users' applications and the people managing the systems. Somehow, everyone seems to forget that it does not work that way most of the time, and the results do not seem to provide the best value to everyone. Working together in a large organization requires everyone to provide information, and everyone to give up information and control for the benefit of the whole.

Have we all become too selfish to look at the group benefit, which, of course, is the organizational benefit. Changing the way we think requires more than leadership from the top today; it requires a complete rethink of how society behaves.

This article was originally published on June 27, 2012