You rarely see business requirements. You see an interpretation of them. Your job as an engineer is to understand the actual business requirements so you can question the interpretation of them and then simplify it.
With that said, many requirements are technical and then you've even bigger freedom.
> You rarely see business requirements. You see an interpretation of them.
At the end of the day, you answer to the bottom line. If you can achieve what is needed of your program (i.e., the business requirements) with less code, it seems you're less likely to have as many bugs - the point of the article. I think here, a good choice of expressive language/framework can pay dividends, moreso than trifling over the product owner over what functionality should go.
With that said, many requirements are technical and then you've even bigger freedom.