Q: Do QA teams focus and Functional Requirements whereas development team focus primarily on functional specification though they need to have an understanding of functional requirements?

The two are closely related. For small efforts, the requirements can be developed to a level of detail where they can also be used as the specification. In general, Functional Requirements are the customer-centric statement of what a system should do. Functional Specifications are a more detailed description of the Functional Requirements. For example:

• Rqmt: The customer shall be able to change the upper alarm limit temperature
• Spec: Selecting the parameter::alarms::temperature menu item shall bring up a pop-up form that allows the user to enter a value between 50 and 100 for the alarm limit.

Functional specifications are still in the realm of describing what a system does, not how it does it. Because of this, QA teams should be interested in the Functional Specifications for several reasons, among them are:

1. The QA team needs to ensure that proper reviews have been covered to determine that the Functional Specifications are consistent with the requirements, and that they are complete.
2. Each of the Functional Specifications are testable, so the QA team needs to make sure the tests are defined and the software product passes those tests.

Q: I assume QA would sign off the product as long as the functional requirements are met irrespective of whether the functional specification is followed or not. Is my assumption correct?

Whether or not QA signs off on a product that deviated from the specification depends in part on what process was followed when decisions were made to make changes. If the development team followed the change processes, QA would not have any problems. (Note — these processes should insure that proper communications about these changes occur). However if a development team goes off and decides on their own there are a lot of risks that even though their efforts satisfy the requirements, their efforts may be rejected by QA, other business units in their organization, and even the end users.

That is not to say that a development team is bound by the specifications. It is OK for a development team to deliver something that deviates from the original specifications. However making decisions to implements something different that what is in the specifications should be made unilaterally. Mature organizations will have some defined change control processes to accommodate changes. QA will be making sure such processes are followed.