What I call design goals is what many others call non-functional requirements, and so call it quality attributes. I have a huge problem with the term non-functional requirements because practically anything called non-functional requirements translates directly to added functionality!
The term also appears to give many stakeholders the impression that they are less important that so-called function requirements, which are considered more what the ‘business’ needs. Non-functional requirements are always added last, and rarely captures any reviewer’s interest.
So called non-functional requirements are also the first to be pt aside when the development schedule and budgets start slipping.
I find it more intuitive and constructive to call it design goals.
Of course, it the formal requirements dictate a certain performance criteria, my performance design goals will at least achieve that, but also often exceed them.
In my solution architecture documents I usually use 17 subchapters to cover specific design goals, but it may vary depending on the solution’s size and complexity.
I encourage you to do the same, but to also at least consider the 17 suggested topics.
Keep in mind that design goals aren’t requirements. But I always try to supplement inadequate requirements by suggesting and seeking backing for ambitious design goals, which I believe will result in a better solution with manageable costs of ownership.
To the extent that formal requirements have been specified within these 17 topics I actually avoid referencing them in my architecture document. Instead I create a separate requirements matrix that maps formal requirements to content in the solution architecture document. This is more of a project document, and ensures that I don’t accidentally forget anything, and helps me put my stakeholders at ease on that same score.
Remember to not just state the goals, but expand them and describe how the design addresses them.