A category of issues, often arising after go-live, can cause tension between business users and the implementation team. Businesses will claim that the system is too hard to use or that it’s too slow. The implementation team will counter that the system works how it was designed. Stopwatches may emerge as the implementation team proves that the forms are displayed within 15 seconds (not five minutes), not realizing that 15 seconds seems like a lifetime for a form used hundreds of times a day. Or users claim that a form is too hard to use, even though it does everything they need and more.

You might think the solution to these issues is obvious, but it is a solution hidden in plain sight. Implementations should focus on non-functional requirements as well as functional requirements.

Functional Requirements are often the focus of both ERP selection and implementation. Functional requirements are the things the system must do. Meeting functional requirements is critical to success.

Non-functional requirements specify how the software works, not what it does. Non-functional requirements are sometimes described as the “ilities” because they include quality, usability, security, scalability, maintainability, accessibility, and others. Non-functional requirements are just as critical to success as functional requirements.

This article will focus on the five non-functional requirements that I most often see as problems that deserve special attention in an implementation methodology: (1) reliability, (2) robustness, (3) usability, (4) performance, and (5) security. If these are not baked into the implementation process, fixing them after go-live will be disruptive and costly.

• Reliability Reliable systems perform their functions correctly. Reliable systems are also highly available. Thorough testing with well-thought-out test cases, including expected results, is critical in creating reliability.
• Robustness  Mistakes happen. Robustness measures how the software prevents or recovers from errors or prevents them. A robust system will provide meaningful error messages and recover from errors gracefully. Robustness should be a key consideration at design time.
• Usability  “It’s too hard to use” is a common user complaint in adapting to a new system. If the software is highly usable, tasks can be accomplished efficiently and effectively with minimal confusion or frustration. Usability is another design time consideration.
• Performance  In the design/build phase, performance requirements should be specified as precisely as possible and tested under real-world conditions. Performance testing should be a significant part of the testing cycle, with different performance tests such as load, spike, stress, and volume testing.
• Security  Security is a broad term covering how difficult it is for authorized or unauthorized users to conduct a malicious act, see information they should not see, or run a process they should not run. Allowing access to required information and processes, but only as required, is an important design and test consideration.