Messages

I just want to share with you all that of all the lists I've been on over the past nearly 15 years, this thread about BAs and IAs has truly been the most informative and interesting discussion 

I've ever followed. The knowledge you are sharing has been so incredibly helpful to me and my business. Thank you all.

Dennis

[address removed]

On May 9, 2008, at 10:11 P

Jonathan Lane <[address removed]> wrote:

I agree with Ashley with the exception of designing process flow.  BA's should be expected to do those--perhaps along with the IA, but certainly under the BA's direction.

I think many times requirements gathering includes process flows.  For example, some of the stakeholders want to make sure a loan application allows the Borrower to specify whether or not they want a Co-Signer before they start filling in any contact information.  Additionally, if the Borrower says they do not want a Co-Signer and then gets denied when they request a loan pre-approval, then the system should allow them the option of adding a Co-Signer and trying again.  (Yeah, that's a real world example from my last job.)

These kinds of if/then logic paths are, in my opinion, part of the BA's job.  The flowcharts might be simple snapshots of requirements or a full maze of boxes and arrows.  But they're necessary PRIOR to the functional specs being written so that the entire team can examine the flow and agree, "Yeah, this is when the user tells us such-and-such."  Later, the IA's can elaborate in site maps and wireframes, and systems architects can take these process flows and turn them into full use cases for the programmers.  But for me as a BA, process flows are totally part of my job responsibilities.

 - Jonathan