Reporting requirements are often put off until the end of the project, when all other requirements have been identified and finalized. This won’t always cause problems, but sometimes it means that you’re ignoring one of your most important users–the person paying for the system to be built in the first place.

In a few systems that I’ve worked on recently, the project sponsor’s primary way of interacting with the system has been by viewing reports. They knew about the rest of the system–the screens and transactions and web services, etc.–but the only part of the system they directly interacted with was the reports.

When they identified calculation errors in the reports, or misleading presentation of the data, they thought the entire system wasn’t working. Nearly everyone else on the project thought that the system was working pretty well but had a couple reports to clean up.

There are good reasons why reporting requirements are addressed only after everything else is completed. Most often you’re using a reporting tool or framework, so there isn’t any new reporting-related functionality to build, only data to be presented.  You can’t create the report until you have data, and there isn’t any data until the system is working, so the reports have to be done at the end.  And the most difficult and interesting part of the system might be capturing and displaying the data on the screen, or processing data from other systems, so that is where the team spends most of its time. These all make sense, but can cause problems.

So how can you address reporting requirements earlier? The best way is to identify and involve the reports user early. Treat the reports as another user interface that needs to be designed as carefully as the screens. Create report mockups in the same way that you create screen mockups and get feedback early and often from the users who need the reports.

Just as you do with screens, create working versions of reports with each build. Schedule some report development time early in the development process. Create a draft version of the key reports, and create these reports as part of every build. Ideally you’ll have some automated tests to verify that the data in the reports matches the test data that went into the system.  And you’ll know early on if the system is collecting and storing the input data in a way that can be easily output in reports. As you add functionality, the content of the reports can grow also, until they are complete.

Including reports early in the development cycle helps reduce the risk that your system is functionally complete, but isn’t storing some key data that is required for a report. Fixing a problem like this (believe me) can take a lot of time, just at the point in the project when you can least afford it–at the end.

Recent posts by Kevin

• Lightweight Requirements Management with Confluence - March 12th, 2010
• Shorter Requirements are Better - July 7th, 2009
• Use Case Discipline through Ajax - March 30th, 2009

Related posts

• Lightweight Requirements Management with Confluence It’s common for project teams to document and manage their...
• Use Case Discipline through Ajax In every article or book* about how to write use...
• Shorter Requirements are Better When writing requirements documents, it’s tempting to add more &...