We always make 2 documents the SRS (Software Requirement Specification) and the FS (Functional Specifications) documents for the coders aka programmers.
As I have examined the SRS is more like containing both functional and non-functional requirements as compared to the FS that deals only with the functional requirements.
To cut it short will the SRS be sufficient enough for the programmers to do their work? and not make any FS anymore?
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.
The duplication in your docs is a data problem. Data views are being treated as data sources. Relational DBs, normalization, and queries were designed to handle this. It may be over-kill, but you could make a requirements database. A filtered query would produce the "functional" requirements.
Maybe an excel sheet with a functional/non-functional flag column would suffice.
As long as programmers and QA agree that this is sufficient and you're happy that what is being delivered and not spending too much time later explaining features to dev/QA - I don't think people would care what the document is called. No reason to have two docs that are largely duplicates of each other.
You'll need to identify which requirements in SRS are traceable to features(when user clicks A, B happens) and which are not (Ex. extensiblity, cost) so you can get agreement that software meets the requirements when all is said and done.
