Requirements are anti-climatic

Many business analysts assume that their entire job, the end result of their efforts, is the requirements document, or in an agile context, the set of user stories or product backlog. This is not the case.  The requirements regardless of what form they take or what they are called, are really an after thought.

The real job of the business analyst is to come up with solutions to the business problem.  Optimally, the business analyst comes up with more than one solution so that the business stakeholders or management can decide which solution is the best for the organization. That doesn’t mean that the business analyst implements the solution, only devising the solution: what the business needs to do to solve the problem.  The solution is developed, or built, or purchased, or repurposed by a solution team of which the business analyst may be a part, or not.

The solutions the business analyst presents to the decision makers may be in the form of a business case, a proposal (if the business analyst works for a consulting firm, for example), a PowerPoint presentation, a formal review, or any number of other forms, but not in the form of requirements.  Why go through the exercise of developing requirements when the solution to be implemented has not been selected? 

Only after the solution has been determined are the requirements developed. 

The requirements are the details of the solution that describe to the implementers, the builders, the software development team, the quality assurance team, management, the process workers and users of the solution, and anyone else involved in or interested in the improvement being made. 

And even as detailed ‘instructions’, the requirements are still an after thought.  The business analyst should communicate the selected solution and details to the solution team and everyone else (in their own language and to the level of their understanding and need to know) before the formal requirements are committed to paper, electronic or otherwise. 

Understanding comes first, requirements simply document that understanding.

The problem is solved and everyone agrees to the solution.  All those involved in making the solution happen or evaluating the solution or using it understand what is to be done to their level and agree to it.  It’s all done and decided.

Then the requirements document what is being done.  Quite anti-climatic.

words are magic

Several years ago I was consulting to a large company in the health care business. I was somewhat of a "business analysis coach" in the role that I had. In one meeting the business analysts were complaining about their elicitation process. The complaints were fairly consistent with many others I had heard: the important people don't show up to the meetings, people who do show up don't contribute, some people high jack the meetings with their own agendas, there is conflict in meetings where there should be only information passed, people come unprepared, etc.
I made a couple of small suggestions. They called their meetings "requirements workshops" as per the IIBA's BABOK and many other sources. I suggested they call their meetings "information gathering sessions" instead.
Why? because anyone attending a "requirements workshop" would have the expectation that the meeting will end up with completed requirements. So people will come ready to make sure that their requirements get included. Others who have no particular requirements or who are afraid to commit to requirements will not show up or will show up and stay silent. Arguments will ensue among those who want their requirements included. In an "information gathering session" the only expectation is that information will be passed.
I also suggested that they change the name they gave to those coming to the meetings. In their invitations they cited "attendees". I suggested that someone coming to a meeting as an "attendee" has an expectation of just attending. If they want the people coming to the meetings to participate in the meetings they should call them "participants".
They made the changes immediately. By the next week as they returned from their meetings and reported in, they told us of the change in the way things were going. People came to meetings with documentation, prepared to answer questions and provide information. There were significantly fewer conflicts, even among those who were consistently in conflict in the past meetings. More people coming to the meetings contributed and responded to questions the business analysts asked. In general the meetings were more positive and the morale of the business analysts rose.
All as a result of simply changing a bit of vocabulary. This proves how important words are and how they affect our expectations, even subconsciously.

Several years ago I was consulting to a large company in the health care business. I was somewhat of a "business analysis coach" in the role that I had. In one meeting the business analysts were complaining about their elicitation process. The complaints were fairly consistent with many others I had heard: the important people don't show up to the meetings, people who do show up don't contribute, some people high jack the meetings with their own agendas, there is conflict in meetings where there should be only information passed, people come unprepared, etc.
I made a couple of small suggestions. They called their meetings "requirements workshops" as per the IIBA's BABOK and many other sources. I suggested they call their meetings "information gathering sessions" instead.
Why? because anyone attending a "requirements workshop" would have the expectation that the meeting will end up with completed requirements. So people will come ready to make sure that their requirements get included. Others who have no particular requirements or who are afraid to commit to requirements will not show up or will show up and stay silent. Arguments will ensue among those who want their requirements included. In an "information gathering session" the only expectation is that information will be passed.
I also suggested that they change the name they gave to those coming to the meetings. In their invitations they cited "attendees". I suggested that someone coming to a meeting as an "attendee" has an expectation of just attending. If they want the people coming to the meetings to participate in the meetings they should call them "participants".
They made the changes immediately. By the next week as they returned from their meetings and reported in, they told us of the change in the way things were going. People came to meetings with documentation, prepared to answer questions and provide information. There were significantly fewer conflicts, even among those who were consistently in conflict in the past meetings. More people coming to the meetings contributed and responded to questions the business analysts asked. In general the meetings were more positive and the morale of the business analysts rose.
All as a result of simply changing a bit of vocabulary. This proves how important words are and how they affect our expectations, even subconsciously.

Listen Naively

Generally the users or stakeholders do not tell you things that they think you know. The more you appear to know about their environment, problem, process, etc. the less they will tell you, especially about specifics.

This is a natural human reaction.  We don’t want to answer a question posed by someone with information they already know.  We don’t want to hear, “Yes, Of course. I know that. What I want to know is…”  In other words, we don’t want to appear stupid. So we will answer the question vaguely or with Monty Python’s “wink, wink, nod , nod” (I don’t have to say it because you know what I mean). 

The end result is that no new information is provided with the answer to the question.

And of course the questioner  is loath to repeat the question to get more detailed information because the questioner also does not want to appear stupid.

The answer is to ask and listen naively.

If you listen naively, as though you don't know anything, and encourage the responders to tell you more, you will get a lot of unstated expectations and implicit requirements. Use the "tell it to me like I'm six years old" approach and you may get most of those implicit requirements and hidden expectations.