During a recent project, our team faced that common challenge for complete requirements. While trying to extract additional requirements, the Subject Matter Expert (SME) responded with “I don’t know if I can tell you the right answer, but I can certainly tell you when I see something that is wrong.” The project manager struggled with this statement, because without complete requirements, there is really no way to determine the scope of what remaining work still needs to be completed … and provide target dates to senior management.
In all actuality, the SME’s approach is more in line with reality than probably anyone would want to admit. After all, SME’s often are delegated into the role and often do not truly possess the necessary knowledge needed to document all the requirements. Furthermore, they rarely think about requirements in the manner that Information Technology (IT) professionals expect.
In my example, certainly 80% of the requirements were noted. However, 80% is not 100% complete. Unfortunately, the road to complete that final 20% can end up taking more time than the work completed for the initial 80%. This is because the 80% is often the “low hanging fruit” that is easy to document, design and test. The remaining 20% mostly consists of rare situations (or edge cases) that are not expected or common.
A solid design of the business rules, should help expose some of these rare situations. However, in order to do so, the developer must think beyond the requirements received. Realizing that interactions with the SME would be limited, I opted to catch the rare situations and stop processing at that point. A custom error was displayed in the application, which would allow the testers to interact with the SME in order to obtain the right direction. Using this approach, we were able to get closer to 100%, but this was certainly not a “silver bullet” that could always solve the problem of incomplete requirements.
Unfortunately, to reach the 100%, iterative design and testing between IT and the SME is likely to be required. These tasks are often difficult to estimate and outline ahead of time. So when this point is recognized, the decision should be made whether a) the project manager and senior management simply allow the iterative effort to continue or b) the design is deployed in the current state – documenting any defects that surface and fixing them in a future release.
In any case, as this knowledge is recognized, it is vital that the underlying requirements be updated and communicated. Doing so could shed light in other aspects of the application where similar edge cases exist.