In the section that follows we introduce the key properties that a good requirements model should exhibit, and we demonstrate - with a small number of examples - how the current set of standards does not adhere to them. We first examine consistency: does the standards document use (interpret and give meaning to) notation and terminology in a consistent way, do they have contradictory standards, and do the standards contradict the other set of instruments that precede the document? Next we ask if the standards are complete: are there some existing e-voting systems whose adherence to the standards cannot be ascertained because the standards are not broad enough, and are there some aspects of e-voting system behaviour, in general, that the users are interested in but are not mentioned in the document? We also ask if there are some aspects that really don't need to be included as they are either outside the scope of e-voting, or they are in the scope of e-voting but adequately addressed by the other instruments. The next property that we address is that of the level of abstraction of the standards: if the standards are too concrete (over-specified) then they will exclude potentially good e-voting systems (that meet user requirements) because they are not implemented in a particular way or using a particular technology; similarly, if they are too abstract (under-specified) then there is no obvious mechanism for deciding if a system meets the requirement and so the standard will fail to exclude systems that appear not to meet a requirement due to uncertainty. Next, we examine whether the standards embody a clarity of expression - where the goal is to say things as simply as possible - and so we ask if there is too much repetition. Finally, we ask if the document is easily changed and updated. Are there some things that are likely to change in the future, that will require changes to the standards, but whose change will be very difficult and costly to manage? If so, the standards are not maintainable.