In my experiences, the quality assurance staff typically handles system and acceptance testing, so I think that this would be a good place to start. This includes both manual and automated tests of the system against the requirements (functional and non-functional). Given how you describe the background of the individual, it sounds like this is an appropriate set of responsibilities for him. Because of this, yes, he would be the person who decides if and when an implemented requirement is done.
Personally, I would involve a quality assurance specialist at every phase of the lifecycle, from requirements through release. This would mean reviewing your requirements to ensure that they are good requirements, designs (with an emphasis on the testability and correlating design decisions with requirements), documentation (especially that which is shipped to the customer), code and tests, and released packages of material.
He could also be involved in measuring product quality through the use of appropriate measurements and metrics. These would include cyclomatic complexity, test coverage, Halstead complexity, defects, lines of code, and so on. He could then report on these for each iteration, identifying modules that are high in complexity (indicating that a possible refactoring is in order), have low test coverage (indicating that perhaps more unit or integration tests are needed), and defect density. Since he has some experience with writing code as well, he would be able to look at the code base, understand it, and be able to comment on its health in a manner appropriate for both technical and non-technical audiences, even if he isn't actively developing.
Other tasks would vary, and depend on the team, the project, the schedule, and the workload of the individual. You need to make sure that he can actually accomplish his tasks in the course of a normal week, as working overtime is generally seen as an antipattern in the agile community.
As far as managing QA on your project tracking system, it depends on what your team is comfortable with doing. In something like Kanban, when a developer feels that the feature is implemented and developer tested, it would get moved to QA. However, you might choose to only maintain a product backlog, a sprint backlog, and a set of completed items. In that case, it would remain in the sprint backlog until QA calls it "done", at which point it's moved to completed and you get your points. There might be some other system that your team develops that works better, as long as it makes sense for how you work and doesn't get in the way of everyone doing their job.