Documentation – Is Functional Spec a Design Document?

It depends a bit on your target audience, but my experience ( more in small/medium scale development than very large scale work ) is that detailed design documents are arduous and boring to write, rarely read and tend to end up out of date by the time a project is delivered.

This does not mean that they are worthless - if you are delivering something for someone, there needs to be an authoritative and agreed statement of what will be delivered sufficiently detailed that everyone can point to it in case anyone is dissatisfied with the deal and say "this is what we promised" and evaluate it against what was delivered.

If I were setting up a company to build a product, however, I wouldn't worry so much about a detailed specification. I would want to document what we were going to do, but I wouldn't want to go into too much depth regarding how - that is the part that is most likely to change and leave the documents out of date and useless or even inaccurate enough to be actually obstructive. I would prefer to document the "how" stuff in code using whatever documentation format the language or IDE supports best, so that as the code changes it is easier to update the documentation at the same time. It won't stop it going out of date, but it will reduce it somewhat.

Ideally you would want a design document that could double as your manual when your code is complete, but I don't know of anyone who has managed that successfully.

Explicitly separating requirements will make it easier to design the right system.

With nonfunctional requirements (I prefer the concept/term quality attributes - should provide new insights beyond functional vs. not functional), you are more concerned with the properties of the software rather than the functionality. That is how the system performs some function, not simply what the system does. Quality requirements have a significant influence on the architecture of the system in ways that the functional requirements do not and for this reason they should be treated differently.

Keeping the quality attributes separate from functional requirements allows you to analyze, specify, and prioritize different kinds of requirements in different ways. For example, quality attributes are normally specified using a quality attribute scenario while functional requirements might take the form of stories, use cases, shall statements, or any other number of formats. Most of the systems I've worked on had less than a dozen quality attributes and many, many more functional requirements.

I would actually introduce another kind of requirements - technical constraints. Again, explicitly separating the requirements into these three buckets gives you cues for how to make the right trade-offs while building the system. Functional requirements are often quite negotiable, quality attributes will heavily influence your architecture and the structures you choose, technical constraints are non-negotiable.

If this were my team, I would tell them the requirements should be clearly annotated by type to make sure we don't miss something important in the architecture. Think about the architectural drivers, not just the functionality.

Anthony Lattanze in Architecting Software Intensive Systems: A Practitioners Guide gives a practical overview of architectural drivers and why they should be treated differently, much more comprehensive than my summary here.