Requirements gathering for report development are one of the lesser talked about topics
that are really key to successful report development projects and general company-wide
acceptance for them as a whole. Sometimes report developers get lucky and have the
requirements spelled out for them. But let's be honest, are those types of requirements
ever fully complete or correct? Most of the time they aren't unfortunately. That's why
doing a full requirements gathering discovery process is fundamentally important.
Below are steps that will help with the requirements process for successful report design
and development.

Step 1: Profile the data. If you don't know the data your users certainly won't. Understand
the schema, data-types, relationships, anomalies, and business rules of the data. Get into
SQL Management Studio and run some queries. Pick around in the data and flesh out
hierarchies and groupings.

Step 2: Document the data. This will include documenting schema, relationships, data-types,
and table sizes. I find it helpful to put this type of data in an Excel spreadsheet.

Step 3: Interview the eventual end-users of the reports you will create. You will want to ask
them their understanding of the system and the data it contains. Their interpretation of the
data may be completely different from what actually exists in the model. It is your job at
this point to collaborate your understanding of the data. This will help flesh out business
rules and other intricacies of the data. Be sure to document your findings in a "living document".

NOTE: The interview process is more of an art than a science. Sure, you will ask your users
what types of fields they wish to see on the report, but this is usually just the tip of the iceberg.
You will ask them company specific things like:
     - Do you want to see these sales figures from your department only or all departments?
     - Will the end-user be able to select one department at a time, multiple, or all (total) departments?
     - Do you want to run the report by a specific time frame? (This is very common).
     - What input will the user's provide to run the report? (You are asking about parameters here).
     - Who will be allowed to see what data? (Security issues flesh out here).
   

 Step 4: Interview the Project Sponsor. This is an important step due to the politically charged
 nature of every reportin project. You will want to share your end-users interview findings with
 this person for a couple of reasons. One is that he/she may have missed something that needs
 to be included and second, he/she may not want the end-user to have certain information available.
 Often times during this process, I have presented end-user interview findings with the project sponsor
 in which the reply was, "they don't need that, leave that out".

Step 5: Do a feasibility study. Once you have acquired enough information for a full requirements
document, go back to your data and see if the requirements are doable. This process will again
flesh out any misunderstandings with the data either from your side or the project sponsors and
end users. You may find out more about the data at this point that will prompt futher discussion
with your end users and project sponsors. This is called an interation. Don't worry if it doesn't
all fall into place after the first iteration, that is common. Keep iterating through this process until
all of the kinks have been completely flushed out.
      

 Step 6: Build a Proof of Concept. Building a small proof of concept will give your project sponsors
 and end users the ability to see this as a work in progress where they can provide useful input
 along the way. During this phase, the design requirements will be initiated. These will include
 font types, font colors, font sizes, header titles, background colors, etc...

 Step 7: Keep asking questions. Staying in constant communication with your end users and 
 project sponsors will keep the project on track and ensure it's success. Developing something
 in a silo will guarantee failure.

Did you enjoy this article?
This topic and many more will be covered
in my new Reporting Services class.

Check it out, this class is awesome!
http://www.endtoendtraining.com/rs.aspx

I also do on-site training for SSIS, SSAS, and SSRS
www.PragmaticWorks.com

To view more of these articles, please visit my blog site at:

http://pragmaticworks.com/community/blogs/