Where is the Challenge with User Requirements?
User Requirements are obviously very elusive little things. They seem to be extremely difficult to capture and, once captured, seem to be brilliant at hiding and escaping. It would appear that they have an uncanny ability to change their appearance so no one can recognize them and then just wander off without sounding any alarms. Sometimes, one could even think that they exist on a different plane of reality, flashing onto our plane briefly and then disappearing from whence they came. Their elusive existence causes us the most heartburn on information technology projects. We must learn more about these intriguing little beasties to figure out how we can harness their energy and expend less of our own to deliver the technology solutions that the business community craves.
On a typical project, the business analyst (or someone with a different title but the same responsibilities — we will name this person Babs to make our life simple) is charged with gathering user requirements. She spends an ordinate amount of time (some might think inordinate but Babs is experienced enough to know the difference) interviewing subject matter experts and others in an attempt to figure out how the business community could take advantage of new technology. Other times, Babs has had to figure out how the organization could use existing but currently unused technology more effectively. From her experience, she knows that this is the spawning ground for user requirements. If we were to ask Babs at this time, "Where are the requirements," she would most likely answer that they are in the minds of the presumptive users (whoever that might be).
So our intrepid hunter–gatherer–analyst Babs takes up the onerous task of flushing out and capturing the young, rambunctious user requirements. She applies all of the tools, techniques, and wily tricks she has at her disposal in an attempt to force the most timid and reclusive user requirement to reveal itself. It is easy to bag one once it is visible (obviously, user requirements are not the fastest runners even in the bloom of their youth). At the end of the hunt, the triumphant analyst returns to her cubicle, flushed with victory and carrying a heavy load of freshly caught requirements. Now, she knows where the requirements are — they are in the bag.
Hidden User Requirements
Next, Babs starts to deal with each user requirement on a one–on–one basis. She carefully removes one from the bag, studies it, dissects it, reformats it, and labels it with a descriptive (business requirement, stakeholder requirement, functional solution requirement, quality solution requirement, etc.). Ancient and revered analysts developed these descriptives to aid in the classification and ultimate application of user requirements. Babs then places the now labeled requirement into the container deemed most appropriate to hold one of its kind. The containers that she has available are called Business Requirements Document, Product Backlog or some such impressive–sounding label — also invented by those same ancient analysts. Now she knows for sure where the requirements are — aptly sorted and in the appropriate container.
Unfortunately, when finished with this highly analytic activity of sorting and labeling, Babs has a sense of unease as if there were something missing. Perhaps there are still user requirements lurking out there somewhere, requirements that were not in the heads of the users but hiding somewhere else. Suddenly, Babs has an insight, a flash of brilliance. User requirements could hide in the processes and procedures of the organization. Excited, she rushes out to the nearest office supply store to buy huge flipcharts and markers. Calling her subject matter experts together again, she proudly exhibits her artistic side by drawing detailed models of the processes. In agile meetings, she creates data flow diagrams, activity diagrams, Swimlanes, and data models. She is amply rewarded when a flood of new, hitherto hidden requirements fly around the room and are captured, one by one, on the flipchart under the magic markers in Babs’s hand. They cannot escape now; they are there, visible on her models.
User Requirements Transitioned
Proudly, Babs presents her captured user requirements to the development team. She tries her best to communicate the deeper meaning behind each statement and symbol, encouraging the team — nay, challenging them — to ask any question they can think of. She is confident that she has all of the answers and, in case she does not, she knows she can always fall back on her sources.
User Requirements Changed
The team distributes the user requirements to individuals or groups who will be responsible for building or buying a solution that exhibits the behavior that the individual requirement expresses. In the middle of this process, of course, Babs shows up with chagrin and mentions that a couple of the user requirements somehow escaped their containers in her cube. She throws them into the corral. The model of a good analyst, however, she does not leave before making sure that the developers have no unanswered questions.
Although the interruption was unwelcome, the team recognizes reality. They continue the process of grouping, sorting, and assigning the user requirements including, of course, those that Babs added.
Thus armed, the developers sally forth, building a component here, buying one there, integrating them, testing them, molding them to become the solution of choice. This is a critical time on the project to ask our annoying question, "Where are the requirements?" The answer will tell you a lot about the probable success of the project. Let us look at some typical answers and the implications for the future of the endeavor.
"I don’t know, ask the project leader". We hereby sentence this project to an indeterminate amount of rework that will culminate in redefinition, redesign, redevelopment, or burial.
"They are over there, in the Requirements Document (Use Case Document, User Story, etc.)". Good inasmuch as the developer at least knows where he/she should be looking. Not so good since the effort required to go anywhere to get the requirement is an impediment to making sure that the solution fulfills it. We decree that this project suffer from missed requirements and unsatisfied users.
"They are right here in my hot, little hands". This is one of the best answers since the developer is obviously obsessed with the requirements — and obsessed is what he/she needs to be to be able to deliver the right solution. This project has a reasonable chance of success — depending on what the developer does with the requirements in his/her possession.
Where the Requirements Are
I have actually never run across what I consider the best answer. Based on many (many, many) years of experience in analyzing, defining, and delivering information technology to the business community, I conclude that there is only one right answer.
Requirements are in the minds of the users. Yes, Babs tried her awesome best (and she is good, remember?) to get them out of their minds and on paper, on her models, and in her documents. The developers did their level best (and they are skilled) to make sure that they understood what the requirement meant before they started to develop a solution.
Unfortunately, reality measures success not by how many requirements you meet but by how positive the business community views your solution. Accept the fact that written requirements, whether captured in text or in a picture, are only representations of what the requestors were thinking at some point in time. As the analyst, as the designer, as the developer, you have to be in constant contact with those requestors. You know that the real requirement is only in their mind. Asking is not enough, you have to demonstrate as early as you can what you think the requirement means. You have to let them try out what you are building while you are building it before they can possibly know whether the solution you are building is what they had in mind.
19th Century poet, critic, and philosopher Samuel Coleridge observed, "An idea, in the highest sense of that word, cannot be conveyed but by a symbol." The corollary in the world of information system development should be, "A requirement, in the true meaning of that word, cannot be conveyed but by a solution". That is when the requirement leaves the mind of the requestor and enters reality. Now we all know where it is. It is in the solution.
