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.