It possibly depends on your organization and the size of your product, but I would think that the more times the input of customers and system engineers are converted from one form to another, the more costly your product and perhaps more seriously, the more disconnected will be the developers relative to the customer.
Distinguishing between functional and system requirements probably has some benefits, but I think mostly our documentation needs to grow vertically (more descriptive) rather than horizontally (bigger waterfall, more handoffs). Even big DoD projects are organizing into System of Systems approaches so they can be done with smaller teams, smaller specs, smaller budgets, and higher potential for reuse.
Another consideration might be whether you use the V-model. In the V-model, there is a customer specification cycle that pairs with acceptance testing, design that pairs with system integration testing, and development that pairs with unit testing. If your two requirements documents don't line up with the creation of test cases, that could lead to some pathology. For example, it you have requirements in which no corresponding test cases forces the shalls to be interpreted concretely (for example, the system shall have superior performance means nothing, but the system shall respond to touch screen presses within 200 ms does and can be tested), then you can end up with real disagreements about suitability and deliverability of the product.