SQA本身的意義在於透過一系列的方法(例如：Review、Audit)，去提供幕僚人員及管理者在於「產品與產出產品的過程是符合標準、要求及規範」的信心。

因此SQA與其他的支援性過程，例如Configuration Management、Verfication、Validation、Review、Audit、Problem Resolution、Change Management....等等不宜直接劃上等號或視為包含關係。從ISO的品質管理系統來說，要求所謂的「說、寫、做合一」，能不能通過ISO的稽核，主要是看你訂了多少規範與要求(這些要求與ISO 9001:2000的要求應該是要一致的，這是前提之一)，這些規範與要求你有沒有說到做到，做到了就可以通過認證。當然這也就是為什麼有人會垢病─按照標準還是做不好，其實並沒有這種問題，因為各公司只是按自己訂的制度在走而已，至於有沒有真的力行，那是另外一回事。

至於有了品質管理制度之後，卻沒有能把事情做好，這並不是出在品質管理系統或者SQA的問題(假設公司有按照自己訂出來的制度在執行)，所以就有一些過程標準，不論是從軟體角度出發的，或是從組織角度出發的標準：這些標準包括：
1. 過程角度：ISO/IEC 12207軟體生命週期過程、ISO/IEC 15288系統生命週期過程
2. 組織角度：CMMI以及CMMI前身框架(SW-CMM、SE-CMM、SA-CMM等等)
以上的這些標準，都包括了SQA及其他的軟體過程(含支援性過程)
組織可以將其中的過程要求，納到組織的品質管理系統當中，以改善及強化組織的軟體過程，進而達到所期望的品質，當然這些要被強化的過程當中是包括了SQA過程本身、CM的過程、驗證過程、確認過程、審查過程、稽核過程.....等等。因為這些過程都是屬於「品質」的一環。SQA屬於「品質」的一環，但並不代表有SQA就等於「品質」，因為若公司訂了SQA的過程，但是並沒有遵循此一規定的SQA過程來執行，那麼組織還是一樣「沒有品質」。SQA也不全然等於品質管理系統。

----------------
引文: