Yesterday I accompanied my colleague Dan Williams to a meeting with one of our business users to discuss some requirements for the next section of the application we're developing, and it reminded me of some key points regarding requirements gathering, which can be easily overlooked.
We were discussing one particular metric and the merits of where the data for this metric should be displayed; i.e. is it of most interest to this particular user group or of more interest to another user group, and it became apparent that the understanding or the meaning of the metric is different between the two user groups. In this case it transpired that what initially appeared to be a single metric is actually two separate metrics and hence most benefit may be gained from breaking this up and displaying it individually in each of the two locations we were originally trying to decide between.
The key learning point here is that regardless of how well you may think you understand the definitions of the terminology and metrics being discussed, it is always worthwhile when talking to a new user for the first time clarifying the definition, to identify if the same definition is shared by all users. If not, it may be, as in this case that you are actually dealing with more than one metric. Alternatively, as I have also experienced previously, it may be that there is not a common understanding within the business of the definition of a particular metric, in which case as a consultant you can help to identify such disparities in understanding and work with the business to resolve this.
The second point which I was reminded of has to do with work out-of-scope. Often during the course of requirements gathering you will find things come up for discussing which get quickly dismissed because they are out of scope for the current development, however too often I feel this out of scope work is not properly understood because it is dismissed immediately due to it's not being (or appearing to be) relevant to the current scope. This is potentially a mistake for two main reasons.
Firstly, in order to definitively state that something is out of scope, it is important to clearly understand what it is that we are talking about. As we have learnt from above, sometimes an initial understanding of some particular term or metric etc is not necessarily complete. Using the example above, we may have initially considered the metric out of scope, however after having clarified the definition and identified that in fact we are talking about two separate metrics, perhaps it is the case now that only one of these two new metrics is out of scope, but the other is actually not. Any number of other scenarios could be described to validate the proper following up of out of scope work.
The second reason is that out of scope work will not necessarily be out of scope for ever, therefore it makes sense to understand these requirements also, so that current development will not inhibit the incorporation of these requirements at a later date. Whilst I am not advocating an extensive amount of time be spent on gathering requirements for out of scope work, in my view it is always worthwhile capturing requirements from users when they raise them, even if you just file them away for future use. Otherwise, you may find it difficult to do so in the future.
James