HELP! Why are reporting requirements so difficult. The user seems to need to see the report before they can tell me what they need. Does anyone have any comments, suggestions to make this process easier.
Having just implemented a very complex report, I found that mockups were very helpful in explaining what was required on the reports ("a picture is worth a thousand words"). Mockups must be created carefully however, because I found they can be taken far too literally.
I can provide my own process.
1. Gather requirements through multiple question and answer sessions
-- who are the primary users of the report?
-- why is the report being developed, e.g. what is being replaced / improved?
-- What data is required on the reports?
-- What is currently not available in the existing solutions (meaning, how do they get this data today and what's missing from it)? What do they hate/like about currently solution?
2. Gather artifacts of other existing report samples
-- Sample(s) of any existing report(s) that users have used previously
-- Sample(s) of any existing worktool(s) that users are currently / have previously used
3. Examine gathered data and research reporting capabilities
-- what functionality is available on existing worktool(s) that users are currently using? (examine artifacts)
-- what technology is available to your organization -- is there something currently in place? If not, does another piece of your organization have a reporting environment available with whom you can piggyback, or gain insight? Otherwise, may need to go outside of organization (forums, etc.)
-- where will the final product live?
4. Wireframe your report and share with Stakeholders in a "MockUp Dev Session" session
-- do a simple black-and-white wireframe outline of your initial report -- this is very preliminary. (hint: do a Google image search for "wireframe examples" for a variety of wireframe examples) Don't worry about presentation at this stage -- this is a visual way to get across the requirements.
-- share the Wireframe with your Stakeholders in a special session to lay out the pieces of the report. You can do this via Photoshop while conducting a WebEx/NetMeeting/Online Communication tool of your choice; or, if you can gather people in one room, sketch this out on a Whiteboard; or, you can develop your wireframe in Visio and send out via e-mail. (I prefer option 1 because often, the wireframe gab session results in a good working solution and it's already in a portable format that I can re-use.)
5. Flesh out your wireframe in Photoshop/Gimp/photo editing tool of your choice (optional)
-- examine your company's UI guidelines for web pages (if available): logos, headers/banners, colors, etc.
-- if you have the design skills, or know someone who does, take the ideas from your Wireframe and createa nicer layout, taking into consideration any UI design decisions from above
6. Draft the written Spec document and embed your Wireframes here
-- My own report was several reports in one, output to a single format, so it's broken down a bit differently, but here are some items to consider.
Project Overview:
-- Background
-- Prototype (any existing solution, where idea came from, e tc.)
-- Business Benefit
-- Affected Areas
-- Out of Scope
-- Terminology
Requirement-Spec 1: General Requirements
-- report format (landscape / portrait)
-- number formatting
-- how to fail gracefully
-- what to display if data not available
-- Colors used
-- Who sees the report
-- Fonts used
Requirement-Spec 2: Input Parameters
-- Fields required to produce report (table useful)
-- Default settings for input controls
-- Any special text required here for user feedback
Requirement-Spec 3: Page headers / footers
-- Header elements common to all pages
-- Footer elements common to all pages
-- Logo
-- Report Title
-- Report Dates (beginning / ending dates show?)
-- Separator Lines for breaking up content
-- Text positioning (e.g. left-justified, centered, etc.)
-- Page numbering (consecutive or other?)
Requirement-Spec 4: Report 1
-- Column placement
-- Rows separated by alternate rows shading?
-- Are columns labeled?
-- Where is data pulled from? (may require mapping document in Appendix A)
-- Can report section break across pages?
-- Column heading font
-- Data font
-- Is line of data displayed if no results returned?
-- Spacing between rows
Requirement-Spec 5: Report 2
....
Requirement-Spec 13: Export Format(s)
-- PDF, XLS, etc.?
-- If no data available for a column, what goes here? (zeroes or empty)
Requirement-Spec 14: Report Availability
-- who gets the report
-- how is the report triggered / where can it be found?
+ Operational Requirements
+ Appendix A
-- an Excel spreadsheet could be used here to map each data element. Get info from the column headers and row results...where does the data come from? Map the report outputs to the source fields on the database.
Mockups are worthwhile
Having just implemented a very complex report, I found that mockups were very helpful in explaining what was required on the reports ("a picture is worth a thousand words"). Mockups must be created carefully however, because I found they can be taken far too literally.
I can provide my own process.
1. Gather requirements through multiple question and answer sessions
-- who are the primary users of the report?
-- why is the report being developed, e.g. what is being replaced / improved?
-- What data is required on the reports?
-- What is currently not available in the existing solutions (meaning, how do they get this data today and what's missing from it)? What do they hate/like about currently solution?
2. Gather artifacts of other existing report samples
-- Sample(s) of any existing report(s) that users have used previously
-- Sample(s) of any existing worktool(s) that users are currently / have previously used
3. Examine gathered data and research reporting capabilities
-- what functionality is available on existing worktool(s) that users are currently using? (examine artifacts)
-- what technology is available to your organization -- is there something currently in place? If not, does another piece of your organization have a reporting environment available with whom you can piggyback, or gain insight? Otherwise, may need to go outside of organization (forums, etc.)
-- where will the final product live?
4. Wireframe your report and share with Stakeholders in a "MockUp Dev Session" session
-- do a simple black-and-white wireframe outline of your initial report -- this is very preliminary. (hint: do a Google image search for "wireframe examples" for a variety of wireframe examples) Don't worry about presentation at this stage -- this is a visual way to get across the requirements.
-- share the Wireframe with your Stakeholders in a special session to lay out the pieces of the report. You can do this via Photoshop while conducting a WebEx/NetMeeting/Online Communication tool of your choice; or, if you can gather people in one room, sketch this out on a Whiteboard; or, you can develop your wireframe in Visio and send out via e-mail. (I prefer option 1 because often, the wireframe gab session results in a good working solution and it's already in a portable format that I can re-use.)
5. Flesh out your wireframe in Photoshop/Gimp/photo editing tool of your choice (optional)
-- examine your company's UI guidelines for web pages (if available): logos, headers/banners, colors, etc.
-- if you have the design skills, or know someone who does, take the ideas from your Wireframe and createa nicer layout, taking into consideration any UI design decisions from above
6. Draft the written Spec document and embed your Wireframes here
-- My own report was several reports in one, output to a single format, so it's broken down a bit differently, but here are some items to consider.
Project Overview:
-- Background
-- Prototype (any existing solution, where idea came from, e tc.)
-- Business Benefit
-- Affected Areas
-- Out of Scope
-- Terminology
Requirement-Spec 1: General Requirements
-- report format (landscape / portrait)
-- number formatting
-- how to fail gracefully
-- what to display if data not available
-- Colors used
-- Who sees the report
-- Fonts used
Requirement-Spec 2: Input Parameters
-- Fields required to produce report (table useful)
-- Default settings for input controls
-- Any special text required here for user feedback
Requirement-Spec 3: Page headers / footers
-- Header elements common to all pages
-- Footer elements common to all pages
-- Logo
-- Report Title
-- Report Dates (beginning / ending dates show?)
-- Separator Lines for breaking up content
-- Text positioning (e.g. left-justified, centered, etc.)
-- Page numbering (consecutive or other?)
Requirement-Spec 4: Report 1
-- Column placement
-- Rows separated by alternate rows shading?
-- Are columns labeled?
-- Where is data pulled from? (may require mapping document in Appendix A)
-- Can report section break across pages?
-- Column heading font
-- Data font
-- Is line of data displayed if no results returned?
-- Spacing between rows
Requirement-Spec 5: Report 2
....
Requirement-Spec 13: Export Format(s)
-- PDF, XLS, etc.?
-- If no data available for a column, what goes here? (zeroes or empty)
Requirement-Spec 14: Report Availability
-- who gets the report
-- how is the report triggered / where can it be found?
+ Operational Requirements
+ Appendix A
-- an Excel spreadsheet could be used here to map each data element. Get info from the column headers and row results...where does the data come from? Map the report outputs to the source fields on the database.