Firstly, there are no absolute ways of defending against change; to do so would require a degree of clairvoyance seldom bestowed on the humble software engineer. But by looking at the provenance of your requirements, you can make a good start at predicting the ways in which the software might need to change in the [...]
As some of you may know, I’m interested in landscape archaeology – looking at what’s around me in the landscape and tracing features and signs of previous land use. As part of my study, I’m learning to recognise features that might be quite old and to deduce the reasons that they are there. It’s more [...]
One of the first things I do when starting a new project, or meeting a new client, is to compile a glossary of terms. Each industry has its own jargon, and each business probably has its own spin on that, and a set of short-cuts to concepts that may only make sense once you understand [...]
No system is going to be successful if the end users reject it, that’s self-evident. But how do you make sure that it’s as much their baby as yours? Part of my analysis process is to test out the TRUTHs, POLICYs, LAWs and WISHes that I discover, by running them past as many interested parties [...]
So how do you work out what you really need? There are as many answers to that question as there are practitioners of the subtle art of requirements gathering. I think it’s important to employ common sense and not adhere to a purely academic approach here. Ultimately you are dealing with software for people, and [...]
Commissioning software is *hard*. Lots of people have lots of potentially conflicting ideas and opinions; you might have a legacy system that does almost what your users want, but not quite; you might want to make use of a new technology, or introduce more automation into the process to drive greater efficiency. How do you [...]