On one of the Tech forums I was reading the other day, someone asked "Have you ever been a part of a project where a Business Analyst (BA) did anything remotely productive?" Why yes, yes I have. Unfortunately, while this question displays the divide between IT and the business it is supposed to be supporting, the ratio of respondents nodding their heads in agreement to those who actually admitted working with a decent BA shows the extent of this divide.
In my consulting role, I have seen both sides of a client growing from a small department of programmer analysts (PA) to a large IT shop of BAs and Software Engineers (SE). The transition to enterprise application development pointed out for me the difference between the traditional PA analyst role and the BA analyst role. And in my mind it pointed out the problems that can accompany the PA analyst role. The BA is a business role first, and a technical role second. His job is to collect business requirements and verify that the final product meets those business requirements. The BA does no programming, and is not responsible for providing technical design of the IT business solutions being provided. A good BA may not be terribly technical but frequently comes from a help desk background. He has enough technical experience to talk to the SE, but more importantly has the people skills to talk to the business about their needs. On the other hand the PA is typically a senior programmer, a technician first, who has learned something about business. Problem is, this guy typically comes at a problem differently than the business person. His first priority is finding the problem, and designing a solution. When talking to the business representatives, the PA will frequently talk in design terms with the business, and frankly, the business doesn't, or shouldn't care if the application is using optimistic or pessimistic locking. They do care that the users are able to do their work efficiently as possible.
Business requirements are not detail design specifications. They aren't data design specifications. They aren't even high level design specifications. Business rules state that the Customer number must be unique, not that the customer number is the primary key of the customer table. Business rules state that an invoice may not be created for an inactive customer. They don't state how that is going to be accomplished. Design specs are the SE team's responsibility. And that is a different story.
In my consulting role, I have seen both sides of a client growing from a small department of programmer analysts (PA) to a large IT shop of BAs and Software Engineers (SE). The transition to enterprise application development pointed out for me the difference between the traditional PA analyst role and the BA analyst role. And in my mind it pointed out the problems that can accompany the PA analyst role. The BA is a business role first, and a technical role second. His job is to collect business requirements and verify that the final product meets those business requirements. The BA does no programming, and is not responsible for providing technical design of the IT business solutions being provided. A good BA may not be terribly technical but frequently comes from a help desk background. He has enough technical experience to talk to the SE, but more importantly has the people skills to talk to the business about their needs. On the other hand the PA is typically a senior programmer, a technician first, who has learned something about business. Problem is, this guy typically comes at a problem differently than the business person. His first priority is finding the problem, and designing a solution. When talking to the business representatives, the PA will frequently talk in design terms with the business, and frankly, the business doesn't, or shouldn't care if the application is using optimistic or pessimistic locking. They do care that the users are able to do their work efficiently as possible.
Business requirements are not detail design specifications. They aren't data design specifications. They aren't even high level design specifications. Business rules state that the Customer number must be unique, not that the customer number is the primary key of the customer table. Business rules state that an invoice may not be created for an inactive customer. They don't state how that is going to be accomplished. Design specs are the SE team's responsibility. And that is a different story.
Powered by Compendium Blogware
Comments for Business Requirements are not Design Specifications