There are business objectives and user objectives.
Business objectives come from managers or stakeholders, like in adrianh's example: "increase the lifetime value of customers by 10%". They are related to the purpose of the business behind the site. There is a root objective, like "let's sell goods online", which is the core purpose of the business and everybody takes for granted.
User objectives against our site are more like "get a wireless mouse".
Thy come from (end) users, or from personas if the end users are not available with ease.
Alan Cooper explains the user's objectives clearly in "The inmates are running the asylum" and other books.
The wishes of the end users (generically "purchase goods") are complemented by marketing findings, like "bluetooth mouses are trendy".
The success of the (let's assume it's an) e-commerce site depends, among a lot of other things, on how both objectives are aligned. But, it depends much more on the user's objectives, thus repurposing the business should always be an option.
All this pertains to high level business strategy.
Coming down to the site level, here is where requirements appear.
The strategic objective of increasing customer value can be pursued in one or more ways.
Like reminding them of a feature (adrianh's example), and also by offering the goods that are trendy, lowering the shipping costs or times, you name it...
As UX practitioners our most powerful tool to support the company's objectives is by enhancing the site's usability.
We can guess that a user that made a purchase with ease might come back to out site the next time, and the other, and so on, thus supporting the 10% customer value increase.
So we analyze and think (this implies a lot of competitive sites browsing), and come out with a few ideas, changes to make to the UI. This is an analysis phase, soon to be followed by requirments writing.
A related success story is Jared Spool's 300 millions button.
Depending on the organization level of the company, we can communicate the changes to a developer on a napkin, or do something more formal like writing use cases and drawing wireframes.
These are the requirements. In IT parlance (because we have moved the action from business analysis to software development) the requirements are the documents handled to the people who will write the code, containing an unambiguous specification of the outcome expected from them.
The napkin counts as requirements too, only it's way more informal and risky than a UC.
A word about use cases
Or two ...
First, use cases might be regarded as extremely formal documentation, that one is forced to do only in big companies using UML, SEI's CMMI and the like.
Not so. UCs can be simple and informal, grounded in actual users using our UI. In UC writing, less is better. It is said that if an UC set is too heavy nobody will read it and thus it's useless.
Also, you don't need to be an IT propeller-head to write UCs. Actually, you are better off.
Second, the beauty of UCs is that they are the hinge that articulates the worls of normal people and the world of software devlopers.
An UC can be understood by an end user and also be a clear specification for an IT type.
When we handle well-written UCs to developers, the chances of getting back something like what we wanted are greatly enhanced. Also, we will get is sooner which means less dev time, a.k.a. lower development costs (this was measured, the numbers are significant, like 30%).
This is so because writing a good UC forces those who write it to ask themselves all the questions that the developers will stumble upon, and preempt them.
Also, because the UC can be monitored by the end users (or checked against the personas) which ensures that the resultant UI will be usable once it's finished.