I disagree with the contention that requirements always change. I see it as a euphemism used to excuse laziness in gathering requirements.
The requirements are what they are. In general, it is not a wishlist, rather, a specific problem or situation arises that requires resolution. Usually, that does not change.
The changes i have seen have to do with the UI. They want it to do this, or because they had not seen it, they didn't realize they also needed that. The requirements haven't changed, the UI however, needs more revisions.
In some cases, the requirements change often, because the situation demands it. In those scenarios, it is more efficient to follow the Un*x paradigm of separate tools. Each one, however, would be design completely before being coded.
In reply to Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by chacham
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |