Getting Your Banner Black Belt, Lesson Two: Use Good Requirements Documents
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’m here to assure you, it’s not. This article is the second in our Getting your Banner Black Belt series, and today we’re going to talk about one simple step that will make your reporting life a thousand times easier: using good requirements documents.
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 graphics, charts, graphs, etc.?
Once you have good answers to those questions, you’ll have a pretty good idea of what the end user needs. But just knowing what questions to include won’t necessarily make your requirements documents successful. The other factor you’ll need to take into account is, of course, the human one. Let’s walk through a quick example:
Say that Sally, the registrar, sends me an email asking for a “Student Hold Report.” Armed with a fresh copy of my requirements document, I set out to clarify her request and get some detailed specifications. I start by asking Sally what exactly she has in mind, when she says “students with holds”. We go back and forth for a while, until we have a much more specific definition of her population. In the end, instead of “students with holds,” the population section of my requirements document 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. When discussing the output, it’s important to be on the lookout for anything that’s going to be particularly complicated (read: time-consuming) to produce, so you can let the requester know about it up front. 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 and will take more time. I explain the situation to Sally and give her the option to skip the course names, so she’ll haven the report more quickly, or include them and have to wait a little longer.
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 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, my first step is to ask if she needs anything beyond a simple list of the data she’s requested. (With an operational report like hers, that’s often all that’s needed. Analytical/strategic reports are more likely to include graphics and charts.) We have a quick discussion in which she sketches out her layout needs. I 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 me feedback, and we determine exactly how she’d like the final report to look. With my nicely fleshed out requirements document in hand, I’m ready to get to work on the real thing.
Of course, working on the real thing means getting up to your elbows in SQL. Fortunately, in the next installment of our Getting Your Banner Black Belt series, we’ll talk about some eminently useful shortcuts and tricks of the trade that make writing complicated queries faster and easier.
In the meantime, do you have any advice for making your requirements documents more effective? We’d love to hear it! Please share with us, in the comments section below.
Latest posts by Zach Heath (see all)
- Best Practices for Designing OLAP Cubes - 05/01/2014
- Deconstructing Business Intelligence & Analytics for Higher Ed - 12/04/2013
- Configuration Tips for Improving your Data Security - 08/15/2013