An important lesson for business analysts about non-functional requirements follows…
After several months of configuring a core system upgrade for a health insurance company, it came time to test EDI membership files. The legacy system had been handling these files for years without much of a hitch.
Since the new system utilizes modern technology, it was assumed that the EDI processes would be at least as fast as the legacy system.
Unit testing involved small files which tested individual data pieces. As the tests grew larger, it was taking longer to load the files. This alarmed some of the EDI Analysts, who calculated that a typical daily load would be an order of magnitude greater than the window was for loading the files. The next few weeks were spent working with the vendor to pare down the load times to get them to acceptable levels.
It all traces back to assumptions about non-functional requirements. These are often the most difficult requirements to document because it’s not easy to determine if they are complete. The key to finding them is to listen for – or dig up – assumptions. Everyone expected the new system to be fast, so the requirement about loading times remained undocumented until the eleventh hour.
It’s up to the BA to ask those “no duh” questions in order to get the answers documented. Broach different categories to get the conversation started – compliance, reliability, response time, security, just to name a few. Don’t overwhelm your stakeholders with an arsenal of categories for which you want to document those NFRs. Easing them through it will ensure that they devote enough attention so that some no-brainers don’t fall through the cracks.
