Business Requirements
We have made it yet another month and to yet another episode in the continuing saga known as TSQL Tuesday. This month we are being hosted by Steve Jones ( Blog | @Wayoutwest ) of SqlServerCentral fame. Steve has asked us to speak a little bit about business requirements, interpreting those requirements, and some of the pitfalls that may or may not exist in the whole communication process of getting a project done. Now, can somebody please explain the requirements for me?
What issues have you had in interacting with the business to get your job done?
I think a common area that is easily overlooked when it comes to requirements and interpretation of requirements is report creation. A common problem is that there are no defined or written requirements for the creation of a report. When there are inadequate requirements, it is easy to miss the intention of the report and thus frustrate the business group that requested the report. Another problem that can arise is the perceived inaccuracy of a report – even when all business requirements are properly met and signed off by the requesting business group. How can that be? Let me explain.
Perceptions
A recent problem was brought to light that revolved around the creation of two similar reports. The reports were to be used by different business groups and each was requested by a different group. The values in the reports no longer match due to a change requested on ReportA by GroupA. GroupB doesn’t think this is accurate and wants both reports to match. Small problem is that both reports should not produce the exact same results based on requirements and usage. The report for GroupA has some extra requirements and filters placed on it to prevent the users from seeing data about former employees. The report for GroupB is different in that it should show an overall summary for all data, even data of former employees.
Re-Alignment
Managing business requirements is almost as much about managing the perceptions of the business users as it is understanding what the business truly wants. It is important that you are able to help them understand what it is you will be doing, what you can accomplish, when you can do it, and what impact it may have on other business parts (if they are known). When an issue arises, it is best to approach the business and try to understand what the disconnect is. In the case of the example of two reports outlined, I had to research and test both reports to get a better understanding of what the problem was. Once I did that, then it was a matter of explaining the findings to the business. From there, a discussion between business analyst and the two departments for which the reports serve needs to take place and an agreement made.
Conclusion
This is a rather short and straight-forward entry for this month for TSQL Tuesday. This is a delicate subject and I am sure many people will have many more tales to tell. I think it is most important to approach the business and try to help them understand what you understand from the requirements and get it hammered out before too much development has been done.