Nick McKenzie states in the article: "To do A you need to have B. However, B is not specified. [The business owner] assumes that because he knows what B is, that the business analyst and the programmers will also know it.”

B,could be of such consequence that it can completely change the scope of a project."

Tony Markos responds:

Stated another way: As a process (function, whatever) is defined by its inputs and outputs, it is essential that the BA document them in the functional spec.

Typically, the business owner is aware of the processe's outputs, but can not accurately identify all the essential inputs. Therefore, high focus on documenting the inputs is most critical.

Unfortunately, the majority of BAs are not aware of the need for proper input/output analysis. And you can not blame them; just look at the currently "hot" functional analysis techniques. With graphical Use Cases and Activity Diagrams, the BA pretends that inputs and outputs don't exist.

With BPMN and the like, if inputs and outputs are given consideration, the are documented on the same diagram as are flow of control, sequencing, timing and other stuff. This violates the analysis principle, as Yourdon used to say "If you want to know anything, you must not try to know everything - at least initially".

To the article, I'd have to agree that there must be good collaboration between the BA and members of the technical team. I would also add that the best scenario is most likely an overlapping one in which testing and technical team members are active participants in requirements elicitation while the BA is very visible during design, construction and testing in order to efficiently transfer knowledge.

The article seems to profess that it is tools that form better communication for teams by enabling them to work better together. While tools do provide capabilities, it should not be forgotten that if communication and collaboration are poor to begin with, the results of adding tools can exacerbate the problems. Discipline should be in place first. The other thing I noticed is that there really isn't a promotion of core communication here, but rather using a tool to share pictures that multiple people can see and work with. Only core, basic communication will elicit solid requirements that manifest in design and construction.

To Tony's comments, I can't see how you think that UML diagramming ignores inputs and outputs. In fact, use cases properly written account for it very clearly. Input/Output analysis is critical, and I think that the strength of UML is that it provides multiple perspectives of the same problem statement, with each view delivering specific types of content visuals. Whether BPMN or UML or crayons on napkins, a good BA knows never to use one method by itself, as that risks blinding oneself to a potentially critical view.

DougtheBA:

Graphical models need to be used to flush out the essential inputs and outputs. Only by use of graphical models do the "holes" in our input / output analysis become glaringly evident. Because inputs and outputs are not identified on graphical use cases, there is no real check on the rigor of analysis that went into the supporting written material.

When we don't use graphics to flush out the inputs / outputs, we are not sure of what we have, as written text by it self will have alot of holes in it that are not obvious.

A wide variety of tools is handy - provided that the tools address the essential (UML diagrams don't) and address them in a realistic way (BPMN doesn't).

Tony