Asking for the Right Information
When a form is initially designed, the process should be to determine what data is necessary - and for each datum, ask "why" it is really necessary (how will we use it? Can the task be completed without it?).
Forms evolve over time, so documentation should be kept to remind you of the reasons (when the form is redesigned), and it's often good to revisit forms periodically to determine if those reasons are still valid (business practices changed and certain things are no longer necessary).
From the user's perspective, they expect that if they provide information, that you are going to use it. If you ask for a phone number, it's because you're going to call them. And more, they expect it to be used for their benefit: if you ask for an e-mail address in placing an order, they will expect an e-mail notification when their item ships.
The form content should be determined by internal stakeholders: the sponsor, the individuals or departments that will consume the information. If you can document these stakeholders and the rationale for the information from each perspective, it can help to allay conflict among them.
Also of importance: determine whether the organization already has the information. Especially if you maintain a user account, you should not need to ask the user for information you already have on file (though you may need to redisplay it to confirm it is still valid).
One bit the author doesn't mention, but is relevant in some instances, is that you shouldn't ask the user to enter information if it can be determined automatically.
When designing a form for the first time, do a competitive analysis: find out what other sites with the same operation (preferably in the same industry) are asking. Don't imitate blindly, but use it as a starting point.
The author also fails to mention: you should look at yourself as well - what information have you requested for similar tasks in the organization's own site(s)? And again, don't' just copy yourself blindly - ask the "why".
The author shows an example of a question protocol, using a three column layout: the question (asterisk if mandatory), who needs it, and what they will do with it, which she uses as a checkpoint with stakeholders when designing forms.