It's much better to have 2 levels of documentation.
1. A functional set of requirements that's user readable, excluding technobabble;
2. A technical specification that contains quality assurance criteria that can be tested, and allow a school to cancel a contract without penalty if there is poor performance.
On the technical side, the risk is that suppliers tick the box that they can do it - and sort out the implementation problems later. Look at Prince2 product descriptions to see a respectable way to structure it. For example, there probably aren't many people around that can confirm SCORM and SSO compliance just by looking at supplier documentation. When the time comes to use it, I expect there will be a few "Whoops, there must be a bug in the code" or "We are doing it right, it must be the other guy". It would be interesting to get some feedback on how well the Becta Framework suppliers are doing against the specifications.
I have already posted about SCORM. My research into authentication and single sign on is incomplete, and reveals new twists on a weekly basis. Ideally teachers should be able to have SSO to their learning platform, e-portfolio, school administration, local authority, RBC and possibly ContactPoint systems. It would remove the need for multiple passwords, tokens or smartcards. Technology is available, but the registration processses, codes of connection and information sharing protocols, I'll wager, are just not in place. The wider information assurance aspects should be considered now, not next year.
Unless there is communication of these issues and setting of realistic expectations there's going to be an awful lot of demoralising frustration in 2009 - and beyond.