Hello,
I'm hoping for some input regarding what people have found successful when documenting reports. I've seen both ends of the spectrum: detailed functional and technical specifications, versus documenting the report in the .rpt object itself with a text field containing the Report Selection criteria or the SQL statement WHERE clause. I'm personally not supportive of either extreme. Often the detailed, lengthy specs take longer to create than the actual report and are not maintained over time. On the other hand, using query language seems woefully inadequate (no information regarding required columns, layout, formatting, etc) and is difficult for the average user to understand.
Using 3rd party documentation tools is not an option because much of our business logic is embedded in database stored procedures which are either the report datasource or create summary data-mart-like tables.
Any thoughts, suggestions, or examples are greatly appreciated!
~E
I'm hoping for some input regarding what people have found successful when documenting reports. I've seen both ends of the spectrum: detailed functional and technical specifications, versus documenting the report in the .rpt object itself with a text field containing the Report Selection criteria or the SQL statement WHERE clause. I'm personally not supportive of either extreme. Often the detailed, lengthy specs take longer to create than the actual report and are not maintained over time. On the other hand, using query language seems woefully inadequate (no information regarding required columns, layout, formatting, etc) and is difficult for the average user to understand.
Using 3rd party documentation tools is not an option because much of our business logic is embedded in database stored procedures which are either the report datasource or create summary data-mart-like tables.
Any thoughts, suggestions, or examples are greatly appreciated!
~E