Tuesday, January 19, 2010

Business Analysts and Software Developers

Of all the relationships within a software development organization, the one that seems to cause the most friction is the one between the business analyst and the software developer. I find this is often caused by a lack of understanding about who is responsible for what.

A BA where I'm currently working spelled it out best in a meeting a while back (Brian D). In our organization, the business analysts own the "who, what, why, where, and when" and the developers own the "how".

Not sure how this maps into other people's organizations, but it seems to be a good starting point. Very often I read requirements with a lot of "how" in them.

Examples of this sort of thing include:

  • Create a web service to enable validation of item information

  • Build a screen with 4 fields (create date, last modified date, historical cost, deleted flag

What I would expect, as a developer is something more like:

  • We need to be able to run the mainframe part validation routines against part data submitted from third parties

  • We need to display item information to our sales users... critical information they need to understand includes when the item was created, when it was last modified, what it cost before the last modification, and an indication if the item is currently able to be sold in our retail outlets

These examples are a little more verbose (thought they don't need to be), but also decouple the implementation (how) from the problem (why) and free the development team to explore alternative solutions. Perhaps instead of SOAP/WSDL web service, posting XML via HTTP is better... or maybe just FTPing a file is best... In the second example, perhaps it's best to just show an iconic indicator of if the item is active or not (versus a boolean flag). In addition, instead of simply naming the fields that should be displayed, the intent (why) and audience (who) of the page is better explained.

No comments: