subbu.org

Of all the tasks in software development, collecting requirements and then specifying a design are the most difficult things, and I have been guilty of being imprecise about both. Is there a way out? Bruce Eckels’ recent post on
Finding out what the customer really wants made me rethink about these issues.

First of all, when we begin to think of new things, we tend to be imprecise. As the things we want take shape, we get better at visualizing the thing we want that can do the things we want to accomplish. This is an iterative task and evolves over time. So, when we ask customers/users of what they want, we are bound to get imprecise descriptions. Most project managers and those dealing with customer requirements, often blame customers for changing their minds. I can imagine the frustration when a user tells a project manager that his/her view of the system changed, but I don’t think the user should be blamed for that.

For a moment, let us think of a restaurant. You take your table at the restaurant, and the waiter asks you to describe what you want to eat without showing you the menu. You will describe the ingredients, the kind of preparation, and so on, in very imprecise terms, based on similar items you have eaten elsewhere in the past. When the food finally arrives, first reaction would possibly be "this is not I asked for". Should you be blamed for this? Instead, think of the usual scenario in a restaurant. The waiter shows you the menu, you pick up the items, and then the waiter asks you for any variations. You will most likely be satisfied with the order when the food finally arrives.

I think the requirements issue is somewhat similar to this. When you start to deliver the initial bits of the software, the user’s understanding of the system improves. The users tends to get more and more precise about what the system should do. Then it is the time for the user to restate the requirements.

Process-gurus can design all kinds of processes to isolate this uncertainty in requirements. But no process can make a person give precise description of what he/she wants without an iota of understanding of what he/she is going to get. Yet we try, because people who manage the development process must somehow be able to comprehend the software without precisely understanding either the requirements or the implementation.

A related issue is specifying a design for the system without actually building one. Don’t we sometimes get blamed for jumping to coding without fully specifying a design? I think this is natural. Just as users are generally imprecise about requirements, we tend to be imprecise about design. As we start implementation, our understanding of the system improves, and so the design evolves. As a result, the design specifications will remain imperfect, and will not completely reflect the final system.

It takes experience and imagination to design software that is resilient to uncertainty of requirements and imprecise specifications. I admire those who pull through these and deliver useful software. I must admit that there are certain kinds of software that must be specified more precisely. I also admire those who make such specifications, and those who build to those specifications.