The most common verb associated with requirements is “gather.” Yet most requirements that end up fulfilled in a system aren’t gathered. Yes, I know, there are always a few requirements that are so obvious in a new system that you can “gather” them from stakeholders, but gathering implies that the requirements are already out there, fully formed and fully understood, and ready for harvest. It just doesn’t work that way. No stakeholder ever says to an analyst, “Requirements? Why, yes, I have eleven requirements. Eight are functional, one is a usability requirement, and the other two are operational requirements. Are you collecting constraints now, as well? I have three of those. Please sit down, and I will elucidate perfectly clearly on each and every one in turn.” Most requirements are discovered–or invented. Many are transformed or compromised along the way.
Most stakeholders don’t consider the underlying requirements of their work; they do their work. They are not in the business of reinventing the work. The arrival of a new project is the point in time when the ideas for new possible ways of doing work force us to consider the underlying requirements. If you go to an experienced front-desk hotel employee and ask what requirements there are for the check-in process, you are most likely to hear in excruciating detail exactly how the check-in procedure works today. Indeed, you will probably hear more than just about check-in; you will hear about the reservation procedure and how it impacts the check-in procedure. It never crossed the mind of that employee to consider what information and material goods the hotel needs in order for a guest to do self check-in with a new automated system. And the idea of the guest selecting a room from all those available is a shock. It’s not done that way!
This is why we have folks with “analyst” in their titles. Analysis is never simply about recording requirements from clients and other stakeholders. Analysts are not waiters who take orders without comment. Analysts need to learn how to tease out the basic rules–the policies–of the system and liberate all stakeholders from thinking that the new system should be based on current procedures. It is invention that is at the heart of analysis, not gathering.