Finally you go into the details. Most people will skim this until they need to know a particular detail. Details are the most important thing in a functional spec. You'll notice in the sample spec how I go into outrageous detail talking about all the error cases for the login page. All of these cases correspond to real code that's going to be written, but, more importantly, these cases correspond to decisions that somebody is going to have to make.
Somebody has to decide what the policy is going to be for a forgotten password.
If you don't decide, you can't write the code. The spec needs to document the decision. It's OK for the first version of the spec to leave open issues. By the time the programmers start work, all of these need to be stomped out. You will have enough problems resolving the new issues that come up when the programmers try to implement the code, without having old open issues around that you knew about in advance and could have solved then.