RUP vs Scrum

I'd like to offer my own view on these two methodologies:
- Scrum is a fully agile methodology that was initially designed for projects implemented by a single team of around 7 people. Since then, people have designed ways to make Scrum work for multi-team, even distributed, projects, with mixed results. Also, Scrum is really a set of rules to make a team more productive. It is not a full methodology; for instance, it does not suggest any development practice (unlike XP for example). For that matter, Scrum can be applied to all sorts of projects, not just software. Finally, Scrum emphasizes "time boxing" over "content boxing", i.e. everything, from meetings to Sprints to Releases, is limited by a fixed duration, not by the outcome (contents).
- on the other hand, RUP is a full methodology for large software projects. It provides guidance throughout the project to all "actors" (users, developers, designers, testers, product managers, project manager, etc.) as well as templates for artifacts, processes, recommendations for tools, etc. It emphasizes predictability by providing a complete project plan by the end of the Elaboration phase, and therefore tries to aim for feature completeness in a predictable timeframe.

Personally, I would recommend RUP for large, high-value software projects (such as complex software products), and Scrum for smaller projects (of any kind), especially projects that require incremental delivery.

Note that the fundamental idea behind Scrum is empowering the team, making it fully autonomous and responsible. This can be disruptive in some organizations.
On the other hand, RUP is a "structured" process that gives the power to... the process. This is often desirable in large organizations but can reduce "nimbleness" and creativity.

As for your question on requirement management, Scrum indeed freezes requirements only for the duration of each Sprint (usually 15 to 30 days), but that's because Scrum by definition does not guarantee the contents (features) of the Release in advance. Basically, a Release contains... what could be delivered in the Release timeframe.
RUP also allows requirements to be taken into account during the Construction phase, but the more you allow that, the more unpredictable your project becomes, which can be a problem for projects that choose RUP over Scrum for its predictability.

I like to add to the excellent explanation of Defi0 that RUP is capable of delivering software in a demand-supply organization (whereas the supplier has a contract to deliver software for the demanding business), because in RUP it is possible to organize progress and changes in a rigid way so both parties in the organization keep on track during the process. Using SCRUM in a demand-supply situation will be a huge challenge, since every sprint can (and will) stir up previous agreements. My experiences tell me that business decision making bodies are commonly not that flexible.

Another point of consideration is that SCRUM is a way of working that can easily be adopted, also for a single project. RUP to the contrary will take more time to adopt as one needs to start with what NOT to use of the 32 roles, 200+ templates and accompanying workflows in your organization, then have everybody (i.e. everybody, including management, customers etc) put their mindsets in the same RUP direction. Only when this is put right, you may (or should) start with your first Inception phase. Any attempt to introduce RUP fpr an standalone project and start using it before organizing it, fails.