لطفا منتظر باشید ...
Planning Your Report Design
Before we actually get into the technical report design, we need to spend a little time planning our report to alleviate some of the problems we might face later when we actually sit down and develop the report. Too often as developers we will create reports that we think the user will want, using all of the latest features, bells, and whistles, only to find that the end-user would be happy with something much simpler, and probably easier to read.Another problem is that a developer will often sit down and crack open the Report Designer without really knowing what the end product will look like, or considering how the end user will use what has been created. What is called for is a bit of planning before we jump right into the technical aspect of designing reports. By planning our report before we get started, we can deliver a report that meets the users' needs and expectations.If you already have a report design methodology and it works for you, please have a read over this section anyway - you may find a different way of doing things or be able to incorporate some small part of it into what you already do. In any case, there are a number of reports associated with this section available in the downloadable code for this chapter - feel free to modify these reports for your own use.
In a very basic report design methodology, there are four steps to planning a new report:
Gather Report Requirements
Perform Technical Review
Develop Report Prototype
Design Report
In most applications, reports are usually tied to a specific function or area of an application. For example, if you have created an application that is used for entering telephone sales orders from customers, chances are there will be a suite of reports tied to that function, showing sales summaries, order totals, etc. The best way to determine what these reports should look like is to actually ask the people that will be using them on a daily basis.If you are working in a large organization, you will probably have a business analyst who will interview the user, gather their requirements and then communicate these requirements back to you. If you are in a smaller organizer or, if like the rest of us, you are forced to take on a number of roles, you may gather these requirements yourself.In either case, end-user interviews are the key to targeting a report's content. Organize the interviews with the actual end users (not their supervisors, personal assistants, or others), and ask them to bring along examples of reports they currently use, or would like to use. This is your chance to find out what information they need to better perform their job. Be careful when interviewing, as users will sometimes come up with an arm length long wish list for reports they would like to see.
In the interview, the user should be able to tell you how the report is used and what decisions are made based on this information. If they can't tell you either of these things, either you are interviewing the wrong person or they really don't need the information they have asked for.
Once you have interviewed the end users, you should have a pretty good idea of what reports are required, and how they will be used. From this point, there are many different ways of documenting the user's requirements (such as user requirements statements, or use cases) but the most straightforward method is to create a formal Report Requirements document.A Report Requirements document will outline what information needs to appear in the report, how the report is used (is it interactive or run in a batch), and the general look and feel of the report. You may also create a mock-up of the report or a rough sketch of what it will look like. With your report requirements in hand, the next step in our method is to perform a technical review of the report's definition.A good place to start with a technical review is to determine the data source for this report. Most likely the data source will be a relational database, but the data could also reside in spreadsheets, text files, OLAP (OnLine Analytical Processing) data structures, and even non-relational data sources (like Exchange or Outlook folders). Once you have found the data source, you will need to dig a little deeper to determine the exact tables and views that can provide the data required. You may need to develop additional views or stored procedures to consolidate the data prior to developing a report (for speed and ease of use and reuse) and these will need to be documented as well. Again, all of this information is added to your Report Requirements document.
For the next step of the technical review, you will need to investigate whether or not the design of the report is feasible. The user may request twenty columns (when the page will only fit seven landscape) or may have based the design on an existing report or spreadsheet created by hand. Once you are more experienced working with Crystal Reports, you will begin to understand how the tool works and the kind of output that can be achieved. In the meantime, browse through some of the sample reports that ship with the product to get a feel for the types of reports Crystal can produce.Once you have completed the technical review and you understand where the data for the report resides and you are comfortable that Crystal Reports.NET can deliver the required format, it is then time to create a report prototype from your notes and preliminary sketches. This prototype can be created using Word, Excel, Visio, and so on, but should closely match the report's final layout and design. Again, another important check is to make sure that the layout and design you create can be created with the features and functionality that Crystal Reports.NET has available.A good way to determine if Crystal Reports.NET can deliver a particular format for data is to find a sample report that shows the data presented in the method you want to use or you could create a small proof-of-concept report with sample data to test the design.The prototype, combined with a formal Report Requirements document will clearly communicate what the report should look like when it is finished. It also helps gain user acceptance for the design, as they can see what the finished product will look like (even before you have opened the Report Designer). If you are working in a large team, this documentation will communicate the requirements to other report developers, so you don't actually have to brief them on every single report that needs to be developed.If you are working as a business analyst, application developer, and report developer all-in-one, it can also help you keep on track with the user's requirements and make gaining user acceptance that much easier. Once signed-off by the client, the Report Requirements is a contract, so should it turn out that the report designed isn't what the client wanted, you can point to this document and their signature on it!Finally, with the documentation and prototype in hand, it is time to actually sit down, open the Report Designer and design your report.
