Requirements Gathering

Requirements gathering is the first step on the "traditional" process of designing any new piece of software, and involves asking detailed questions regarding what the expected users of the system want to see in the finished product.
I have found, working as a systems or process analyst for some years, is that the end users rarely have a clear view of what they want and certainly not in precise details.

I have worked with many people over the last 40 years and I would put them into two broad groups - those that go for the "details" and those that go for the "big picture", or "helicopter view" as one Managing Director once described it to me.
Computer programmers tend to be in the "details" group, whilst managers tend to be in the "big picture" group. This is just by the very nature of the jobs, they attract people with that type of view. Of course, neither view is any better than the other, as both are needed.

The difficulty for requirements gathering then, is that of getting the requirements in enough detail to allow the programmers to write the code, without the managers or end users losing patience or retreating from the project.

I am prompted to muse on these thoughts as I prepare to become involved in "SCRUM" and Agile.