As a practicing business analyst the chances are you participate in a wide variety of projects, on many different teams. And usually, at the start of such projects, roles and responsibilities have to be discussed and agreed. Conflicts of opinion often occur, as business analysis, project management, development and quality assurance duties partially overlap with each other. This is not a bad thing. Instead of entrenching behind strict boundaries, all roles, and particularly business analysts, need to see themselves as generalizing specialists.
So what is a generalizing specialist?
As a generalizing specialist you must be experienced and knowledgeable in your own domain. But you must also have an understanding of the responsibilities of the roles with which you interact, and be prepared to take on some of these roles even, too.
I can learn a lot about the quality of my requirements by working with QA, and even helping QA to do the testing. But guess what? QA can really help me with my requirements. I focus on the common cases and the main exceptions. QA bring a different mindset – “what will go wrong?” – and this so often brings up all sorts of requirements discussions. Do we include validation to support this? Or do we handle it through documentation?
Some of the greatest opportunities for role generalization for me have arisen with developers. Design documentation of any type was not being produced and mistakes and assumptions were uncovered too late. So I offered to attend design meetings and take notes. Reluctantly the developers agreed. But then, as design progressed, the developers had all sorts of requirements questions and I was there to answer them (or find answers). And not only that, sitting and working together built up understanding and trust, and our working relationship improved. Finally, the development manager asked to come along to requirements meetings to help learn about the business needs. And the quality of delivered software improved because development assumptions became better aligned. And I learned how to document designs!
An even better example for business analysts related to partnering with business. If you are about to work in a new business domain (or even for a current domain in which you believe you are an expert) go and do the job for a few days. Really do the job, working on production business. You will gain a much better understanding of the requirements that way. And when, in reciprocation, the business folks help to write requirements, they will have a better understanding of systems too.