Requirements Analysis

This article was published in the CAmagazine in July 2010.

Problem

Before replacing any system, you need to document your requirements. Obvious, right? You just have to talk to the people working with the existing system and ask them for the requirements. But that would be a huge mistake, for a number of reasons. If employees are afraid the new system will automate a big part of their job, they might be reluctant to tell the whole story. Also, they might be unable to think outside of their own box, or they might think certain tasks are not worth mentioning

Solution

There is a better way. Rather than ask employees to define their requirements, hold a business process review where they can describe their current process, including its pros and cons. That will uncover the processes that should be maintained as well as weaknesses that could lead to new requirements. By the way, it’s a good idea to get an estimate on the impact of a weakness – the time wasted because of it. This will help you decide how much attention to pay to the weakness (for example, an employee might be troubled by a rather insignificant issue that doesn’t warrant a lot of detail in the documentation). The impact could also be used to help build a business case if the problem is significant. The new system should eliminate the weakness, while generating cost and time savings. For that reason, all problems should be considered opportunities with a new system.

For the process meeting, ask employees to bring both printed and electronic versions of key forms, documents and reports. Consider writing the review documentation as the employees speak and letting them see what you’re writing. Don’t copy verbatim; focus on understanding and synthesizing. That will allow the employees to see instantly if you do in fact understand. It helps to be a fast typist but it’s not essential as you should be documenting only the key points.

Level of Detail

The biggest challenge lies in deciding on the right level of detail in your requirements, so here are some pointers. First, for the development of a custom system, you need much more detail than you do when selecting existing systems. Second, if you will be evaluating vendors that already have hundreds if not thousands of clients, don’t document basic requirements. The vendors would not be in business if they didn’t already have those covered. Third, you need to be good at synthesizing so you capture only the essence of the process. For example, you don’t need to know every person who approves a document. But you do have to understand the business rules associated with approvals – whether there are multiple sign-offs or whether approvals are based on dollar amounts. Fourth, do remember the purpose of the business process document. It’s not meant to serve as a training tool, but as a vehicle for exposing key strengths and weaknesses. The same requirements might be defined in multiple places and not grouped logically. Consider the business process review report as a working paper -- a starting point in discussing the “to-be” business process, in building a business case for improvement and in defining requirements in a vendor questionnaire

Script

With some adjustments, the business process review report can also be used as a script for potential vendors to follow in conducting their demonstrations. But if you want it to serve as a vendor questionnaire, you will need to transfer the requirements to another document where you group them into sections and subsections. For example, a requirement for the number of segments in the chart of accounts would be included in the general ledger section and setup subsection.

Requirements

When the requirements document is completed, you still need to have the requirements confirmed and prioritized. This is usually done by a group of key people who not only understand the details but know the organization’s objectives and critical success factors. They can decide what’s really important. Confirming a requirement includes ensuring it is clear. Prioritization could be something like 5=critical, 4=very high, 3=high, 2=medium, 1= low. To get through the requirements on a timely basis, you should assign one person as a spokesperson for each section. Those who disagree could express their opinion and there could be a debate.

In the end, you should have a clear, well-defined set of requirements that can be used to obtain quotes from vendors for custom development or implementation of an existing system. The document can also be included in the vendor contract to mitigate the risks of non-delivery.Proper requirements analysis takes time but wouldn’t you rather spend that time at the beginning than much later, when every change will cause budget overruns and/or delays with the chosen vendor?