Design properties

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.