Victoria:
From a BA perspective, consider:
* For function/process requirements gathering, is the focus on understanding standalone requirements, or is it on understanding the essential interrelationships between the requirements? This, probably more than anything else drives success or failure. The second approach is the way to go.
* Same as the above in gathering data requirements, but remember that understanding fuctional/process requirements leads data gathering.
* Irregardless of whether the project is called Waterfall, or Agile, is the focus on gathering minimal requirements that are at the same time quality requirements.
* Has the project been formally scoped out (ie has a Context Diagram been created and verified). If not you will have scope creep and missing requirement
* Is the approach as top down as possible. For bigger projects, bottom up projects run the risk of "drowining in an ocean of details."
* If the project is larger scale, then, to handle complexity, decomposition is needed. In this case, is a logical, natural approach to patitioning being taken, else the resulting decomposition will have minimal use.
* Can the project obtain the bigger picture? At the bigger picture level, systems have non definable sequence. Few know how to handle such.
Tony