Personally I think it's important not to over-spec at the beginning of a project, especially if it's very big. I also try not to get too bogged down worrying about implementation details. To me, they usually follow naturally from the team's skill set and the desired functionality.
Also, making minor adjustments to the spec will usually happen throughout a project, and there's always a chance of the budget being either relaxed or tightened.
My project specifications always start with a simple introduction about what it is we're building, what problem it's supposed to solve, and which target audience it's for. When we get to technical details, I care about what technical restrictions there are—what type of server environment we're planning on using, what programming languages we'll use (based on what the team knows), etc. Those are the absolute basics and usually won't change.
From there, I usually draft out the alpha releases, up to the MVP, followed by any number of subsequent releases. The further into the future a release is, the more vague they're allowed to be, since you never know what kind of data and feedback you'll gather. There's no point in specifying future versions exactly, when your customers might end up giving you a whole other picture.
To me, specific implementation details belong in the issue tracker, and not so much the spec. The spec contains a high level discussion of the project, the basic technical road map, and just enough information to give everybody a decent mental image of the mature product.