What I call design properties is what many others call non-functional requirements, and some 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 put aside when the development schedule and budgets start slipping.
I find it more intuitive and constructive to call it design properties.
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 properties, 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 design properties.
Keep in mind that design properties aren’t requirements. But I always try to supplement inadequate requirements by suggesting and seeking backing for ambitious design properties, 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 design properties 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.
Describe how the design addresses each design property.