Change as normal.
WHY REQUIREMENTS CHANGE
Understanding improves Circumstances change Seeing something working changes what people want
WHAT THAT MEANS
Change is information, not failure.
WHAT TO BUILD FOR
The expectation of change.
WHAT MAKES CHANGE CHEAP
Small increments Automated tests Clear structure Loose coupling between parts
WHAT MAKES IT EXPENSIVE
Large batches of work Decisions made everywhere rather than in one place No tests Tight coupling
WHAT PROCESS TO HAVE
A way to request a change An assessment of its effect A decision, recorded
WHAT TO ASSESS
Effect on schedule Effect on other work Effect on the architecture
WHAT TO COMMUNICATE
What the change displaces.
WHAT NOT TO DO
Accept changes silently Refuse changes reflexively
WHAT TO WATCH FOR
Repeated changes in one area.
WHAT THAT INDICATES
The requirement was never understood.
WHAT TO DO ABOUT IT
Return to the problem, rather than continuing to adjust the solution.
