一、需求的分類
需求分析是構建軟件系統(tǒng)的一個重要過程。一般，把需求類型分成三個類型:
1、業(yè)務需求（business requirement）反映了組織機構或客戶對系統(tǒng)、產品高層次的目的要求，它們在項目視圖與范圍文檔中予以說明。
2、用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。
3、功能需求(functional requirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。
業(yè)務需求和用戶需求是軟件需求分析的基礎，也是軟件構建的前提。系統(tǒng)分析員通過對業(yè)務需求和用戶需求的分解，將其轉換成克一形式化描述的軟件功能需求。開發(fā)軟件系統(tǒng)最為困難的部分，就是準確說明開發(fā)什么。這就需要在開發(fā)的過程中不斷的與用戶進行交流與探討,使系統(tǒng)更加詳盡,準確到位。這就需要確定用戶是否需要這樣的產品類型以及獲取每個用戶類的需求。
二、需求的質量分解
一般情況下，采用如下的手段描述軟件需求的質量：
正確性：所有需求必須是正確的、合理的、滿足任務書要求的。
必要性：所有需求必須是為完成指定任務所必需的。
可行性：在指定的環(huán)境和條件下，所有的需求必須是可行的。
完備性：為完成指定任務，這些需求是完備的、無遺漏的。
一致性：所有需求相互之間沒有矛盾，是一致的。
非退化：任一需求的引入都不會導致軟件性能的退化。
無歧義：任一需求的陳述都是確定的、不會導致多義性的。
可驗證：任一需求都是可以測試、可以驗證的。
可追蹤：人以需求都可以追蹤到項目的任務書或規(guī)格說明的需求。
三、需求的隱含質量要求
除了這些可以量化的質量標準，還有一些需求的標準是隱含的。這些要求及時客戶沒有提出來，在實現(xiàn)的時候也應該考慮到，否則，可能導致項目的失敗。
操作方便：每一個客戶都會有操作方面的要求，只是具體的表現(xiàn)方式不一樣。一般，客戶在開始的時候對操作很難對操作有很具體的考慮，他會想當然個認為新的軟件系統(tǒng)會和他以前所熟悉的某一個系統(tǒng)類似。而事實并非如此。當他發(fā)現(xiàn)新的軟件系統(tǒng)不方便使用的時候，就會提出修改的建議。有的時候，這種修改對軟件系統(tǒng)的影響是災難性的。
可以保證操作質量：一般，系統(tǒng)分析員會認為客戶應該勾畫出系統(tǒng)運行過程中可能發(fā)現(xiàn)的重要風險，然后在系統(tǒng)實現(xiàn)的時候予以考慮。然而，在溝通的過程中，客戶認為的重要的風險會和系統(tǒng)分析員所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因為對于客戶而言，這些內容應該是顯而易見的；而系統(tǒng)分析員一把并不了解這些事實。例如，在一個管理保險公司客戶的系統(tǒng)里面，修改職業(yè)是需要嚴格審核的，如果系統(tǒng)分析員以前接觸的業(yè)務以電子商務居多，他可能自然而然的認為客戶修改職業(yè)僅僅是一個一般性的變更。
四、客戶對需求的影響
目前很多系統(tǒng)分析員在進行需求分析的時候，把主要精力放在了解客戶的業(yè)務流程，并試圖將其用形式化的手段描述。而事實上，這樣了解到的客戶需求往往是不完整的，甚至具有很大的片面性。除了隱含需求的定義比較困難以外，客戶本身也是影響需求質量的一個重要因素。
1、客戶有不同的需要。一些客戶知道他們需要什么，而另外一些人知道他們不需要什么。一些客戶希望進行詳細討論，而另外一些客戶則滿足于模糊的承諾。
2、客戶有不同的個性。
3、客戶和供應商之間有著不同的通信方式。一些人非常熟悉產品以及生產廠商，而另外一些人則可能素未謀面，僅僅通過信件往來和幾個匆忙的電話與生產廠商溝通。
4、客戶也經常是矛盾的。事實上，很少有客戶能夠明確的知道怎樣的一個系統(tǒng)對自己是最有益處的，他們往往在集中方案之間徘徊，于是經常產生需求的變動。生產廠商經常陷入客戶自己的矛盾之中。
客戶的負面影響可能對于能夠在預算內按時完成項目產生很大的影響。盡管客戶需要對需求的質量負責任，但是，當一個軟件項目因為客戶事先沒有預料到的情況而導致失敗的時候，即使客戶不會追究開發(fā)方的責任，就軟件項目本身而言，也已經是失敗的。
五、目前控制需求質量的手段
目前，項目經理和系統(tǒng)分析員主要通過聽證、評審、確認等手段控制軟件需求的質量。
聽證：主要是指通過正式或者非正式的渠道召開有關人員的會議，聽求大家對新的軟件系統(tǒng)的要求和意見。
評審：組織有關的專家對軟件需求進行評價，指出目前的需求由那些不合理的地方，以及修改的意見等。評審一般發(fā)生在初步的軟件需求已經形成以后。
確認：開發(fā)方將整理過的需求分析說明書交給客戶確認。如果客戶認可該需求分析說明書，就形成正式的需求分析文檔，并作為一個重要基線管理。
這些需求控制手段可以提高軟件需求的質量，但是仍然無法保證需求是可用的。因為：
1、聽證會的參與者并不一定代表使用者的真實意圖。實踐中經常遇到這樣的情況。即使他是目標軟件的最主要使用者，他也經常會遺忘一些他覺得是很基本的，而事實上對于軟件系統(tǒng)是很重要的細節(jié)。
2、參與評審的專家并不一定對軟件的最終質量負責，因此，他可能把工作的重點放在發(fā)現(xiàn)需求中的問題，而不是確認需求是否可行。
3、客戶確認只代表客戶對需求負責人，不代表客戶承認需求的質量。如果因為需求的質量導致軟將項目無法進展，客戶只能承擔經濟上的責任，而項目小組并不能因此緩解軟件項目陷入的尷尬。
需求分析是構建軟件系統(tǒng)的一個重要過程。一般，把需求類型分成三個類型:
1、業(yè)務需求（business requirement）反映了組織機構或客戶對系統(tǒng)、產品高層次的目的要求，它們在項目視圖與范圍文檔中予以說明。
2、用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。
3、功能需求(functional requirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務，從而滿足了業(yè)務需求。
業(yè)務需求和用戶需求是軟件需求分析的基礎，也是軟件構建的前提。系統(tǒng)分析員通過對業(yè)務需求和用戶需求的分解，將其轉換成克一形式化描述的軟件功能需求。開發(fā)軟件系統(tǒng)最為困難的部分，就是準確說明開發(fā)什么。這就需要在開發(fā)的過程中不斷的與用戶進行交流與探討,使系統(tǒng)更加詳盡,準確到位。這就需要確定用戶是否需要這樣的產品類型以及獲取每個用戶類的需求。
二、需求的質量分解
一般情況下，采用如下的手段描述軟件需求的質量：
正確性：所有需求必須是正確的、合理的、滿足任務書要求的。
必要性：所有需求必須是為完成指定任務所必需的。
可行性：在指定的環(huán)境和條件下，所有的需求必須是可行的。
完備性：為完成指定任務，這些需求是完備的、無遺漏的。
一致性：所有需求相互之間沒有矛盾，是一致的。
非退化：任一需求的引入都不會導致軟件性能的退化。
無歧義：任一需求的陳述都是確定的、不會導致多義性的。
可驗證：任一需求都是可以測試、可以驗證的。
可追蹤：人以需求都可以追蹤到項目的任務書或規(guī)格說明的需求。
三、需求的隱含質量要求
除了這些可以量化的質量標準，還有一些需求的標準是隱含的。這些要求及時客戶沒有提出來，在實現(xiàn)的時候也應該考慮到，否則，可能導致項目的失敗。
操作方便：每一個客戶都會有操作方面的要求，只是具體的表現(xiàn)方式不一樣。一般，客戶在開始的時候對操作很難對操作有很具體的考慮，他會想當然個認為新的軟件系統(tǒng)會和他以前所熟悉的某一個系統(tǒng)類似。而事實并非如此。當他發(fā)現(xiàn)新的軟件系統(tǒng)不方便使用的時候，就會提出修改的建議。有的時候，這種修改對軟件系統(tǒng)的影響是災難性的。
可以保證操作質量：一般，系統(tǒng)分析員會認為客戶應該勾畫出系統(tǒng)運行過程中可能發(fā)現(xiàn)的重要風險，然后在系統(tǒng)實現(xiàn)的時候予以考慮。然而，在溝通的過程中，客戶認為的重要的風險會和系統(tǒng)分析員所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因為對于客戶而言，這些內容應該是顯而易見的；而系統(tǒng)分析員一把并不了解這些事實。例如，在一個管理保險公司客戶的系統(tǒng)里面，修改職業(yè)是需要嚴格審核的，如果系統(tǒng)分析員以前接觸的業(yè)務以電子商務居多，他可能自然而然的認為客戶修改職業(yè)僅僅是一個一般性的變更。
四、客戶對需求的影響
目前很多系統(tǒng)分析員在進行需求分析的時候，把主要精力放在了解客戶的業(yè)務流程，并試圖將其用形式化的手段描述。而事實上，這樣了解到的客戶需求往往是不完整的，甚至具有很大的片面性。除了隱含需求的定義比較困難以外，客戶本身也是影響需求質量的一個重要因素。
1、客戶有不同的需要。一些客戶知道他們需要什么，而另外一些人知道他們不需要什么。一些客戶希望進行詳細討論，而另外一些客戶則滿足于模糊的承諾。
2、客戶有不同的個性。
3、客戶和供應商之間有著不同的通信方式。一些人非常熟悉產品以及生產廠商，而另外一些人則可能素未謀面，僅僅通過信件往來和幾個匆忙的電話與生產廠商溝通。
4、客戶也經常是矛盾的。事實上，很少有客戶能夠明確的知道怎樣的一個系統(tǒng)對自己是最有益處的，他們往往在集中方案之間徘徊，于是經常產生需求的變動。生產廠商經常陷入客戶自己的矛盾之中。
客戶的負面影響可能對于能夠在預算內按時完成項目產生很大的影響。盡管客戶需要對需求的質量負責任，但是，當一個軟件項目因為客戶事先沒有預料到的情況而導致失敗的時候，即使客戶不會追究開發(fā)方的責任，就軟件項目本身而言，也已經是失敗的。
五、目前控制需求質量的手段
目前，項目經理和系統(tǒng)分析員主要通過聽證、評審、確認等手段控制軟件需求的質量。
聽證：主要是指通過正式或者非正式的渠道召開有關人員的會議，聽求大家對新的軟件系統(tǒng)的要求和意見。
評審：組織有關的專家對軟件需求進行評價，指出目前的需求由那些不合理的地方，以及修改的意見等。評審一般發(fā)生在初步的軟件需求已經形成以后。
確認：開發(fā)方將整理過的需求分析說明書交給客戶確認。如果客戶認可該需求分析說明書，就形成正式的需求分析文檔，并作為一個重要基線管理。
這些需求控制手段可以提高軟件需求的質量，但是仍然無法保證需求是可用的。因為：
1、聽證會的參與者并不一定代表使用者的真實意圖。實踐中經常遇到這樣的情況。即使他是目標軟件的最主要使用者，他也經常會遺忘一些他覺得是很基本的，而事實上對于軟件系統(tǒng)是很重要的細節(jié)。
2、參與評審的專家并不一定對軟件的最終質量負責，因此，他可能把工作的重點放在發(fā)現(xiàn)需求中的問題，而不是確認需求是否可行。
3、客戶確認只代表客戶對需求負責人，不代表客戶承認需求的質量。如果因為需求的質量導致軟將項目無法進展，客戶只能承擔經濟上的責任，而項目小組并不能因此緩解軟件項目陷入的尷尬。