什么是軟件開發業務建模分析和結構化建模分析


軟件開發業務建模分析

業務建模

三級需求:業務需求、用戶需求、系統需求(也叫功能需求)

簡單理解:
  • 業務需求:怎么實現盈利,怎么吸引用戶。

    • ” OKR(Objectives and Key Results)“目標與關鍵成果法,業務需求的目標是吸引用戶,獲得盈利,所以在描述業務需求的時候,需要方法技巧。

      OKR的主要目標是明確公司和團隊的“目標”以及明確每個目標達成的可衡量的“關鍵結果”。

    • SMART原則將目標一共分為五個維度:

      • Specific(具體的):我們的產品具體要做什么,要怎么做。
      • Measurable(可衡量的):我們的產品會給用戶帶來什么好處,這個好處用什么方式度量。
      • Attainable(可實現的):產品的可實現性,砍掉不切實際。
      • Relevant(相關的):抓住關鍵目標,砍掉產品的無關目標。
      • Time-Based(有時間限制的):有時間限制的就是砍掉無限拖延。前面確立的項目都很好,但是需要實現的時間太長則沒有意義。
  • 用戶需求:怎么讓用戶選擇你的產品。

  • 系統需求:你的產品怎么能更好用一點。

    其中系統需求基於用戶需求、業務需求基於你的功能如何讓用戶離不開你的產品。


詳細解釋:
  • 業務需求:業務需求來自公司、來自老板。業務需求描述的是願景級的需求,主要描述宏觀上產品解決了市場上的哪類人群的痛點和需求,這里會通過描述用戶畫像等完成產品故事的表達,主要站在整個系統(產品)和公司的角度進行分析,表示組織或客戶高層次的目標
  • 用戶需求:用戶需求來自用戶。對用戶群體進行分類,從某一類用戶的視角分析這一類用戶對軟件的需求。描述的是用戶的目標,或用戶要求系統必須能完成的任務
  • 系統需求:系統需求站在了產品的角度,把具體的用戶需求,變成軟件的功能要求。功能需求是基於業務需求和用戶需求進行需求分析的結果。規定開發人員必須在產品中實現的軟件功能,用戶利用這些功能來完成任務,滿足業務需求

  • 第一步:構建系統上下范圍圖(頂層數據流圖、0層數據流圖),確定系統邊界,確定與系統直接交互的外部實體。

  • 第二步:構建第1層數據流圖,確定與系統直接交互的外部的相鄰系統實體,確定業務事件的發生並引起的進出數據流

    • 業務事件存在系統外部,業務事件是可以引起系統內部一系列活動的外部事件(可以是人、物、時間等等)
    • 業務用例存在系統內部,業務用例可以響應一個業務事件的工作。
    • 外部業務事件觸發內部業務用例進行數據交互(進出的數據流),輸入的數據由業務事件提供,輸出的數據由業務用例提供。
  • 第三步:研究每個業務用例,編寫業務用例場景。這里對應用戶需求。

  • 第四步:利益相關者決定要構建的最佳產品。

  • 第五步:基於第三步和第四步的結論,通過產品用例分析、站在系統角度編寫用例場景。

  • 第六步:分析師為產品編寫故事或需求。


系統功能架構圖示例:

  • 對應數據流圖,通常以3層結構為宜。
  • 其中第1層數據流圖(中央監控、病症監控 ...),對應一個個業務用例(功能模塊),這里以3 ~ 7個模塊為宜。


軟件開發結構化建模分析

  • 軟件模型:對軟件系統在各個開發階段本質特性的描述,它要反映軟件系統的形成過程。
    • 領域模型:也叫業務模型,描述軟件所要服務的業務領域的業務狀況和業務關系
    • 需求模型:描述軟件可向用戶提供的外在特性,包括軟件的目標、功能、性能等。
    • 設計模型:軟件中具體模塊的設計方案(GoF23種設計模式),詳細設計、界面和數據庫等。
    • 實現模型:軟件的具體編碼實現,軟件的實現結構。
    • 測試模型:測試軟件的模型描述。
  • 軟件建模方法:
    • 面向功能
    • 面向數據
    • 面向對象
  • 結構化分析的模型
    • 數據模型(ERD圖 Entity Relationship Diagram)
    • 功能模型(DFD數據流圖 Data Flow Diagram)
    • 行為模型:包括交互模型和狀態模型。側重對象之間的交互、狀態和活動。(順序圖、狀態圖、活動圖)

數據流圖

圖片來自:https://www.jianshu.com/p/2bf96cb928b3

業務流程圖


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM