Service 6.
Requirements Engineering.
Requirements engineering is a difficult discipline. There is a fine line between staying in scope and meeting the client’s often-unspoken dream. Clients always buy a dream. There is an idea of a product which will sell millions. The difficulty is communicating enough nuance that the essence of the product can be captured inexpensively.
One of the skills encouraged in our team is an ability to recognise going out of scope. If something is not defined in the requirements, there are two options. Either we make an assumption on the client’s behalf (risky!) or we clarify with the client. Our preference is usually clarification.
The risk of assumption is we get it wrong. It is impossible to fully communicate a dream. The dream itself may be half formed and our brief might be to investigate possibilities.
The best answer to this is to spend the time with the client, going over the idea and documenting as much as possible. In this way the “feel” of the product, the user experience, is likely to take form. Questions can be posed.
It is critical to identify a fail state as early as possible. “What do we do if something goes wrong?” is a question we always ask. Untested error states are one of the largest causes of in-the-field failure. We must identify an error state early in the design and work out what is the best action. We must then test this action. In some industries, test report coverage of error cases can be mandatory.
It is useful to give the problem to a number of minds. One of the goals is to reduce the amount of unspecified behaviour to a minimum. By exposing the idea, and the requirement, to as many minds as possible, the chances of “not thinking of” something are much reduced.
Requirements engineering therefore requires a deft touch. We must be careful to gather the requirements without spending so long doing so that we delay the project.
