9.1. A High-Level Architecture for Reporting
Remember, the initial step in any architecture effort is to understand the business requirements. The Lifecycle shows that business requirements determine the architecture, and the architecture defines product requirements. Standard report users' business requirements should determine the functionality of the tool you use.
This section begins with an overview of the high-level business requirements for standard reporting and the architectural or functional implications of each of these requirements. With these requirements as a guide, we examine Reporting Services to see how well it fits into your reporting architecture. It's important to step back to consider reporting and analysis requirements because it may turn out that Reporting Services doesn't provide all the functionality your users need. You will need to gather detailed requirements for reporting and analysis as part of the requirements definition process. The functional list we provide here is not enough for you to do a rigorous product evaluation.
9.1.1. Reviewing Business Requirements for Reporting
The real, detailed business requirements will come from the requirementsgathering process. The steps outlined in this section are not a substitute for that process. However, it's possible to identify some common, high-level business requirements for reporting. Create a mental image of your user community. The group includes people at all levels of the organization, with a broad ...
Get The Microsoft® Data Warehouse Toolkit: With SQL Server™ 2005 and the Microsoft® Business Intelligence Toolset now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.