I agree, on the functional requirements vs non functional. On most of the project that I worked on the non functional part is what hurted the most. But still, i

I agree, on the functional requirements vs non functional. On most of the project that I worked on the non functional part is what hurted the most. But still, in you example in my opinion there is 2 defects, a design defects for not choosing the right data structure and coding error which is not checking the boundary or any other error and handle it properly. I can choose the most terrible data structure for a given use case but I can make a good job at handling the case with it that it will work, it won't be fast or it will use double the needed memory or more cpu... But it will function properly. On the other hand I can select the perfect data structure but do a poor job at using it and end up with bugs. My point is the 2 are different type of defects and need to be catched separately with the right set of tool for each and not mixing stuff. The tools for catching coding errors are multi level of tests, code review ... The tools for catching design errors are design review, clarifying requirements (including non functional), may be formal verification when needed...