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 when building the code and the system?
We need good software requirements to be able to assure ourselves that system (or client) requirements have been completely, accurately captured and so can then undertake software design and have something against which we can verify our compiled code. We need to focus on what is going wrong with the whole requirements process, why it is a ‘Cinderella’ subject and what can be done to help improve matters.
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.
What is needed is a clear way of communicating at least one of the sets of requirements. The demand from standards is that software requirements are clear, concise,. This is partly so that developers can do a design and partly so that there is a well understood basis for verification, be that review, some form of formal analysis or test. Providing such a basis has been the aim of the Kapture® tool.
