I have a couple of issues with the original article; a) the 6 points listed, and the article itself, doesn't recognize that requirements gathering is a two way communication and iterative process; b) if you don?t know the difference between these 6 items and a ?requirement?, as a requirements gather, you should not even be in the room.
David?s post (link in his feedback) is much closer to the mark. When a client states a ?requirement? you have to ask why until you get the core requirement(s). Often, as David?s article covers, we fill the gap (i.e. I think I know what they mean), but we must also remember the provider is doing the same think ? they have existing knowledge, experience and prejudices that impact their requirements statements (to take an example ? client states they want a gasoline/petrol engine, why? Oh because they are more eco-friendly ? is that a correct assumption on their part? But if they stated, because the operator and unit will be operated in suburban locations for extended periods and gasoline/petrol is easy obtained in these locations if they run out, we don?t carry too much fuel for safety concerns ? and what we have here is actually a set of requirements/design considerations ? i.e. length of operation without refueling, availability of fuel and safety considerations associated with carting additional fuel and if you go on, cost of fuel/operation).
As a requirements gather, you must be good at asking the questions, feed backing and validating requirements (preferably in scenarios), and educator (i.e. broaden the audience?s mind to alternative considerations, impacts of fulfilling a requirement (e.g. think integration, example would be a finance requirement impacting negatively of shop floor flexibility or efficiency), linking the small detail requirement to the overall objects and goals.
Two big risks I think occur during requirements gathering; a) accepting a ?solution? as a requirement (e.g. ?I need batch management? v.s. ?I need to be able to manage perishable goods, which make up around 5% of my inventory, as we seem to through a lot away?); b) focus on requirements not solutions (there is a fine line here between educating and solutioning).
Solutioning is slightly different game, but I think the same considerations as stated above, plus some other skills and approaches are needed once you get into that area.