一、需要需求的地方有:
1、項目的范圍;
2、成本估算;
3、預算;
4、項目計劃;
5、軟件設計和測試;
6、文檔和培訓手冊;
二、記錄需求的方式有:
1、Stackholder的需要(涉眾的需要);
2、軟件特性;
3、軟件需求規格,要求無二義性,完整,一致,可跟蹤,并且不含設計信息;
它們的層次如下

三、需求產物
業務用例模型。 所期望系統的目標經常是要解決業務問題或通過提供增值服務開拓商業機會。業務用例將用例的概念擴展為描述業務過程。業務用例模型(與業務用例規格說明一起)提供了一種評價所期望系統范圍的方式--有些部分可以自動化,有些部分不能,有些部分可以通過更改業務過程來進行。這就允許我們從一種業務觀點來評價用例模型的完整性,因為每個系統用例必須支持一個或更多的業務用例。
業務實體和領域模型。 大多數系統需要操作和展現業務信息。一個業務實體將一組相關信息字段表示為類。業務實體通過一個業務過程(例如業務用例)被處理和操作,它們接著通過系統用例被自動化。所有業務用例及它們關系的總和組成了領域模型,領域模型描述了問題域。每個系統用例將操作一些實體,并且實體通常被包括在多個系統用例中。
業務規則。 今天,系統的復雜性通常是由系統必須符合的業務規則的復雜性所導致的結果。業務規則將被業務用例和系統用例來表示,并且可以是各種形式,決策表,計算規則,決策樹,時間圖(描述哪些事件必須發生在其它事件之前或之后,以及從中產生的過程),運算法則,等等。在用例流中描述業務規則通常會把用例規格弄得混亂。因此,它們通常是在單獨的工件中被捕獲,或者是作為用例規格的附加物。
用戶體驗模型和情節串連圖板 用戶體驗建模是捕獲用戶界面需求而不借助于畫出屏幕布局的一種便利方式,畫出屏幕布局的方式可能要花費巨大的工作量,并且非常可能發生變更。用戶體驗建模將實際的用戶界面屏幕抽象為一個UML類,其原型是«screen»。屬性確定了用戶在一個屏幕上可以看到什么;操作確定了用戶在每個屏幕上可以做什么;并且關聯關系確定了航行路線。用戶體驗情節串連圖板是用戶體驗模型的子集,用于描述與系統用例有關的屏幕。
補充規格說明。 補充規格說明描述了影響多個用例的需求。例如,所有用例都服從權限控制,審計跟蹤,個性化,等等。補充需求實際上通常是技術方面的,并且可以是關聯于功能、可用性、可靠性、性能以及可支持性。它們通常被表示為“系統應做 ...”形式的陳述語句
