T-SQL Tuesday #13 – Business Requirements

Comments: 1 Comment
Published on: December 13, 2010

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.

1 Comment - Leave a comment
  1. […] is the area where Jason Brimhall has found confusion in different departments wanting separate reports, but then somehow having them […]

Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">








Calendar
December 2010
M T W T F S S
« Nov   Jan »
 12345
6789101112
13141516171819
20212223242526
2728293031  
Content
SQLHelp

SQLHelp

  • @tradney: @zahirmohideen There will always be some SQL files on C:,you can't change, however you can specify a diff drive for most else. #sqlhelp
  • @zahirmohideen: How to avoid any install files ( including essential ) in c: drive ( system drive) ? . I am installing sql binary in other drive #sqlhelp
  • @DBArgenis: @EnlightenData I would never try to schedule those two at the same time, though. Bad idea in general. #sqlhelp
  • @DBArgenis: @EnlightenData incorrect. Backups don't take table locks. #sqlhelp
  • @EnlightenData: I assume an index REBUILD would block a FULL database backup from continuing due to a table lock. Correct? #sqlhelp
  • @meyer_tom: seems that an Alert for message 1480 will only fire if set to <all databases> and not just one. Expected behavior ? If so, why ? #sqlhelp
  • @Dan_Doucet: #sqlhelp wondering if removing a column from an existing non clustered index requires downtime? Table would have about 6million rows
  • @SQLSoldier: @EnlightenData Long running transactions keeping really old versions in tempdb. #sqlhelp
  • @SQLSoldier: @EnlightenData Sufficient space for versioning in tempdb. Very wide rows that don't have room for the version pointer (14 b). #sqlhelp
  • @Chris_Kasten: Details: users are running an old .NET app from their workstations. App hasn't changed in years. No maint on the server in weeks #sqlhelp

Welcome , today is Thursday, January 29, 2015