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...