[edited 09/08/09]
The tension typical between developers and Business Analysts is mitigated with clear responsibilities. Sometimes, the developer *is* the Business Analyst; that’s not wrong, just uncommon on larger projects where the role is usually a dedicated resource.
Let’s consider the job of a dedicated Business Analyst (BA):
- Extract: A BA determines the Requirements by extracting them from business (and government) policies and, when possible, the current or future end users.
- Anticipate: A BA casts a vision to the Product Owner so she can anticipate Requirements that are not yet needed or have not yet been considered (like security).
- Constrain: A BA constrains the user’s whims – functions geared to trends, individuals, or outdated processes – and focuses users on the core business needs.
- Organize: A BA organizes disparate requirements into correlated categories for to manage and communicate Requirements with technical, left-brained resources.
- Translate: A BA translates business Requirements into technical Requirements (not solutions); abstracting business complexity away from technical resources.
- Safeguard: A BA safeguards the needs of business and system users in the development process by verifying functionality, accuracy, and completeness.
- Simplify: A BA advocates simplicity all the time – especially in implementation, making the system useful but continually focusing on day-to-day ease of use.
- Verify: A BA knows the use cases best. They advocate the users, verify the system against Requirements, and must reject implementations that don’t hit the target.
Someone discovered you can build the acrostic SAVE-COST. I didn’t plan for that, but it’s handy. Generally, I am on the developer side of the house. But when a BA handles those eight things well, we all just get along. If you know what I mean.
Have a nice day.