項目范圍：項目該做什么，不該做什么，需要在一開始就有明確的定義。對于項目范圍內的需求，一個也不要放過，而項目之外的，一個也不要去關心。雖然有的時候，范圍的變化會有利于項目本身，例如客戶的合理要求或是市場目標客戶的變化，但是這種變化應該要在"資源能夠支持"和"得到審批"的前提下進行。
項目范圍的描述可以通過陳述和圖示來進行。我建議大家使用圖示。因為陳述語句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務系統。"這句話就是含糊不清的，你的電子商務系統是銷售什么產品？面向什么客戶？是否要支持在線支付？根據這些疑問，這個陳述句可以做進一步的修改，"建立在線訂貨系統，針對當前的目標客戶銷售公司的目前產品。"這樣就清楚許多了。不過圖示的方法會更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據經驗，DFD圖比較容易為客戶所接受。
高階需求：這個部分我們在下面會詳細討論。既然是高階需求，就不能討論過多的細節。在討論高階需求的時候，盡量保證快速的討論出系統的概貌，建立需求模型，得到項目涉眾的一致通過。
取得支持：為了保證需求計劃的順利進行，取得項目涉眾的支持至關重要。你可以選擇在這個時候告訴項目涉眾他們的權利和義務，以及開發人員的權利和義務。在這個方面，具體的我不想多說，大家可以參考『軟件需求』的第二章。主要的就是"涉眾有改變需求的權利，同時要承擔向開發人員講解需求的義務。"開發人員的權利和義務正好和涉眾相反。
業務建模會議：所有的這一切都通過業務建模會議進行，和其它會議不同的是，這個會議需要所有的項目涉眾參加，如果不能獲取所有項目涉眾的意見，那就不是完美的。會議中最重要的工具就是白板，一位出色的速記員也是必須的。
建模原理
5. 業務建模中的用例
在上一篇中我們討論了很多用例的知識，可是落實到企業中的時候，我們往往會感覺難以把握企業的用例，這一點我們在用例的誤區中也有提到。在實際的情況中，你可能會對角色的歸類，用例的劃分，粒度的把握等很細節的方面都沒有底，偏偏這些實際的東西對你的項目有非常大的影響。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
