Like any engineering discipline, we have to know what it is that we want the software to do. This can sometimes feel like trying pin jelly to the wall, especially when the client doesn’t know what they really want, but will be able to tell you in short order when it doesn’t meet their previously unexpressed desires.
At which point comedy (or is it tragedy?), ensues, but it will cost time, money and probably some lost hair before everyone is to an extent satisfied. Avoiding this situation is problematic and there is no single solution that will get the requirements sorted out before any costs ensue but this is the same for any engineering discipline. However, we don’t build a bridge in order to find out where the bridge should be, so why should we tend to do this for software engineering by building the code and the system?
Many standards suggest that there should be a review between system requirements (or the clients’ requirements) and software requirements. This is a subjective review and can be, some observe, an acrimonious, poorly supported or even totally neglected activity. It is difficult to achieve agreement when neither party can properly express their needs on a mutually understood basis.
This is particularly so, if language is not clear. Ambiguity, repetition, incompatibility, undefined terminology and repetition (!) leads to frustration and hence to iterations of requirements impacting on the remaining development life cycle; costs rise.