Ten Rules for Great User Requirements

Who doesn’t like a good top ten list? There are websites devoted to them. David Letterman presented 4,605 on his show. My favorite was Top Ten Numbers Between One and Ten. Out of concerns over copyright infringement, I am not going to repeat it here; you will just need to guess 😉

Well, here is my list focused on software implementation. I will keep it brief as each of these items can consume an entire post of its own.

Write it down – Writing down the requirements is the first step toward alignment. The act of writing requirements forces us to boil it down to the essentials and provides a mechanism to play it back to the system owner.

Align with the business process – Unless the business process is fully understood, chances of the system adding value are slim.

Ask questions in the right way – Information gathered from the users should be about how the business works, not about software features. After the business needs are known an expert can present the options to fulfill those needs.

Show a picture – Descriptions are great, but process maps can show so much more detail. They also provide a way to ensure the entire process has been thought through.

Don’t automate a bad process – As you are understanding the business process take advantage of the opportunity to make improvements. See what the technology can do to lean out the process.

Don’t chase the shiny objects – Focus on the business needs, not the cool system features. A great tool looking for a problem to solve is a recipe for a wasteful project.

Get it signed – A formal signature confirms alignment. A need to look back at the requirements for reference confirms you are looking at the proper version.

Don’t over-design the process – No need to design for every exception. Ensure the baseline processes are covered and work out the exception handling during the implementation. If there are exceptions discussed during requirements gathering, capture them for later.

Keep the pedal to the metal – Information gets stale over time. Old discussions are forgotten or remembered in different ways. It is best to close out the requirements discussion, get them clearly written up, and signed-off as quickly as possible.

Think about the end game – A well organized set of requirements will make life much easier to track implementation tasks, prepare for system validation, and prepare for training. This is especially true if it is in the context of process maps.