The community has done a good job in describing and understanding techniques for achieving operational qualities. Performance, availability, security, and usability have been well studied from the point of view of definitions and techniques to achieve them.
Less well understood are developmental qualities.
Modifiability/maintainability, reuse, and portability are mentioned as developmental qualities. Developmental qualities have much to do with the partitioning and allocation of functionality. Yet there are a great many allocation or partitioning decisions that don’t fit into any discussed or described quality attribute. Here are some examples:
1) An organization wishes to get their subcontractors on contract as soon as possible. So they proceed with the contracting process. In order to have the contracts in place, the subcontractors must had defined development tasks. These tasks effectively partition the functionality. All of this before any architect is even hired, let alone before an architecture is defined. – Contractability?
2) An architect designs a system cleverly and the design does not need a data base. His manager convinces the architect that a data base system is needed because there is an expensive data base group that currently has no tasks. – Databasability?
3) A design excludes the use of threads because the staff has no experience with threads. – Threadability?
4) Time to market considerations cause the use of a legacy component that has much more functionality than required. – Hurrability?
I am sure there are other examples out there. My point is that we have advocated a design process that assumes we begin with the necessary functionality and the important quality attributes and proceeds from that premise. The reality is that frequently, partitioning decisions are driven by factors that are essentially irrelevant to the purpose or the quality requirements of the system.
– Len Bass, SEI