The SIS Shopping List

Replacing our student information system (SIS) may seem like a daunting task. After all, the SIS touches nearly every aspect of business at the university in some way, large or small, directly or indirectly. On a project with such a large scope and with so many different stakeholders, how do you even begin to understand what’s required to be successful?

For Stewart McMaken, a business systems analyst working on the SIS project, the answer is simple: a list. “It stops being overwhelming when you have a list,” he says. In this case, he’s referring to the list of requirements for the project.

“It’s the same as making a grocery list,” he says. “Every time I go to the grocery store and I think I know everything I need and I don’t need to make a list, I leave without one or two things. Every time.” We certainly don’t want to finish the SIS project with anything missing and so we’re working on our own SIS requirements shopping list.

What exactly is a requirements list and how does it help get us closer to successfully launching a new SIS?

Specific, but Not Too Specific

At its most basic, a requirements list is a checklist. A very long, very specific checklist of everything the SIS must do to support the ongoing business of the university. When a solution can meet all of the requirements on the list, we will know it’s ready to be deployed.

McMaken defines a requirement as, “a description of a feature that a system has to have to succeed.” It’s a pretty simple definition, but writing a good requirement can be difficult. That’s because well-written requirements must be definitive, unambiguous and verifiable. Even more importantly, they must describe what is needed, but not how it is to be done. Not specifying how something must be accomplished is often the difficult part.

For example, to write a requirement for cooking chicken, rather than saying the chicken must be cooked in an oven for 15 minutes in order to be ready to eat, you would instead specify that the chicken be cooked to an internal temperature of 165 degrees. You leave the specifics of how that happens (in an oven, in an air fryer or over a campfire) out of the requirement.

Writing a good requirement takes skill and a great deal of inquisitiveness. It requires being able to understand and to discover not just what is happening, but why it’s happening.

Asking the Right Questions

If you have participated in any meetings related to the SIS project, you may have noticed McMaken in the meeting. Even if he doesn’t speak up, he’s always listening for anything that sounds like a new requirement that needs to be added to the list. If he hears something, he’ll jump in and ask a few key questions.

Why do you do that? What would happen if you couldn’t do that or didn’t have that feature? Do you really have to do that? Sometimes he’ll ask “why” a number of times. When pressed to explain the purpose behind asking “why” so many times is important, he shares a joke.

“There’s this old corny joke where this guy is teaching his daughter how to cook a ham. And he says, ‘The first thing you do is cut three inches off the end of the ham.’ The daughter asks why you have to cut off three inches first,” says McMaken. The daughter, he explains, is unsatisfied with her father’s explanation that that’s simply how a ham is cooked. She asks successive generations of family members why, until her great-grandmother explains that a ham wouldn’t fit in her tiny oven without first cutting off three inches.

McMaken laughs then adds, “We have so many things like that, where people are cutting off three inches because of a system constraint that hasn’t existed for 10 years.” The business process analysis work of the SIS project is the perfect opportunity to uncover these areas where a constraint that no longer exists has been fossilized into a process.

And, as with the girl in the joke, sometimes you have to ask “why” a few times before you get to the root of the issue. That’s a key part of the requirements gathering process. Listening and asking questions, even sometimes asking the same question multiple times.

Checking All the Boxes

Requirements and the process of gathering requirements allow us to have a productive conversation about the future system, even without knowing what that future system is. That’s the key reason beyond not specifying how something must be done. One SIS may accomplish a requirement in a certain way, while another SIS may achieve the same thing in an entirely different way. 

But, that’s also why the requirements list must be very detailed and very specific. As long as a system meets our requirements, then we know it can do what we need it to do, regardless of how it does it. “If it checks off all your boxes, then it flies,” as McMaken says. 

The requirements list also helps with the decision-making process. While there may be many possible solutions that seem to meet all our needs, once those solutions are thoroughly tested and vetted against the requirements list, there may be only one solution that actually does everything we need it to do. So, that’s the right solution.

At the time of the writing of this article, there are 618 requirements defined for the SIS project. McMaken, however, expects that there will be closer to 850 by the conclusion of the project. “You are never done. We will be adding requirements all the way into [the testing phase of the project],” he says.

The next time you participate in an SIS meeting, if you see McMaken or if you hear him jump-in to ask, “Why?” remember that he’s working on building the long, detailed shopping list that’s a key part of ensuring the new system does what we need it to do.

And, the next time you go grocery shopping and forget something, you can’t say we didn’t tell you that the only way to make sure nothing gets missed is to make a list.