You’ve heard the expression “first things first”? It sounds obvious, but as you’ll see, we can’t take anything for granted or assume things will get done as expected unless we take pains to spell out the necessary steps.

To start with first things first, it’s very important to get a good list of the requirements of whatever your report or application is supposed to do. This list is your blueprint. Because without the requirements, you really have no idea what to build or what the report is supposed to show.

This requirements step in the development of a solution is critical to the success of the solution and helps avoid many problems in the overall development process. Many projects don’t succeed as well as they could or fail completely because the requirements are not gathered properly or at all.

The usual way to gather the requirements is to talk to the user or the data consumer. Another common method is to assume that you know what the user or data consumer wants. But this method can lead to lots of problems. Talking to the data consumer is the right approach, but can be difficult to accomplish for a variety of reasons.

What we know about the data consumer:

• Generally not a technical person in the IT department or may not be computer savvy.
• Knows the application (possibly Ellucian Banner) and their work area very well.
• Knows how information flows in their area and what the important pieces of information are and what should be in a report.
• May be unfamiliar with the field names, the tables and how to present the information.
• Will have excellent ideas on what information they need to accomplish their job.

It is important to approach the data consumer in a neutral manner. Too many technical terms or jargon can be alienating. The technical aspects of various reporting tools are very cool and fascinating, but not to the data consumer; they couldn’t care less.

Speak The Same Language

Learn to speak the language of the data consumer or at least have a passing understanding of what they do and how their job is performed. The requirements must be gathered in the language of the data consumer, which generally requires some work from the technical person or project manager. The data consumer won’t know or care about the technical aspects of the reporting tool or language that will be used for the project. Many times when these items are discussed it only leads to confusion on the part of the data consumer. Better to leave out the technical discussion.

When To Present Solutions

The time to present a solution to the data consumer is not when you are gathering requirements. You can develop a solution once you have the requirements, but presenting a solution first is usually bad form. It can be very off-putting to end-users to be told how to do their job from someone outside the organization. Plus, it defeats the purpose of gathering requirements. You won’t succeed with this approach.

Now, the data consumer may want to talk about the technical details and may feel that they have a good grasp of the technical issues and how to solve them. But this is a trap! Don’t fall in. You are the technical expert and will make the technical decisions later on. To gather the requirements, remember to put the technical details aside and talk in the data-consumer’s language. Get the consumer to talk about what is needed and why, not how to present it. Have the person explain the importance of the report in terms of their area or department and how other people will be using the report once it’s complete.

Avoid Assumptions

Don’t make assumptions when speaking with your data consumer. Although it may seem obvious that a student’s name is presented as First Name–Last Name, this assumption can lead to lots of re-do work later on. Be sure to verify the format of the data with the data consumer. Even the most obvious sections should be verified to avoid problems later on in the development of the report.

Ask Questions

Ask your data consumer a lot of questions, such as:

• What are you going to do with the data?
• How do you use the report in your job?
• What pieces of data are more important than others?
• How do you like to see data presented – tabular, bar chart, etc.?
• Who is going to execute the report?
• Are you comfortable using an application?
• Are there calculations that need to be done to the raw data?
• If so, what are those calculations and what are they for?
• How often is the report run?
• Who views this report besides yourself?
• Are there any color issues that need to be handled – such as a colorblind reader, or whether school colors must be used?

By asking such questions, you’ll help the data consumer feel more at ease talking about the report, especially if they’re not comfortable technical discussions (which should be avoided anyhow). The answers to these questions will help you better understand what the consumer wants in and from the report, while increasing your knowledge of the activities and priorities within the data consumer’s department.

Cut Scope Creep

State the requirements that you get in English sentences so that the data consumer can read them and agree to them. The reason for this is to try to eliminate scope creep as the project evolves. The use of diagrams or images to illustrate what the end result may look like can also be very helpful. Keep in mind that the data consumer may not be able to accurately picture the result, even with several diagrams of the proposed report.

Match Requirements With Requests

At this point, you should have the report requirements and a good list of statements that can be turned into technical requirements. Note that it’s important to be able to map the technical requirements to the requirements to which the data consumer originally agreed; this way, you’ll know when you are finished. You may need to go back to the data consumer with some mock-ups or prototypes and see if those meet the intent of the original requirement.

Again, it’s important not to assume that you know the best method for the data consumer, even though you may be the technical expert. You can show different styles and approaches to answering the questions posed by the data consumer, but remember that the ultimate arbiter of success is the consumer.

Keep in mind that just because you collect the requirements and build something, it may not necessarily fulfill the data consumer’s request. Consumers don’t spend time writing requirements so they can’t always visualize the result. You may need another phase of development to refine or rework parts of the project and address the consumer’s requests. The good news is that if the requirements are gathered using the suggestions listed above, the rework shouldn’t be extensive.