I respectfully disagree with @DavidEspina. I don't think his answer is fundamentally wrong, but it doesn't match my answer.
During project initiation (or in some contract work, prior to project initiation) you determine the scope of work. This is the box inside which all requirements must fit. The project sponsor and project management team must strongly own the scope of work. Scope change is generally a bad thing and should be avoided. Update Scope is a project level agreement between sponsoring stakeholders. Changes to scope generally mean changes to cost, resources, quality and many other assumptions about the project. Changes to scope will usually mean that at least one of the stakeholders will need to reconsider involvement in the project.
An example: a few years ago, the Smithsonian museum was taken to court because the scope of work of the contract was to maintain museum artifacts and executives were using the facility and staff to repair personal vehicles. The latter work is clearly out of scope.
Requirements are generally outlined during project initiation, and refined during project design. Requirements are generally more granular than scope. Requirements should be owned and maintained by the project team including technical staff. It is normal for requirements to change (although the change must be strongly controlled & approved by appropriate stakeholders). Update Requirements are defined within the scope of work, and usually involve much more technical coordination.
An example: If the scope of work is to maintain museum artifacts then the requirements might address things like:
- All artifacts will be cleaned monthly using best professional standards
- Environmentally sensitive artifacts will be stored in a safe environment and weekly environmental monitoring will provide assurance that the environment has the right temperature/humdity/etc.
- Any artifact removed from display will be tracked in asset management in accordance with procedure X.
Let me add a counterexample to address Mr. Espina's question.
If you are the shop steward at the Smithsonian, you should have a copy of the scope of work. if a manager approaches you and says:
- We've just acquired a new, historically significant C-130; I'd like you to bring it in and perform the initial cleaning and maintenance to permit us to put this on display.
Then the logical answer is, "Sounds interesting - we will need to take it through the change control board/artifact accessession committee to make sure that we have the right priority and authorization to spend hours and supplies."
If the manager comes to you and says
- My boss's personal Cessna has some engine trouble; you have the tools here in the shop and you've done similar work on museum artifacts. Would you mind coming in on the weekend and performing the maintenance?
The correct answer is, "I'm sorry, that is outside the scope of my work."
(Roughly, that's one of the things that happened in the court case)
To craft a somewhat strained analogy, the scope of work is like the constitution. A good constitution is broad principles, strongly endorsed and rarely changing. Requirements are more like laws; they are more flexible and can change as society changes or technology changes.