The people you work with are your best resource for understanding their business needs. Businesses get and keep a competive advantage by doing things differently than their competitors, you won't find that informtion in books. Perhaps the problem is how you ask them or what you ask them.
First, many developers come across as arrogant idiots who think everyone else is stupid. This attitude tends to make people less than cooperative about helping you learn. So first things first, check your attitude and your body language and your tone of voice when talking to the users to get requirements.
Next, find the person who has the most stake in the product you are tasked with developing. Have him or her give you a Power Point presentation on the business needs the application will meet. Tell him that you need a better understanding of what they do in order to help them do it better. This is not in the terms of the requirements but just in terms of an understanding of what the jobs of the users who will be using the system are. Ask if there are regulartory requirements they have to follow. Ask to get a copy of them or a link to them if it is too much to print out.
Ask about industry trends; subscribe to reading lists about your industry (I read the news in my industry, it helps me make suggestions for possible application changes that can keep us ahead of the competition).
If the product contains data that will need to be audited, talk to some auditors about what they need to see and more importantly why they need to see things that way. Learn something about IT auditing, it is an interesting field that will serve you well in developing business applications. Pay particular attention to the concept and practice of internal controls. These are critical in any financial application.
Spend some time observing the actual users right now as they work. Take notes. You will see many things that no one ever thinks to tell you in a meeting. Don't just talk to managers about what needs to be done. Talk to the actual users where-ever possible. Invariably they will perceive the application differently than managers will. It has to work for them though in order for the managers to see the data they want to see. Ask them what problems they have with the current solution. Again they will tell you things the managers would never think to tell you.
Getting back to the managers, ask about reporting needs. Business applications tend to have a data entry need and reporting need. You aren't done until both have been discussed. It does no good to put data into a database if it can't be gotten back out in the way the managers need to see it.
When they tell you something needs to happen that you don't understand, ask for further details. Ask what problem they hope to address with this change. Often you will find that they are suggesting a solution that won't completely solve their problem. In fact always ask for further details, it is a rare user who will tell you everything you need to know without extensive questioning.
Pay attention to edge cases when you talk to them. If they say something needs a managers approval for instance, ask what needs to happen if the manager doesn't approve.
Ask for reading material or websites that talk about the professional needs of the users. Ask for copies of any corporate regulatiosn that affect the application, any laws or government regulations that affect the application and any paper forms that data entry people will be entering data from (It's amazing how much easier it is to enter data when the form and the paper form have the fields in the same order, I was entering voter application data once and the form was firstname lastname and the data entry weas last name first name, imagine how many errors that creates.).
Talk about what information the user needs at his or her fingertips at all times to do a good job. Do the tasks need to be done in a set order or can they skip around?
Finally, sketch out prototypes and take them back to the stakeholders and discuss again. Often people can't visualize very well, help them see how the program will work before you spend any time building it. Do this on paper as a very rough sketch, so they don't think that just because you have a pretty page built that the application is finished. Users think the Interface is the whole application, if it looks finished, it is finished in their minds.
Start building a list of questions to ask that show you are thinking beyond the data entry. Ask about security of the data, how private is the data and who should have access to see or change it. Think about how the application will work over time not just what needs to be there for launch. Do you need admin pages to keep the drop down lists up-to-date as the items to pick from change?
