Yazılım geliştirme ve bakım ihtiyaçlarının maliyetinin yüksekliği, bir tasarımın iyi olup olmadığını en baştan belirleme ihtiyacı doğurur.Ayrıca, birçok organizasyon olası kalite sunumunu ve gerekebilecek bakım çabasını tahmin etmek için yazılımdaki kusur sayılarını uygulanmadan önce öngörmek isteyebilirler.Yazılım dizayn matriksleri bunu yapabilir.

Günümüzde güvenilebilir yazılım tasarım yoksunluğundan dolayı, yazılım mühendisleri belirli tasarımı seçmekte zorlanıyorlar.Belirli bir yazılım problemi ya da belirli özellik için birçok olası tasarımlar olabilir.Yazılım tasarımı, tasarımcının yargısına dayanan, beceri isteyen bir karar verme sürecidir.Modüllerin sayıları, bu modüller arasındaki etkileşim, veri yapılarının organizasyonu, vs gibi birçok yazılım tasarım kararı tasarımcının yargısına bağlı, zor kararlardır.

Dizayn matriksleri, belirli bir metodu kullanmanın ya da birçok olası tasarım metodolojilerinin karşılaştırmalı araştırmasının yararlarını ölçebilmelidir ve yazılım mühendisine ihtiyaç önceliklerine uygun olarak bunlar arasından en iyisini seçmeyi sağlayabilmelidir.

Yazılım tasarımının basit olması için, bileşenlerin bağımsız olması ve yoğun ölçülerde etkileşime sahip olmaması gerekmektedir.Bağlaşım-bağımsızlığın ve bağlılığın bir ölçüsü olması-, bir modülün işlevinin tekliliği- tasarım ölçevlerinde kullanılabilen iki kriteridir.Bağlaşım, yazılım kalitesinde çok büyük etkisi olan yazılımın niteliklerinden biridir ve bağlaşımın ölçüsünü belirlemek için birçok metod vardır; bunlar yazılım tasarımının sübjektif (subjective) ölçümleridir.Ayrıca, bu kriterleri daha büyük tasarımlar için kullanmak yersiz olur.

• Tasarımlanan yazılımdaki kusur derecelerinin olası tahminleri.
• Belirli bir yazılımın, gerekebilecek bakım kolaylığının derecesinin tasarım aşamasından beri görülmesi
• Yazılım modülünün halen işe yarar olduğuna karar vermek üzere, gerçekleştirilmesi gereken testin haricinde ihtiyaç duyulan uygulamanın zorluk derecesi nedir?
• Belirli bir tasarıma dayanan yazılım geliştirmede, modüldeki kusur sayıları gibi ölçülebilir özellikler ne kadardır
• Tasarım özelliklerine dayanan yazılım modülünü test etmek için gereken gayret ne kadardır?
• Tasarıma dayanan yazılımın son ölçüsünü tasarım öngörüyor mu?
• Ayrıca bazı aykırılıkların belirlenmesinin temelinde matriks kullanma ve tasarımda olan problemleri belirleme

Tasarım yapılarına dayanan tasarım ölçevlerinin işlevi,belirli bir tasarımın uygulama aşamasında problemlere yol açabilecek tasarım zayıflığını belirlememize izin vermelidir.Ayrıca, sonunda bu tasarımın temelinde geliştirilmiş yazılımın bakım kolaylığındaki problemleri tahmin etmede kolaylık sağlamalıdır.Fakat tasarım yapı ölçevleri, bir yazılım tasarımındaki modüllerinin ölçülerini göz önünde blundurmayacaktır.

Henry ve Kafura’nın bilgi akış ölçevi, sisteminin karmaşık yapısını yakalamaya çalışır ve tasarım yapma süreci için belirli nicel esas sağlar.Fakat,bu ölçev bir yazılımın bakım kolaylığı ve kusur eğilimi derecesini doğru tahmin etmede yardımcı olmaz.Bir bileşenin uzunluğunu kendisi tasarım aşamasındayken kullanmak, tasarımcı bunu belirleyemiyebileceği için zordur.Ayrıca,bu ölçevlerde eğer faktörlerden biri örneğin giriş yelpazesi ya da çıkış yelpazesi eksikse, o zaman karmaşıklığın kendisi sıfıra düşürülür.Bu ölçev kullanışsızlığını oluşturur.

Yazılım kalitesinin esas tanımı, belirlenmiş nitelik derecesindeki önceden belirlenmiş işlevsel ihtiyaçları karşılaması gerektiğidir.Onaylanmış olabilecek yazılıma karşı birçok sayıda nitelik faktörleri vardır.Bir tasarımın modülerliği kalite yazılımı için önemli bir kriterdir ve en iyi modüller yapısını tahmin edecek ölçevler gereklidir.

Yazılım tasarımı, yazılım mühendisinin bir tasarımının üzerine bir diğerini seçmek için kullanacağı yinelemeli bir süreçtir.Bu yüzden ölçevler farklı tasarım çözümleri arasında karşılaştırmalar yapmanın temelinde, aykırı değer modüllerini belirlemede kullanılabilir ve böylece yazılım mühendisinin daha iyi ve etkin tasarımlarla gelmesine yardımcı olur.