軟件客戶需求義務書
1. 給分析人員講解業務及說明業務方面的術語等專業問題。
2. 抽出時間清楚地說明需求并不斷完善。
3. 當說明系統需求時，力求準確詳細。
4. 需要時要及時對需求做出決策。
6. 對單項需求、系統特性或使用實例劃分優先級。
7. 評審需求文檔和原型。
8. 一旦知道要對項目需求進行變更，要馬上與開發人員聯系。
9. 在要求需求變更時，應遵照開發組織確定的工作過程來處理。
10. 尊重需求工程中開發人員采用的流程（過程）。
需求權利和義務規定了客戶和開發者雙方應該做些什么，雙方共同出力，確保需求過程的有序進行。不過，大多數的軟件公司一般都把“客戶是上帝”這句話貫徹的很好，客戶有什么樣的要求，軟件公司就做什么樣的修改，最終損害的是客戶和自己雙方的利益。一次，我和一個小軟件企業的技術總監聊起這方面的事情，請教他的做法。他在經歷了幾次銷售人員隨意答應客戶要求的痛苦之后，決定親自出動，在和客戶接觸的過程中掌握主動權，判斷客戶是不是一個“好”客戶，再決定做不做這個軟件。實施了一段時間后，發現效果非常的好，成本大幅度下降，客戶也很滿意。軟件開發過程中軟件企業和客戶是一對合作者，一榮俱榮，一損俱損。要達到雙方共贏的局面，只能靠充分的溝通。 需求分析和需求管理
需求的過程包括了兩個過程，需求管理和需求分析。如同一個公司開展業務離不開管理一樣，脫離了需求管理的需求過程很難做到順利的完成需求過程。當然，并不是所有的軟件公司都沒有需求管理，例如安排需求的時間也是需求管理的一方面，大多數的軟件公司都沒有一個科學的、
任何活動都離不開管理，需求過程也不例外。需求過程的活動分為需求管理和需求分析兩種。大多數人說不清楚需求管理和需求分析的差別，但是他們在進行需求過程的時候已經不知不覺的在開展需求管理和需求分析兩種活動了。這種行為就有點像一些小企業主，缺乏科學的、系統的管理知識，但你卻不能說他不懂管理，因為他有大量的實踐經驗。同樣的，一些不夠成熟的軟件企業在進行需求分析的時候，主要還是靠經驗，并沒有一個經過驗證的方法。 需求分析活動包括對一個軟件項目需求的獲取、分析、規格說明及驗證。典型需求分析的結果是軟件需求規格說明（System Requirements Specifications）及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線（baseline）。這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定（agreement）。工程項目可能會有其它的約定，例如可交付性、約束條件、進度安排、預算及合同約定等。但這些并不是需求過程主要考慮的因素。
需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動，如圖所示。需求管理強調：
1、控制對需求基線的變動。
2、保持項目計劃與需求一致。
3、控制單個需求和需求文檔的版本情況。
4、管理需求和聯系鏈之間的聯系或管理單個需求和其它項目可交付品之間的依賴關系。
5、跟蹤基線中需求的狀態。
和任何的管理活動一樣，需求管理的目的也是為了確保需求分析活動按照既定方針執行。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
