在排除了市場因素產(chǎn)生的風(fēng)險(xiǎn)之后，我們應(yīng)該保證需求描述的質(zhì)量。人與人的交流總會(huì)存在一些誤會(huì)，同樣一句話，心情不好與心情好的時(shí)候聽起來可能會(huì)截然相反，正是因?yàn)槿藗冎g存在著理解上的偏差，在描述需求的語言上就應(yīng)該注意盡量避免歧義的產(chǎn)生。如果對UML比較熟悉的話，需求分析可以利用UML工具進(jìn)行，這樣可以減少一些自然語言引起的歧義，但是并不是所有的用戶都了解UML各種圖形的意思，與用戶溝通起來存在障礙，除了工具之外，我們可以從以下幾個(gè)方面來保證需求描述的質(zhì)量。
    首先，看句子和段落是否簡短。長句子看起來會(huì)非常困難，很難弄懂真正的需求：另外，過長的句子和段落容易讓人忽視一些需求。所以，如果一個(gè)句子不能完全描述清楚需求，應(yīng)該將其拆分成多個(gè)小句子。
    其次，句子是否有語法錯(cuò)誤，還要注意標(biāo)點(diǎn)符號，有時(shí)，標(biāo)點(diǎn)符號點(diǎn)錯(cuò)了就完全成了另外一個(gè)意思。再次，是否存在模糊不清的需求，出現(xiàn)“可能，大概，或者”等詞匯表述。
    最后，注意是否存在形容詞及比較性詞語，比如：容易的、快速的、方便的、有效的、許多、很少、簡單、復(fù)雜、最新的、界面友好的、減少、擴(kuò)大，不小于等等，需要將描述性詞語進(jìn)行量化，并且給出具體值或者范圍。
    另外，保證需求質(zhì)量的一個(gè)很重要的因素就是需求是否細(xì)化，如果需求不細(xì)化就很容易造成代碼的返工，出現(xiàn)程序員盡管加班加點(diǎn)卻總是不能如期完成任務(wù)的情景。怎樣才能判斷需求細(xì)化的程度呢？需求細(xì)化程度確實(shí)很難把握，什么樣的需求可以算是比較細(xì)了，不用再進(jìn)行細(xì)化了呢？
    答案是：是否可以將需求寫出相應(yīng)的測試用例，如果寫不出來，就說明需求還不是很細(xì)，還需要進(jìn)一步進(jìn)行細(xì)化。
    把握住了需求分析這一關(guān)，下一站我們就可以進(jìn)行設(shè)計(jì)了。
    軟件架構(gòu)設(shè)計(jì)在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會(huì)涉及到方方面面的角色。
    例如：用戶、項(xiàng)目管理人員、程序員、測試員、維護(hù)人員等等。不同的角色對架構(gòu)設(shè)計(jì)的要求也不相同。對于程序員來說更關(guān)注模塊是否清晰，類的功能是否單一等等，對于測試人員來說，關(guān)注的是系統(tǒng)的可測試性。對于維護(hù)人員來講，系統(tǒng)的擴(kuò)展性、可維護(hù)性如何？
    一個(gè)高質(zhì)量的軟件架構(gòu)，應(yīng)該限度的考慮并滿足不同角色的不同要求。因此我們在進(jìn)行軟件設(shè)計(jì)的時(shí)候，應(yīng)該進(jìn)行全面的考慮。一般用來衡量軟件設(shè)計(jì)質(zhì)量的標(biāo)準(zhǔn)可以從以下幾個(gè)方面來考慮：
    ◆功能性
    包括完全性、正確性、安全性、兼容性、互用性。
    ◆效率
    產(chǎn)品運(yùn)行的時(shí)間效率和利用的硬件資源兩方面。
    ◆維護(hù)性
    包括架構(gòu)的可改正性，可擴(kuò)充性以及可測試性。如果用戶的一個(gè)很小的需求變更會(huì)引起架構(gòu)設(shè)計(jì)很大的變化，那么這樣的架構(gòu)設(shè)計(jì)的可改正性和可擴(kuò)充性就比較差。