|
|
|
Grasshopper
 
Group: General Forum Members
Last Login: Friday, February 05, 2010 2:48 PM
Points: 21,
Visits: 113
|
|
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
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 2:33 AM
Points: 126,
Visits: 99
|
|
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).
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 2:33 AM
Points: 126,
Visits: 99
|
|
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.
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: Friday, February 05, 2010 2:48 PM
Points: 21,
Visits: 113
|
|
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. 
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Thursday, January 14, 2010 9:09 AM
Points: 142,
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
|
|
|
|
|
SSChampion
Group: General Forum Members
Last Login: Yesterday @ 3:56 PM
Points: 20,164,
Visits: 13,699
|
|
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."
For better, quicker answers, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: Friday, February 05, 2010 2:48 PM
Points: 21,
Visits: 113
|
|
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
|
|
|
|
|
SSC Eights!
Group: General Forum Members
Last Login: 2 days ago @ 3:40 PM
Points: 859,
Visits: 284
|
|
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
|
|
|
|
|
Grasshopper
Group: General Forum Members
Last Login: Monday, January 18, 2010 6:16 AM
Points: 18,
Visits: 42
|
|
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.
|
|
|
|
|
Valued Member
Group: General Forum Members
Last Login: Tuesday, March 09, 2010 8:26 AM
Points: 60,
Visits: 20
|
|
| 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.
|
|
|
|
