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.
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.
Comments
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.
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.