4 ms·

NFRs or Non Functional Requirements are root cause of bugs in most of the cases. Functional requirements are easy to meet. It is NFR where our assumptions come

by kulu2002 9y ago

NFRs or Non Functional Requirements are root cause of bugs in most of the cases. Functional requirements are easy to meet. It is NFR where our assumptions come into picture. As an example consider selecting improper data type to represent something. When this datatype fails to accommodate given quantity/ overflows creates the bug. But this will not happen immediately. Even such issues can easily escape rigorous testing. Check 911 outage case for that matter [1]. I think it was more than just a coding error - A bad design decision. [1] https://www.theverge.com/2014/10/20/7014705/coding-error-911-fcc-washington https://www.theverge.com/2014/10/20/7014705/coding-error-911...

virgilp 9y ago
> Functional requirements are easy to meet. That really depends. Coding against specs is just like walking on water: easy, if frozen :)
- kulu2002 9y ago
  Yeah .. I mean apart from 'Functionality' these are to be taken into consideration; https://msdn.microsoft.com/en-in/library/ee658094.aspx https://msdn.microsoft.com/en-in/library/ee658094.aspx But again ... You try to make system foolproof and nature will create better fools :-D
- neo2006 9y ago
  I coded once against h264 spec it felt like walking on water, there is always an edge case that the spec do not specify and you are not sure how to handle it.
neo2006 9y ago
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...

virgilp 9y ago

> Functional requirements are easy to meet. That really depends. Coding against specs is just like walking on water: easy, if frozen :)

kulu2002 9y ago
Yeah .. I mean apart from 'Functionality' these are to be taken into consideration; https://msdn.microsoft.com/en-in/library/ee658094.aspx https://msdn.microsoft.com/en-in/library/ee658094.aspx But again ... You try to make system foolproof and nature will create better fools :-D
neo2006 9y ago
I coded once against h264 spec it felt like walking on water, there is always an edge case that the spec do not specify and you are not sure how to handle it.

neo2006 9y ago

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...