From Requirements to Reality

In a December 2021 article, we talked about the process of generating the student information system (SIS) project requirements list, or the checklist of everything a new SIS must do to support the ongoing business of the university. This is our SIS shopping list.

So, we have our list, now what?

Just as a good grocery shopping list doesn’t always equal a good meal, the requirements list alone doesn’t ensure that a new SIS will function exactly as we want it to. Nor will we be creating what amounts to a simple family dinner. “This project is the equivalent of making Thanksgiving for 10,000 people,” says Stewart McMaken, the business systems analyst gathering requirements for the SIS project.

As it turns out, the requirements list is just the beginning of a multi-step process of designing and testing a new system. When making dinner for the family, you start with your shopping list, then create your meal, hopefully taste-test as you’re cooking, make adjustments as needed and then serve it to your family.

When implementing a new system, you gather the requirements, then you design the new system, you implement the design and then you test it to make sure it functions how you and your end-users expect it to, making changes and adjustments as needed. Only after all of that do you roll out the system.

Designing the System

Once you have your requirements list mostly completed (remember, requirements will continue to be added to the list all the way through the testing phase) and you know which system you will be using, then you can begin to design how that system will function.

At this point in the process, you don’t actually do any work in the new system other than learning about it. What it does, what can be changed and what can’t be changed, how its pieces connect together and how it connects to other systems.

Remember how we said that a good requirement doesn’t specify how something is done, only what must be done? The design phase is where we shift gears and start defining exactly how things are done. The project team, lead by the design architects and technical experts, begins to create a design document that lays out exactly how everything in the new system will be designed and configured.

Once that design document is completed, the design document must be checked against the requirements list to ensure that all the requirements have been met. This is a very detailed process of noting which requirement is satisfied by which design specification. This is tracked in what’s called a requirements traceability matrix, or RTM for short. (More on the RTM in a bit.)

“Inevitably when you go through that list, you are going to find something that wasn’t addressed in the design document,” says McMaken. “Either because it was so obvious that no one thought to mention it or because it was so specific that people forgot. Then you have to go back to your designers and say, ‘Hey, here’s some stuff we missed. We’ve got to figure out how to do this.’”

All of this happens before any work on the actual system begins. Only once all the requirements are accounted for in the design can the work of implementing the design begin. And once it's implemented, it must be tested before it can be deployed for general use.

Testing the System

So, you have your requirements and, at least in theory, you’ve designed and implemented a system that meets all those requirements. But, how do you ensure you’ve done everything correctly and what you’ve created will meet the needs of your users? You test, of course.

Testing is all about proving you can do what you need to do exactly how you said you’d do it. And, hopefully you’ve set yourself up for success in creating meaningful tests by creating quality requirements. “If you’ve done a good requirements list,” says McMaken, "the testing part should be easy because each requirement implicitly contains its own test.”

Thinking back to our requirement for cooking chicken from last month—the chicken must be cooked to an internal temperature of 165 degrees—it’d be easy to test that requirement. Does the new system cook the chicken to an internal temperature of 165 degrees? If it does, we’re good to go. But if not, it’s back to the drawing board to redesign our system so that it does meet that requirement.

So, for each requirement on the list, one or more tests are created to determine whether or not the new system we’ve designed and implemented meets that requirement. Sometimes one requirement may have multiple different tests because of exceptions or other special cases.

The tests are then linked to their requirements in the requirements traceability matrix, or RTM. What’s this RTM, that we’ve now mentioned twice? Basically, the RTM is an expanded version of our original requirements list.

Providing Accountability

The requirements traceability matrix (RTM) documents everything we’ve talked about until this point. It lists every requirement, or what we said the system needed to be able to do, as well as how we designed the new system to do each of those things and the tests we used to prove that the system we created could actually accomplish the things we designed it to do.

The RTM provides accountability and traceability (hence its name) to the process of implementing a system that truly meets the needs (the requirements) of its users. In a highly complex project that affects a wide range of stakeholders, such as the SIS project, the RTM is a crucial component of successful project execution.

By the time we’re ready to roll the new system out to users, we’ll be able to point to the RTM and say, “Here’s what we said we had to do and how we said we were going to do it, and here’s how we can prove that it got done.”