Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

How do you document your reports? Expand / Collapse
Author
Message
Posted Wednesday, December 30, 2009 1:54 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, February 19, 2014 12:41 PM
Points: 26, Visits: 143
I'm working on an enterprise project, and it would seem that the only thing that isn't documented is the reports. We have lists of the necessary reports, but don't really have fundamental requirements of each of the individual reports.

Ideally, I'd like some sort of flow like this.

Report Requirements - Why do we have the report, what is it used for, and what does it need to do (all the way down to parameters, grouping, sorting, calculations, etc).

Report Specifications - How the report was built against the data that is available.

Report modifications - Change requests to alter the original report requirements or just get more granular.

Until now, we have really been flying by the seat of our pants, going to the business as needed.. but then it comes back to us because we designed the report according to a few individuals that of course is disputed by other individuals. I'd like to get to a more structured process.

Also, FYI. These are very complicated financial type reports, so the level of detail is almost endless.

Any suggestions???

Thanks,
Chris
Post #840574
Posted Thursday, December 31, 2009 6:55 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, June 16, 2011 6:57 AM
Points: 126, Visits: 102
You already know (said) what you need to document. Sounds like you need the standard to follow. Come up with a structured documentation, give it to your work collegues to approve it. Once it's approved, all the work should be peer-reviewed to ensure that everybody follows the standard. If somebody didn't follow the standard, send it back until they get it right, otherwise it'll be a mess forever.

I believe that certain details of the report should be stored within the spec and kept else where (that document also should follow some sort of template).
Post #840812
Posted Thursday, December 31, 2009 6:58 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, June 16, 2011 6:57 AM
Points: 126, Visits: 102
In terms of modifications, you'll need to keep the track of the following:

1. Previous version of the report
2. Date when the change has occured
3. Person who made the change
4. Link to another document with the details why the change has been made.
Post #840814
Posted Thursday, December 31, 2009 7:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, February 19, 2014 12:41 PM
Points: 26, Visits: 143
Thanks for the reply.

I do know what is needed, however, it is quite difficult to find a balance between having enough detail and something that a business user can read, understand, and approve.

I also get sick of other requirements documents that are so "top-to-bottom" and do not make much sense until you read the whole document.

I guess I will buckle down in word to see what I can come up with. Or maybe iRise. If anyone else has had good luck with a particular product made for documentation (besides word!) please let me know.

Thanks.
Happy New Year.
Post #840821
Posted Friday, January 1, 2010 8:47 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, January 14, 2010 9:09 AM
Points: 141, Visits: 187
Here are the steps:

1. Go to Report on Report Manager

2. Click "Show Details"

3. Click "Properties" of the report you need to Export

4. Under "Report Definition", click on "Edit".

You will be able to either "Open" or "Save" the RDL file.


RAQ Report: Web-based Excel-like Java reporting tool
Post #841067
Posted Friday, January 1, 2010 12:43 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:47 AM
Points: 35,347, Visits: 31,882
chris-736523 (12/31/2009)
...however, it is quite difficult to find a balance between having enough detail and something that a business user can read, understand, and approve.


I resolved that issue a long time ago... I make the business user write such requirements and then have them work directly with the developer to ensure the report is developed correctly the first time. Saves on a huge amount of rework. It also saves on the number of reports to be created because a user knows that if they can't describe it or doesn't "have the time", neither can/do we.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #841103
Posted Monday, January 4, 2010 8:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, February 19, 2014 12:41 PM
Points: 26, Visits: 143
becklery,

Your response is quite lame. Download the RDL is your answer?

Maybe you are just trying to spam the forums with the link in your post?


Jeff,

I like your reply, that does apply for some areas of our business where individuals ask for reports, and it's quite effective at getting rid of those requests! But, my problem is that we are responsible for the report definitions for the broad reports (where it's the whole business that needs to take place in the requirements process).


Chris
Post #841531
Posted Monday, January 4, 2010 11:59 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, October 7, 2014 9:53 AM
Points: 959, Visits: 420
It may be a bit overkill, but we have 2 procedures in place:

1. we have a SSRS development sharepoint site and then we have a subsite for each major report.

a) in the main ssrs site, we have standard report information such as colors and fonts and general guidelines, templates to download, etc

b) in each subsite, we have specs for the report and a generic list of information such as who is the lead developer, who is the business owner, due dates, issues, modifications, etc

users know to use these sites and it seems to work ok, albiet, not perfect as people don't always post change requests, etc

2) we still use sourcesafe to store the rdls so that other developers can always download the latest version, etc. again, this is only as good as how well the lead developer keeps the sourcesafe file up to date. ;)

good luck.
-Megan



Post #841628
Posted Tuesday, January 5, 2010 2:35 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, November 7, 2011 6:29 AM
Points: 18, Visits: 43
Were currently contemplating a similar problem here and if your thinking the above is overkill you may think this is too!

I work in a production environment so its request, request, demand here.

Our idea for our solution is to set up an asp.net page with webpart each of which link to a report or "tool / toolset" this way through a customisation page the user can set up their own dashboard. This way the only requests are for new tools.

A small victory but a victory nonetheless.
Post #841920
Posted Wednesday, January 6, 2010 1:12 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, September 8, 2014 9:39 AM
Points: 121, Visits: 148
Depending on what you want the documentation for you may want to add some initially hidden descriptive text to each report outlining what it does. you could make this switchable so that end users can also see that information, although a complex report can end up looking messy if there are lots of detail.

Developer, DBA, Pre-Sales consultant.
Post #842582
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse