iT邦幫忙

DAY 2
5

UML學習過程分享-以EA為例系列 第 2

[Day 2]系統需求發展

系統分析中,最一開始也是最重要的「系統需求發展」,當要開發一個系統,SA需要瞭解user的需求,需要掌握需求,需要能描述需求。
這中間的過程,UML相關的diagram就可以幫上不少忙。
這邊不只要介紹UML的圖什麼時候適用,還要介紹訪談與需求確認的眉角。
需求發展,最常見的就是下面這張圖:

要怎麼樣把user真正要的需求引導出來,到最後讓開發團隊可以順利開發完成,這邊整理成一張心智圖給大家參考。
http://o.1.photo.xuite.net/1/2/1/e/hatelove/3229293/134714608.jpg
專案需求發展
需求發展

  1. 需求彙整最困難的部分,在於如何將user想要的系統,轉成user需要的系統
  2. 需求彙整與規格化的動作,是不斷重複的,直到對user需求達到一個清晰穩定的瞭解

User

  1. Not only people
  2. 會影響或被影響的人事物,皆為User

彙整與管理使用者需求

  1. 將需求訪談轉成結構化應用面需求
  2. 需求條列、分類
  3. 功能性
  4. 非功能性
  5. 介面requirement
  6. 效能需求
  7. rule
  8. 例外情形
  9. 對每一項需求編號
  10. 方便溝通
  11. 方便追蹤
  12. 文件產出(基本上以CMMI為主)
  13. 會議記錄
  14. 客戶提供資料記錄表
  15. 現行作業流程圖
  16. 需求彙整清單與glossary
  17. 系統軟體、硬體與網路架構
  18. 資料量分析表
  19. 若不需要PM可裁適
  20. 需求追溯表(RTM)
  21. 系統需求規格書

需求確認

  1. 取得專案成員認同(內部成員,如SA、PM)
  2. 取得user認同
  3. 彙整報告會議
  4. 審查會議
  5. 交付需求分析文件
  6. 文件審查
  7. User簽名

Models

  1. 三個面向
  2. Level
  3. Scope level
  4. Scope
  5. High level
  6. Conceptual(brief description)
  7. Low level
  8. Detail description
  9. Focus
  10. who
  11. 影響與被影響的actor
  12. what
  13. 流程、規範等
  14. when
  15. 何時使用、使用的頻率與時間分佈
  16. where
  17. 網路與實體機器位置等
  18. why
  19. 為何需要,有什麼樣的問題需要被解決
  20. how
  21. 如何滿足需求
  22. View
  23. Behavior
  24. Use Case Diagram
  25. Flow chart
  26. Structure
  27. Data model
  28. Class Diagram
  29. Dynamic
  30. Statechart Diagram
  31. Event table
  32. Control
  33. 作業規範
  34. business policy
  35. 常用的model與適用時機
  36. What do we means
  37. Glossary
  38. Who's affected by the project?Who affects it
  39. Stakeholder Classes
  40. 關鍵人員
  41. 外部界接系統也可能是關鍵人員之一
  42. Who does it
  43. Actor table
  44. Actor map
  45. What must be true?What policies do we have?
  46. Business Policies
  47. Business Rule
  48. Decision Table
  49. Decision Tree
  50. When will it happen?What will result?
  51. Event table
  52. What does need to do?
  53. Event-driven system
  54. Who or what parts of organization are involved?
  55. Relationship Map
  56. What data is needed?
  57. Domain Model
  58. High level
  59. 將現實世界問題,使用圖解方式表達Conceptual class or object
  60. What information action need?
  61. When will the data change?
  62. Statechart Diagram
  63. 例如Insert、Edit狀態改變
  64. What processes will go on?In what sequence will things done?
  65. Process Map
  66. Flow chart
  67. Use cases
  68. 描述Actor與系統內功能的關聯
  69. 定時或批次處理的驅動actor
  70. timer
  71. Use Case Map (Activity diagram)
  72. What are dependencies among use cases?
  73. Use Case Packages
  74. What are examples of what will happen?
  75. Scenarios
  76. What will the system look like?
  77. User Interface Navigation Diagram
  78. 類似以UI為entity的flow chart
  79. Prototype

SA的責任

  1. 引導(Elicitation)
  2. 可透過一連串的問答來引導user,找到user真的想要與需要的系統
  3. Analysis
  4. 找到消失的需求(missing requirement)
  5. 例如透過CRUDL matrix找出消失的操作
  6. 五種權限
  7. Create
  8. Read
  9. Update
  10. Delete
  11. List
  12. 二維matrix
  13. X: entity
  14. Y: use cases
  15. Specifation
  16. 將需求轉換成規格文件及model
  17. Validation
  18. 確認需求

上一篇
[Day 1]UML與EA的簡介
下一篇
[Day 3]Use Case Diagram簡介
系列文
UML學習過程分享-以EA為例30

2 則留言

0
Ken(Bigcandy)
iT邦大師 1 級 ‧ 2009-10-05 10:08:18

感謝+1,辛苦了

0
ithomelee
iT邦研究生 1 級 ‧ 2009-12-14 15:47:38

請教大家:需求追溯表可否作為驗收的依據?

我要留言

立即登入留言