||There is a myth that
requirements define a solution. There is an associated myth that poor
requirements' gathering lead to failed projects.
This is to misunderstand requirements. Requirements actually come in a variety of forms.
There is a set of requirements that, when analysed define a problem. Then there are those requirements which are the result of the development of a solution. Thirdly are the requiremenst for a project. It is only that last that a project manager should be concerned with. If the project is supposed to identify a solution as well as implement it then my advice is to be very suspicious. It is very likely that "requirements gathering" will get very confused.
The process should be:
1. Business Requirements
2. Business Problem
3. Proposed Solution
4. Detailed Requirements
5. Implementation Project
I suggest that an Architect should deal with 1-3, the Architect (and potentially a Designer/Technical Specialist or two to assist) develops 4 and a PM looks after 5.
Project Managers and Architects look at requirements in different ways.
If a PM doesn't have enough requirements, they gather some, probably by running a workshop or two.
An architect has (or should have) a fundamentally different approach.
An architect will start off with a business problem to be solved. It may be phrased in terms of objectives, intended solutions, and even a set of requirements. Many business people can only really think in terms of perceived solutions. However, there is often enough information to start discovering the real problem.
A good architect will gather information on the problem, often by analysing a proposed solution (by analyse I mean, fully understand what it is trying to achieve), identify how the proposed solution was developed, what the solution will actually achieve (often not what was intended) and uncover all the overt and/or covert assumptions that have been made.
Once the problem has been understood, the architect will develop a range of solution options. These can then be measured against the problem as well as the issues relevant to implementing the solution.
Finally a proposed solution and transition plan can be recommended and agreed. Once that has been achieved the detailed requirements to deliver the solution can then be documented and then form the basis of the implementation project. The PM will be happy because (s)he doesn't have to gather any - other than a few incidentals like how they are going to run the project.
The difference between the Project Manager approach and that of an Architect is that the requirements as identified by the architect will lead to a coherent, optimised solution that spolve the problem, whereas the PM's requirements are more than likely to be inconsistent, incomplete and lead to something other than an optimal solution.