10 Questions to ask before Changing your Software

It's been said that modern day software engineering is like gardening in that you're not normally creating something new but maintaining an existing system.
So when gardening - when making changes to your existing codebase - there are several questions to ask:

1. Why am I Making the Change?

The best code change is no code change at all - because every code change carries the potential work of a bug fix waiting to happen.
The smaller the code or configuration change, the lower the risk. If it ain't broke, don't fix it.

2. Who is the Customer?

Are you making the change because your boss thinks it would be a cool new feature? In which case he's your internal customer (this is often the easiest case as it matters less when the requirements aren't completely defined up front).
Or is it that there's a real, paying, external customer who wants something added to their bespoke software package?

3. What are the Use Cases?

Once you know who it is you're developing for, you'll need to know exactly how they plan to interact with the system...

4. What are the Detailed Customer Requirements?

...and what those new UI components should do under the hood.

5. How will the Architecture be Affected?

Will the change affect your software's architecture? Are you just adding a new widget to your GUI, or are you going to rewrite half of the existing code?

6. Which Existing Modules need to Change?

You do have a modular codebase right? Yeah? So you'll need to think about which ones need to change, and how.

7. What new Modules are Needed?

Will that new widget require its own module, or does the functionality sit naturally in an existing module?
If new modules are needed, what's their public interface and how do they interact with everything else?

8. How will Errors be Handled?

How does the software cope when the inevitable happens and the user does something stupid?
Or the robot that you're driving decides to crash into itself?
What happens when the web service that you query falls over because a pop superstar passes away and there's too much web traffic?

9. How do we test it all?

As this is a change to existing system, you need two types of test:
1. Regression tests to confirm that the existing system still works.
2. New tests to test the new stuff.
If the software already has an automated test suite you've covered 9.1 already and covering 9.2 should be a doddle.

This is also the place to look our for deficiencies and commonly experienced problems, for instance, if you have a highly multithreaded codebase, how do you make sure that the delta hasn't introduced a deadlock?

10. What are the alternatives?

Double check that the change you've decided to make really is the best way before touching any code.

What do you think? Is there anything that you disagree with? Or that should be added to this list of gardeners' questions?