David Bush

UK National Air Traffic Services Ltd, London, UK

ALL SYSTEMS change over their lifetimes. Unless you are fortunate enough to be responsible for delivering a very small system, with a limited life expectancy, people will want to change your system. This will almost certainly happen while you are developing and delivering the system, and it will definitely happen when you are operating it—unless it is one of the significant numbers of systems that are delivered and never used—which is hardly a consolation.

There are really only two things you can do about this: you can ignore it and hope that you are moved onto another system before anyone thinks too much about changing the system; or you can specify and build your system so that it is robust in the face of the changes it faces, that is, so that change is not needed, so that it is easy to achieve, and so that it does not detract from the operation of your system.

If you are bold enough to take the responsible approach to this problem, this chapter offers you a mechanism for identifying what changes might occur over your systems life cycle. Armed with that knowledge, you have chance of future-proofing your system, and probably getting a promotion for your successor.


Using scenarios of the system environment to identify possible requirement changes requires an investment of time, both to establish the scenarios and to carry out the assessment. ...

Get Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.