Requirements analysis involves working through the requirements that are being elicited and looking for problems, problems that might be omission, duplication, conflict, all kinds of things. In actual fact, the most productive way of doing that, the easiest way of doing that, is to predefine a set of filters through which we pass our requirements, and this table shows us a suggested set of filters. Unravelling multiple requirements involves checking that each requirement is, as far as possible, what they call an atomic requirement, a requirement describing one thing and one thing only. If our requirements become composite, then we're locked into either delivering the entire requirement, or not delivering it. If we break it up into its component parts, we can choose which of those need to be implemented and which can be left. Checking for overlapping or duplicate requirements is a necessary task because we are working with multiple stakeholders, and different stakeholders may ask for the same thing in different ways. We may end up with duplicate requirements, or indeed if our requirements are not atomic, we may well find that requirements overlap with each other. One component of requirement A is the same as a component of requirement B.

We should also confirm the relevance of the requirement. People will ask for all kinds of interesting things when we have conversations with them, some of which may sound like great ideas. The question is, are they relevant? Are they in pursuit of the agreed objectives of this piece of work? Conflict is inevitable when working with multiple stakeholders, stakeholder A wants it red, stakeholder B wants it blue, the way to deal with conflict is first of all to notice it. So, we pass the requirement through the conflict filter to spot those difficulties, then allowing us to find an easy resolution. Checking for solutions involves finely picking through our requirements to find any element of presupposition, any time the stakeholders have already decided how the requirements should be met. Sometimes it's something simple like, 'We want it printed on A4 paper.' And the question we have to ask is, 'Well, does it need to be printed? Why do you want to print it?' 'We've always had it printed.' Sometimes the solutions are bigger, they've already decided which software application they need, probably because they had it at their last place. We also evaluate the feasibility of requirements, be it business feasibility, technical feasibility or financial feasibility. The requirement may well be a great idea, but how expensive is it? How hard to do, how risky is it given our understanding of technology? Does it fit in with our business culture?

Finally, we consider the quality of expression in the requirements. In the end, most of the time, what we rely on is written documentation of requirements, and if that documentation could be misinterpreted, misunderstood or simply baffle our stakeholders and ultimately our developers, then we have a significant problem with the requirements. So, there's a whole range of filters we can use to confirm the quality of expression in our requirements. Consider this requirement, 'Users must be able to make a rental booking, change existing bookings, and cancel them.' What's wrong with that? Well, first of all, I've used must in the requirement. That's one of my reserved words, if we're using MoSCoW, it suggests that a requirement has been prioritised as a must-have. We should take MoSCoW language out of our requirements. Secondly, well, clearly this is a composite requirement, this is multiple. It should be separated out into three separate requirements, one for making the booking, one for amending a booking, and one for cancelling a booking. Thirdly, this generic term users might be a little bit too generic for this scenario. Exactly which users should be able to do these things?

Requirements analysis | BAF |

About