Much emphasis is given in the writings on Requirements to topics that cover the collection and definition of requirements. But I notice a lot more ambivalence when it comes to dealing with the Development side of the fence. We are more concerned with defining the boundaries between Development and Requirements as opposed to vigorously engaging with our brethren who write code.
Some of this separation is justified to ensure that real requirements are being defined as opposed to tailoring requirements that match some predefined solution that already exists or development believes to be the right solution. But I believe an over emphasis on not crossing over the boundary into design can actually hurt projects instead of helping them.
Specific ways in which Requirements Analysts can help designing solutions are suggested below:
1. Facilitate design meetings. Requirements professionals have specific skills and training in the area of facilitation that software developers usually do not have. Having the Requirements Analyst who created the requirements lead design meetings has a twofold benefit. First and obviously, any specific questions on the requirements can be clarified on the spot by the person who created them in the first place. Second and more importantly, the facilitation and elicitation skills that requirements professionals posses can ensure that meetings are productive, focused and arrive at an optimal solution with the active participation of all participants. Oftentimes, junior developers with good ideas are typically shut out of these meetings out of deference for their more senior colleagues. An independent facilitator like the Requirements Analyst can ensure that their viewpoints are heard and incorporated into the final solution.
2. Coordinate the interaction between different development teams. When a solution requires the cooperation and joint effort of two or more functional development teams, the Requirements Analyst can play a vital part in ensuring that these teams communicate effectively with each other. The conflict resolution skills of the Requirements Analyst are particularly helpful in getting teams with differing viewpoints and agendas to arrive at a consensus and move forward.
3. Facilitate communication between teams. It seems almost silly, but I have seen teams even struggle to set up meetings to talk with each other. So even something as basic as getting the two parties together goes a long way to getting code out the door.
4. Provide context for future requirements to ensure that flexible solutions are built. Development teams are often not privy to the prioritization of requirements. The final document they receive may have already redacted additional requirements that were to be taken up in future development efforts. Without this knowledge or roadmap, developers could end up designing solutions that are not future proof. A Requirements Analyst who is part of the design process can provide this context and help development teams come up with robust and future proof solutions.
5. Kill gold plating at the design stage. Developing superfluous features does not always have its genesis in outrageous requirements. I have often seen features delivered that were never asked for because someone in development thought it would be a good thing to do. This kind of wasted effort can be killed at source by a vigilant Requirements Analyst who is part of the solution design process.
In summary, I strongly believe there is a very important role to be played by the Requirements analyst in designing final solutions. In our fear of converting them into software developers or getting them out of their depth in technical solutions they are not qualified for, I think we are depriving the development process of a very valuable resource.
What do you think?
