需求獲取過程中的逆向溝通

需求分析是構建軟件系統的一個重要過程。一般，把需求類型分成三個類型: 
1、業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目的要求，它們在項目視圖與范圍文檔中予以說明。
2、用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。
3、功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。
業務需求和用戶需求是軟件需求分析的基礎，也是軟件構建的前提。系統分析員通過對業務需求和用戶需求的分解，將其轉換成克一形式化描述的軟件功能需求。開發軟件系統最為困難的部分，就是準確說明開發什么。這就需要在開發的過程中不斷的與用戶進行交流與探討,使系統更加詳盡,準確到位。這就需要確定用戶是否需要這樣的產品類型以及獲取每個用戶類的需求。

二、需求的質量分解

一般情況下，采用如下的手段描述軟件需求的質量：
正確性：所有需求必須是正確的、合理的、滿足任務書要求的。
必要性：所有需求必須是為完成指定任務所必需的。
可行性：在指定的環境和條件下，所有的需求必須是可行的。
完備性：為完成指定任務，這些需求是完備的、無遺漏的。
一致性：所有需求相互之間沒有矛盾，是一致的。
非退化：任一需求的引入都不會導致軟件性能的退化。
無歧義：任一需求的陳述都是確定的、不會導致多義性的。
可驗證：任一需求都是可以測試、可以驗證的。
可追蹤：人以需求都可以追蹤到項目的任務書或規格說明的需求。

三、需求的隱含質量要求

除了這些可以量化的質量標準，還有一些需求的標準是隱含的。這些要求及時客戶沒有提出來，在實現的時候也應該考慮到，否則，可能導致項目的失敗。
操作方便：每一個客戶都會有操作方面的要求，只是具體的表現方式不一樣。一般，客戶在開始的時候對操作很難對操作有很具體的考慮，他會想當然個認為新的軟件系統會和他以前所熟悉的某一個系統類似。而事實并非如此。當他發現新的軟件系統不方便使用的時候，就會提出修改的建議。有的時候，這種修改對軟件系統的影響是災難性的。
可以保證操作質量：一般，系統分析員會認為客戶應該勾畫出系統運行過程中可能發現的重要風險，然后在系統實現的時候予以考慮。然而，在溝通的過程中，客戶認為的重要的風險會和系統分析員所理解的有所不同，而被忽略的一部分，往往是很基本的那部分，因為對于客戶而言，這些內容應該是顯而易見的；而系統分析員一把并不了解這些事實。例如，在一個管理保險公司客戶的系統里面，修改職業是需要嚴格審核的，如果系統分析員以前接觸的業務以電子商務居多，他可能自然而然的認為客戶修改職業僅僅是一個一般性的變更。

原文轉自：http://www.kjueaiud.com