A great deal of the requirements analysis activity is identifying the entire problem. Many software people are eager to present a solution to some of the problem.
Perhaps I can't locate my keys. Having a "Clapper" on my key ring so that my keys chirp may be a solution. However, if the real problem is that my keys were in my car when it was stolen, the Clapper isn't really part of a solution to the actual problem.
Another example that is common is "reducing network traffic". This is often stated as a requirement, as if this has merit in its own right.
This is a "non-functional" requirement. It is part of resource use or performance, and should be clearly identified as such. It has nothing to do with the behavior of the software; it doesn't help to meet the actor's goals or objectives except in a peripheral way of not being slow. The real requirement, then is for some timeline or performance objective, irrespective of the chosen solution.
Network traffic may not be part of the problem or the solution. Stating it in the requirements makes the assumption that a network will be part of the solution. This assumption may be false, and may also needlessly constrain thinking of actual solutions to the actual problem.
Often, a needless constraint appears on the scene because the actual problem is incompletely defined. Assuming a network in the solution may be because the context was not clearly stated, or the actual problem was not identified.
Typically, the solution is assumed because the problem appears to be a weakness in the existing technology. The fix, then is a patch or revision to that specific technology-related problem.
I might, for example, find myself too far from my keys to get my "Clapper" to respond. My engineer then builds a wireless web-based device with an integrated Global Positioning System (GPS) that posts the exact location of my keys on the Internet. I still have to translate this information to a specific spot within my house, but that is only more technology. The real problem is that I leave my keys in my car with the engine running when I go to the liquor store in crime-ridden neighborhoods.
The real problem has still not been identified, but a great deal of technology has been designed based on a great many technical assumptions.