What security activities occur during the Requirements phase of SDL?

This is where you decide, before any code exists, what "secure enough" means — capture security/privacy requirements, name owners, and set the quality bar bugs must clear to ship.

Requirements is the cheapest place to influence security, because changing a goal on paper costs nothing. The phase achieves three things:

• Pins down the security and privacy requirements while there's still freedom to choose architecture — the development team writes them down alongside the functional requirements.
• Assigns accountability. A dedicated Security Advisor (an experienced security person, often outside the team) reviews the product plan and gives recommendations, and named security/privacy contacts are appointed so there's always someone responsible.
• Sets the ground rules for tracking and triage. A bug-tracking system is mandated, and the team defines bug bars — the minimum acceptable security quality level. A bug bar is a fixed line drawn up front (e.g. "no remotely exploitable memory-corruption bugs may ship"); anything worse than the bar must be fixed before release, which stops teams from quietly waving through serious flaws under deadline pressure.

Why up front: agreeing the bar before development means security decisions are made calmly by policy, not in a panic the week before launch.