需求管理之如何對客戶的需求進行分類

      不要指望你的客戶會給需求分析者提供一個簡潔、完整、組織良好的需求清單。分析者必須把代表客戶需求的許多資訊分成不同的類型，這樣他們就能合理地編寫資訊文檔并把它們用于最合理的方式上。那些不屬于這些類型的資訊可能代表一個非軟體項目的需求，例如，為使用新系統而進行的使用者教育訓練或者它僅僅是不重要的資訊。

     下面讨論在聽取客戶需求過程中的一些建議，這将有助于對資訊進行分類處理。

      1) 業務需求，描述客戶或開發公司可以從産品中得到的資金、市場或其它業務利潤的需求就是最可能的業務需求。再聽聽直接或間接的軟體使用者得到好處，例如“市場股票價格上升x %”，“每年節約$ Y”，或“替代了維護費用高的老一代系統Z”。

      2) 使用執行個體或說明有關利用系統執行的業務任務或達到使用者目标的總的陳述可能就是使用執行個體，而特定的任務描述表示了用法說明。與客戶一起商讨，把特定的任務概括成更廣泛的使用執行個體。可以通過讓客戶描述他們的業務工作流活動來擷取使用執行個體。

      3) 業務規則，當一個客戶說，一些活動隻能在特定的條件下，由一些特定的人來完成時，該使用者可能在描述一個業務規則，例如，“如果一個藥劑師在危險化學制品教育訓練方面是可靠的，那麼他就可以在一級危險藥品清單上訂購化學制品”。業務規則是有關業務過程的操作原則。你可以用一些軟體功能需求來加強規則，例如，讓“化學制品跟蹤系統”可以通路教育訓練記錄資料庫。正如上面所說的那樣，這裡業務規則不是功能需求。

      4) 功能需求，客戶所說的諸如“使用者應該能<執行某些功能>”或者“系統應該<具備某些行為〉”，這是最可能的功能需求。功能需求描述了系統所展示的可觀察的行為，并且大多數是處于執行者—系統響應順序的環境中。功能需求定義了系統應該做什麼，它們組成了軟體需求規格說明的一部分。分析者應該明确，每個人應了解系統為什麼“必須”執行某一功能。所提出的功能需求有時反映了過時的或無效的業務過程，而這些過程不能加入到新系統中。

      5) 品質屬性，對系統如何能很好地執行某些行為或讓使用者采取某一措施的陳述就是品質屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡易、直覺性、使用者友外部接口需求好、健壯性、可靠性、安全性和高效性。你将要和使用者一起商讨精确定義他們模糊的和主觀言辭的真正含義。

      6) 外部接口需求，這類需求描述了系統與外部的聯系。軟體需求規格說明必須包括使用者接口和通信機制、硬體和其它軟體系統需求部分。客戶描述外部接口需求包括如下習慣用語：

      • “從<某些裝置〉讀取信号”

      • “給<一些其它系統>發送消息”

      • “以<某種格式>讀取檔案”

      • “能控制<一些硬體>”

      7) 限制，限制是指一些合理限制設計者和程式員選擇的條件。它們代表了另一種類型的非功能需求，你必須把這些需求寫入軟體需求規格說明。盡量防止客戶施加不必要的限制，因為這将妨礙提出一個好的解決方案。不必要的限制将會降低利用現有商業化軟體內建解決方案的能力。一定的限制有助于提高産品品質屬性。隻利用程式語言的标準指令而不允許使用供應商的擴充，可以提高可移植性。下面是客戶描述限制的一些習慣用語：

       • “必須使用<一個特定的資料庫産品或語言>”

       • “不能申請多于<一定數量的記憶體>”

       • “操作必須與<其它系統>相同”

       • “必須與<其它應用程式>一緻”

      8) 資料定義，當客戶描述一個資料項或一個複雜的業務資料結構的格式、允許值或預設值時，他們正在進行資料定義。例如，“郵政編碼由5個數字組成，後跟一個可選的短劃線或一個可選的四位數字，預設為0 0 0 0”就是一個資料定義。把這些集中在一個資料字典中，作為項目的參與者在整個項目的開發和維護中的主要參考文檔。

      9) 解決思想，如果一個客戶描述了使用者與系統互動的特定方法，以使系統産生一系列活動（例如：使用者從下載下傳清單中選擇一個所需要的項），這時你正在聽取建議性的解決方案，而不是需求。所建議的解決方案使擷取需求小組成員在潛在的真正需求上分散精力。在擷取需求時，應該把重點放在需要作什麼而不是新系統應該如何設計和構造。探讨客戶為什麼提出一個特定的實作方法，因為這可以幫助你了解真正的需求和使用者對如何構造系統的隐含的期望。