Requirement vs. Solution Architect

From most of the projects that i have involved, there's always conflict of interest between a BA, SA or a Solution Architect. A lot of times, there's thin line between each role and if the expectation is not being managed correctly, job responsibilities, the so called "ideal" solution architecture may varies, and i mean WAY different from what is captured from the business point of view.

HOWEVER, i enjoy working with them, in which people from different background see requirements in different angle, in which this can further empower how a requirement should be written and support with other necessary documents, i.e reports, chart,draft flows, etc. How bad could it go? Let's see the famous chart that portaying how requirement is being captured, "ASSUME" and documented below, which i think is really appropriate.


and of course, what customer really wants is:

I have learned something over the years, there's a couple of scenarios may occur when a requirement gathering, or analysis went too wrong:
1. A new feature evolve!!
2. A feature the customer will NEVER use!
3. A Bug that would never SOLVED! and the customer needs to work around it.

I also learn to accept and "negotiate" for what the idea and concept is presented. A lot of times, I will try to iterate the requirements by draft out the high level screen flows (Which may not be same like what SA will draw), but just to keep a common understanding between the team members, and the customer ... and how the document should be written (hey i won't want to write something that we can't even deliver!). So then i found some hot approaches are pretty useful, i.e RUP!

note: i know the artifacts are crazy! and time always the issue in SDLC!