Functional Requirements / Specification and relationship to DEV and QA

Adhering to the recommended guidance to exclude assumptions from a functional requirement document depend on a few things.

First, how strict is the culture and the project?

Sometimes recommended practices are treated as defacto required practices. It is 'good practice' to ensure how strongly such things are merely recommended, and which are in practice, required. Endeavour to have some idea what any consequences might consist of if you do or do not adhere to the 'guidance'. That is my disclaimer.

Second, what is the rationale behind the guidance?

So what might be the rationale for steering functional requirements document preparers and contributors away from including a section devoted to assumptions?

In my experience, people and projects view functional requirements differently at times. In some cases, functional requirements (what happens and sequencing or when something happens) are clearly distinct from system or service requirements (where or how something happens). Finding the distinction when the system or environment is central to the effort (device or service interfaces or device drivers, for example) may prove to be more effort than it's worth, and so in those cases I would state that as my first assumption and then move forward.

In the case of the functional requirements document, the rationale for not including an assumptions section may be presumed that if a section for assumptions feels required, then perhaps the requirements are not functional. In other words, if you feel that there are relevant assumptions that should be documented pertaining to the included requirements; the requirement may be too specific to an implementation or a particular service, and perhaps do not belong in that particular document. On the other hand, maybe the requirements do belong but just rewritten in a different manner as to not be so specific that a particular implementation and related assumptions would then cease to apply. It is probably intended that the guidance is not a prohibition, but rather as a sanity check or an orange flag to the document preparers and contributors.

If I were to approach a functional requirements document in the strictest sense, system and service requirements would not appear there. If those types of requirements are not included within the functional spec, it is lot less likely that you would need to make or declare any sort of global assumptions (often pertaining to the environment or user). If you find that global assumptions start applying to the requirements being included, it may indicate the requirements are not written as functional requirements, or that the environment or user are central to the effort.

As Robert noted in a comment, I really don't think you can fully encompass all your design constraints in one place. Since you mention that you're intending to document your design constraints to assist with your design decisions, I'm assuming you are working in a waterfall-style development environment. See the Criticism section on Wikipedia regarding waterfall development - while waterfall development may be justified in some cases, there's a reason why agile development is catching on. Since you are free to start developing a product in small increments, as soon as you find that something doesn't work, you throw out that piece and then try a different approach. It's also much more reactive to changing requirements over the course of a project.

Waterfall development often wastes lots of administrative time up front - how many of us have had to deal with a requirements document that is many dozens of pages long, only for it to be essentially useless towards the end of the project, since the requirements have changed over the course of its development?

So far, I haven't directly answer your question regarding how to document a design constraint; rather, I'm suggesting that you don't do it all up front. You don't describe what your development environment is like (meaning, if it's in a large company, you're self-employeed, etc.), but if you can change the expectations of what needs to be delivered up front before any development is done, I think that will help you enormously. If I can twist your question into, "What should I document up front?", then I would suggest you look into formulating user stories instead, which should better document the true needs that should be known up front.

(By the way, if you are working on a solo or small team, you would also benefit from reading up on lean development, which emerged from the Agile movement, and further focuses on removing waste from the development process).

Edit, based on Nicholas' comment:

It sounds like you are probably in a tough spot. The above links in my answer cover each of those areas that you're not familiar with (jump to the top of the Criticism link to see the full scoop on Waterfall development - if you're not familiar with Waterfall versus Agile development, it's almost certain you are doing the former).

Do you have a feeling for how flexible your management's expectations are for what a development project entails? If you feel comfortable bringing the idea up to them, I think you would really benefit from a lean technique, though admittedly, without having a person experienced in lean development there to guide you along, you might find it daunting at first.

If, by chance, you have a Pluralsight subscription (or don't mind signing up for the free trial), their course called "Best Practices for Software Startups" covers the principles behind lean development and would give you arguments to bring to your management as to why you shouldn't try to plan all these design constraints right from the start of a project. (Alternatively, there are a number of presentations you can watch on YouTube).