[yawz]

> The nature of the beast is that software requirements rarely change

Put like this, it's hard to agree with the above statement.

Following the spirit of the article, I assume the author means that the problem domain is pretty stable. But I've been in this for more than 20 years, and I know that requirements always change. Not only our understanding, but also the customer/user's understanding of their needs and priorities change.

(Edit: typo)

[naasking]

> Not only our understanding, but also the customer/user's understanding of their needs and priorities change.

And not only does understanding change, but the business requirements actually change too depending on market conditions.

[cratermoon]

I think the notion of "requirements" the author refers to is what the business actually does. When writing say health-care management software for say, a hospital chain, they're not going to suddenly decide, no matter how much the small-r requirements change, that they instead want their software to be able to do capacity management for lumber mills.

The business domain constrains the field over which the requirements can change, and the sort of deep context which the author mentions will also range over that field.

[naasking]

> When writing say health-care management software for say, a hospital chain, they're not going to suddenly decide, no matter how much the small-r requirements change, that they instead want their software to be able to do capacity management for lumber mills.

But they might start with wanting billing software, and then change their minds and ask for software to do triage and scheduling operating rooms. That's almost as drastic a change in scope as your big-r from health to lumber mills, so I don't really agree with the distinction you're trying to make.