Learning the ropes of Banner reporting can be a challenging process. There is so much data to work with, so many metrics to track, and so many purposes to be served. But even if mastering such a powerful tool can feel impossible at times, I can assure you it’s not. This article is the second in our Getting Your Banner Black Belt series. (Read part 1 here.) We’re going to talk about one simple step that will make your reporting life a thousand times easier: using good requirements documents.

Report Requirements – The Basics

Sometimes called a report request sheet, a requirements document is simply a form used by report designers to collect information about each report request that comes in. It may seem obvious, but the difference between using good requirements documents and using bad requirements documents (or worse, none at all) can be substantial.

To ensure that your report will meet the requirements of the requester, you need to be able to answer the following three questions:

• Population: What attributes or characteristics define the group of things (people, transactions, awards) that will be included in the report?
• Output: What pieces of information about that population will be displayed on the report?
• Layout: How should the information be arranged? Is a simple list or table-style output sufficient, or will the report need charts, graphs, etc.?

Once you have clear answers to those questions, you’ll have a pretty good idea of what the end user needs.

Report Request – A Walk-through

But just knowing what questions to include won’t necessarily make your requirements documents successful. Let’s walk through an example:

Say that Sally, the registrar, sends you an email asking for a “Student Hold Report.” Armed with a fresh copy of the requirements document, you set out to clarify her request and get some detailed specifications. Start by asking Sally what exactly she has in mind when she says, “students with holds.” If you need to, go back and forth for a while, until you have a much more specific definition of her population. In the end, instead of “students with holds,” the population section of the requirements document now reads: “Students registered for a selected term that have active, transcript holds.”

So, you can see that even well-organized requirements documents don’t guarantee you’ll get the information you need the first time around. The document allows you to gather the initial information and build off of it as necessary. A good practice is to include example answers to the questions on the document, so the requester can see the kind of details needed. This helps eliminate some of the back and forth discussion.

Time and Complexities

When discussing the output, it’s important to be on the lookout for anything that’s going to be particularly complicated or time-consuming to produce. Let the requester know about it up front. Another tip is to consider the readability of the output. This is generally where the complexity is introduced. Let’s go back to our example with Sally for a minute:

Sally wants to see the student’s name, their ID, the start date of each transcript hold they have, and what the hold is. So far, pretty simple. But remember one student can have more than one hold. So, say that, Sally decides she also wants to see the courses the students are registered for in the selected term. Here, things get tricky. If a student has 10 classes and 3 holds, a standard SQL query will produce 30 rows for that one student, which yields a very difficult-to-read report.

Creating a readable report with those specifications is possible, but it requires some complicated coding to avoid the 30-rows-per-student problem. It will also take more time. Be sure to explain the situation to Sally and give her the option to skip the course names, so she’ll have the report more quickly. (Or include them with her understanding she’ll need to wait a little longer.)

Layout of the Report

Having the population and output worked out means you’re about 90% done. Determining the layout requirements for a report tends to be the easiest and the quickest of the three steps. Often, the desired layout has already been defined – a requester will come in with an old report they’re looking to update or recreate with the current reporting tool. Other times, you can ask the requester to make a mockup of how they’d like the report to look, using Word or Excel.

But let’s say, as in the case of Sally, that the requester doesn’t have a clear picture of how they want the report to look:

Since Sally is in a rush with this report, the first step should be to ask if she needs anything beyond a simple list of the data requested. (With an operational report like hers, that’s often all that’s needed. Analytical/strategic reports are more likely to include graphs and charts.) If needed, have a quick discussion in which she sketches out her layout needs. Then, use her guidelines to mock up an example of the report in Balsamiq  or another mock-up tool.

Using the mockup as a starting point, Sally gives you feedback, and together you determine the final look of the report. With the nicely fleshed out requirements document in hand, you’re now ready to get to work on the real thing.  

What’s Next?

Of course, working on the real thing means getting up to your elbows in SQL. Fortunately, in the third (and final) installment of our Getting Your Banner Black Belt series, we’ll talk about some useful shortcuts and tricks of the trade that make writing complicated queries faster and easier.

For even more information on report requirements and the report request process, check out these other blogs:

How to Gather Requirements and Solve Problems

The Process: It’s Not Just for Acting (It’s for Reporting Too!)

Juggling Priorities And Ranking Report Requests