Kudos to the article for focusing on requirements from the outset, as generally speaking, software development does this all too rarely. I would paraphrase (and

Kudos to the article for focusing on requirements from the outset, as generally speaking, software development does this all too rarely. I would paraphrase (and slightly alter) the article's recommendations: 1. Write the requirements down at the outset. 2. Rank and prioritize requirements. 3. Reject requirements that are unreasonable (for now), but keep a record of them in case that changes. 4. Try not to make rejected requirements fundamentally impossible in the future.