Strictly speaking, a requirement statement is independent of any current systems/implementations.

The fact you have mjultiple system that need to support the requirement suggests you have redundant systems, but that is not a requirements issue; the statement is the same. It will be the same if you ever want to replace all these systems with one new one.

To me, those are design/implementation considerations.

Per your example, you have a new attribute of a data entity that will likely be implemented as a new column in an existing table*, and as a field on screens or in iterfaces or reports... Your system architecture (or the architect themselves) will need to know where that data entity is implemented today (what table), and how many applications update that table. It is a task of  impact analysis.

Sure, some business people may know what systems need to be changed, but often they only think they know, they could miss things. So business people saying "I want new field X on that system, and that other system" is not a requirement. It is a solution statement based on an unstated requirement.

So when a tech person does their functional spec, that will determine what systems/screens are impacted by the requirements.

Is it easier to do it the way you describe? May yes, maybe no, but it is certainly riskier.

(* hopefully not multiple tables too...