As an architect you often encounter requirements that are better off not implemented, requirements are triaged through several activities one of them is impact analysis. The law of diminishing returns comes into play here given that the how the complexity of a requirement and its return are often inversely proportional. Its often more productive to partially implement the requirement rather than going to the full extent as the cost will far exceed the return.
The law of diminishing returns states that in all productive processes, adding more of one factor of production, while holding all others constant, will at some point yield lower incremental per-unit returns.
This behaviour can be represented using the following formula with X being the unit of incrementation and i the number of increments.
To put it in a more colloquial form, the more seeds you plant in a field the less yield you get per seed, another example would be developers per project there is a certain infliction point afterwards it doesn’t matter how many developers you add to the project the return remains the same.
An example of requirement that exhibits a highly diminishing result are service assurance requirements, requiring a 99.9% accuracy would cost far more than what it would cost to have a manual workflow to manually verify the deviation. OCR (optical character recognition) projects come in mind and hence you find projects like captcha relying on users to verify the output of the OCR algorithm.
This is not very different from NP-Complete problems and approximation algorithms reaching an acceptable solution at a fraction of the cost is favoured over reaching the solution to a certain problem set with a potentially infinite solution time.