P2_C4-7：初始階段

初始階段：利益相關人就產品範圍、願景、使用場景達成一致

Inception is not requirements phase

---

閱讀書上第4章

Inception Phase 初始階段：預見項目的範圍、設想和業務案例

• 初始階段須要考慮的事情：繼續仍是中止？購買仍是本身構建？話費？涉衆是否有統一見解？
• 大多數analysis 是在elaboration中進行的
• inception 階段的activity和artifacts：vision、10~20%的用例、計劃書等等
• 該階段時間要短，若是到一週甚至多周，進入了更深的研究就失去了意義

Evolutionary requirements

---

閱讀書上第5章

Requirements

• 需求是項目必須提供的能力和必須知足的條件
  • Goal：肯定並文檔出真實的需求
  • Challenge： 定義沒有歧義的需求
• 需求的類型能夠按照「FURPS+」模型來進行分類和管理
  • Functional（功能性）
  • Usability （可用性）
  • Reliability （可靠性）
  • Performance （性能）
  • Supportability （可維護性）
• UP會產生的需求製品：如下爲可選的關鍵製品
  • 用例模型、補充性規格說明、詞彙表、願景書、業務規則

Use cases

---

閱讀書上第6章

Actors(參與者)：與系統進行交互的外部實體，如人、計算機、組織等。

• Primary actors：
  • 特色：使用sud完成所具備的用戶目標。
  • 做用：發現驅動用例的用戶目標
• Supporting actors：
  • 特色：爲sud提供服務，一般是一個系統
  • 做用：爲了明確外部接口和協議
• Offstage actor：
  • 特色：在用例性爲中有影響或獲益，如政府機構
  • 做用：完備考慮利益關係

Use Case， 爲知足駐澳參與者的目標而定義用例

• 在FURPS中強調「F」， 功能性需求
• scenario/use case instance：參與者和系統的一系列交互和活動
• use case： 一組相關的成功和失敗的場景集合
• UML use case：提供了一個很好的系統的語境圖
• Use Case 的三種常見形式
• Brief： 一段摘要，在早期的需求分析中很快獲得的，主要用於成功場景
  • Casual：覆蓋多個不通場景
  • Fully：（模板：書上P50）詳細編寫全部步驟和全部變化，包括前置條件和成功保證
    • use case name： 以動詞開始
    • level：user-goal（實現）或subfunction（支持）
• 用essential風格編寫用例（擺脫UI）
  • essential style： 管理員標識本身的身份
  • concrete style： 管理員在對話框中填寫了本身的ID和密碼
• black-box use cases：不對內部工做構件進行秒速，只經過職責來描述
• take an actor and actor-goal perspective：關注涉衆及其關注點
• 如何發現用例
  • choose system boundary：
  • identity the primary actors and their goals
  • define use cases that satisfy user goals :基於參與者/基於事件
• 什麼測試有助於發現用例
  • boss test：
  • EBP test：一我的於某個時刻在一個地點所執行的任務
  • size test：規模不能過小，如輸入定義、移動棋子

應用UML

• 用例圖
  • 準則：繪製簡單的用例圖，並與 參與者-目標 列表關聯。重點是文本而不是圖
• 活動圖
  • 描述某一用例中執行的步驟，使業務流程可視化
  • 可用於早期描述重要場景，用業務流程圖識別用例
  • 重要的表示符號！！（ppt P66）

Other requirements

---

閱讀書上第7章

除了用例之外的需求製品：

• supplementary specifications：各類類型的補充說明，包括URPS中的一些元素（樣例：書上P78）
• glossary：數據字典
• vision：項目的設想（樣例：書上P82），文檔中包含的特性最好少於10個
• business rules（domain rules）：長期政策法規