Who collects a system's requirements — and why does that role need such deep knowledge of the business domain?

The business analyst / requirements engineer, explicitly with a focus on security — and the role needs domain depth because only someone who understands the business can tell what a stakeholder meant from what they literally said.

* Each extra hand-off deforms the request a little further; one domain-deep role in direct contact collapses the chain to a single checkable hop. *

Requirements do not arrive; they are collected, and who does the collecting decides what gets found:

• The business analyst does it, with a focus on security. Software engineers are measured on delivering working functionality, so security is not where their attention naturally goes. If nobody in the project owns that focus explicitly, security requirements simply do not get written down — not out of negligence, but because no one was looking for them.
• The role is central and outward-facing. The requirements engineer is often at the centre of attention and in direct contact with the stakeholders — the single person who talks to everyone.
• Domain depth is a responsibility, not a bonus. The role has both the ability and the obligation to become as familiar as possible with the domain. Only someone who understands how the business actually works can tell a stakeholder's literal words from what they meant, spot the exception nobody mentioned because "everyone knows that", and recognise when two departments are using the same word for different things.

That last point is the whole reason the role exists. The classic failure mode is a chain of well-meaning people each faithfully passing on their own misunderstanding — the customer describes one thing, each hand-off deforms it a little further, and what ships resembles nobody's intention. Domain knowledge plus direct stakeholder contact is what collapses that chain to a single, checkable hop.

Tip: The tell that a project lacks this role is nobody being able to answer "why do we do it this way?" without asking three different departments.

Go deeper:

• The tree swing cartoon (Wikipedia) — the classic picture of the failure this role exists to prevent: each hand-off deforms the request a little further.
• Business analyst (Wikipedia) — what the role does day to day, and where it sits in a project.