No coding is not hard! that's the easy bit.
The hard part about the job is
1 Getting the actual real requirements nailed down 2 Designing the system to run in the real world accounting for all those edge cases and falilure modes.
The hard part about the job is
1 Getting the actual real requirements nailed down 2 Designing the system to run in the real world accounting for all those edge cases and falilure modes.
Wherein the programmer plays the role of social worker. Seriously though, the skill sets are very similar. The client is typically the ultimate source of the requirements, but it's never a simple case of asking the client "what should I build? More often than not, the client doesn't know what s/he wants, wants something that will actually hurt him/her, is actually seven different people who want opposite things, wants the roses simultaneously painted white and red, etc. Which is why I find requirements collection the most challenging part of the job.
If on the other hand you are saying, "should I be evaluating product specification and requirements gathering when hiring business analysts, or product managers" then I would say of course! What else would be evaluating them on?
Similarly, there are environments where static requirements are cornerstone for success. Certain methodologies deal with this environment better than others and certain developers will be more successful than others in these environments.