ANSWER

Yes, there are instances when the developers will produce something different than what the requirements or functional specification documents contain.  Here are some of the instances/causes of such differences:

1. The specifications are ambiguous or incomplete and they can be easily interpreted in multiple ways.  In this case, the developer may have simply misinterpreted the ambiguous requirement in a different way than what was intended.
2. The developer simply ignored the specification and/or just read it quickly and then developed the system from memory.
3. The development team encountered technical limitations and the system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences between the specification and the developed product.  This would require a strong QA team and QA process.  Here are some more detailed which address the three items above:

1. First and foremost, ensure that the business analysis team has documented guidelines for creating requirements and functional specifications as well as processes in place for peer and management review of analysis artifacts to ensure they are accurate and unambiguous.  In addition, since the QA team is responsible for creating test cases and scenarios based on the requirements and functional specifications, they should look for, find, and document as spec defects (bugs) those areas of the analysis artifacts which are ambiguous or are missing information.  These defect reports can be used by the analysis manager to identify areas of improvement and also to provide performance feedback to the individual business systems analyst.
2. Create a process in the development team for each developer to be accountable for his/her deliverables and produce code which is defect free.  In addition, the QA team should be able to find these discrepancies and create defect reports (bugs) for the development team to fix.
3. A process should be in place to deal with instances when the requirements cannot be implemented as outlined in the functional specifications.  Have the development team review the functional specs and provide feedback before the coding starts.  The development team should be a key stakeholder and reviewer of the analysis artifacts.  The feedback can then be incorporated back into the analysis artifacts and, hopefully, resulting in the alignment of the specifications and developed product.