架構師成長第一步:如何做需求分析(方法經驗總結,純乾貨系列)

雲飛龍行2021發表於2021-09-06

前面兩篇文章:

第一篇:《突破內卷,聊聊軟體架構師成長之路,說人話接地氣!系列文章》

  從架構師日常工作的角度,概要講述了架構師要做什麼,以及需要匹配什麼能力

第二篇:《架構師成長之路純乾貨:什麼是架構和架構分類》

  講述了架構的基本概念和架構分類

  接下來我們就來具體聊聊 每個階段該如何去做,從實戰的角度,講講做的方法,都是多年經驗總結,或許看上去沒有那麼高大上,但絕對實用。

  從幾十萬的小專案到數千萬的大專案,都可以用得上。

  先來聊聊 架構師該如何做需求分析

一:架構師需要做什麼,包含但不限於:

1:理解業務,要準確、全面、深入

  這是需求分析階段最最重要的工作。

  準確的意思就是:對每個功能點的理解,要沒有歧義,不可再分。

  如果一個功能點,不同的人有不同的理解,這就是有歧義;另外這個功能點,裡面還有很多小功能點,是可以再分的,這也是不行的。

  可惜我們們在需求文件裡,看過太多這樣的坑,往往一兩句話,就一筆帶過好大一個功能塊,最後為了填坑,多耗費出上月的人力和時間。

  因此,架構師在做需求分析的時候,對每一個功能點,一定要準確,要求理解到沒有歧義,不可再分,基本要到最細粒度的操作,比如:新增、修改這樣的功能。

2:識別重難點業務

  這個算是架構師的一個基本功,拿到需求後,架構師要能識別出裡面的重難點業務,對它們的分析和設計,可能會影響到後面的技術選型和具體的架構設計。

  畢竟,軟體只是工具,是用來幫助實現業務活動的工具;而架構設計是為軟體服務的,是為了更好的開發和製作軟體這個工具。

  因此,對於重難點業務的把握,可能直接決定了架構設計的成敗,一定要非常重視。

3:識別非功能需求和質量約束

  非功能需求:就是除去業務功能需求之外的需求,通常也是軟體質量約束的一部分,比如對系統:效能的要求、可靠性的要求、可擴充套件性要求、可維護性要求、安全要求、備份恢復的要求等等。

  這些要求對於架構設計的影響是非常大的,很多都是架構設計要重點考慮的問題,比如:效能、可靠性、可擴充套件等等。

4:業務架構

  這個通常是以產品人員設計的業務架構為主,但技術架構師需要在準確、深入理解的基礎之上,按照技術人員能理解的方式,對業務架構進行微調,輸出一個技術落地實現的業務架構。

二:對架構師而言,需求分析非常重要

  需求分析是做架構設計的基石或者是起點,架構師在對需求進行全面、準確、深入理解過後,在這個基礎之上才能去做架構設計。

架構師成長第一步:如何做需求分析(方法經驗總結,純乾貨系列)

  需求分析告訴我們到底要做什麼,連這個問題都沒有解決,談何架構設計。如果要做什麼都不清楚,請問這個架構設計為誰做,做來幹什麼呢?

  現在有一些所謂的架構師,輕業務而重技術,成天高談闊論各種技術,名詞滿天飛,為了技術而技術,卻忘了架構設計的初心,這是很不可取的。

  可以毫不客氣地說,這些人根本算不上是真正的架構師,稱之為“偽架構師”或者“PPT架構師”。

三:如何做需求分析

這裡並不是教科書式的方法,只是多年架構設計實戰經驗的總結,供大家參考,不足之處也請海涵,可以多交流。

一)基本思維方式

  只是考慮:具體要實現什麼、明確具體的展現形式

  不去考慮:究竟如何實現

  通常,架構師都是從開發人員升上來的,有些剛開始做架構的架構師,他的思維方式,還帶著濃厚的開發人員的思維,一看到功能需求,腦袋裡就全是程式碼,自覺不自覺的就在思考該怎麼實現,就差把程式碼寫出來了。

  特別提醒,這個階段是隻考慮要做什麼,而不考慮具體如何做。至於如何做的事情,是接下來的架構設計、詳細設計等階段要考慮的。

架構師成長第一步:如何做需求分析(方法經驗總結,純乾貨系列)

(二)做需求分析的基本方法

1:明確系統邊界

2:視角進入系統,按照大業務功能(子系統、業務模組)的方式,來理解這些系統的業務邊界、業務功能和業務流程

如果把系統想象成是一棟大樓的話,視角就像是鏡頭,由遠及近地推進。

3:採用模擬業務運轉的方式加深對業務的理解

4:採用不斷問問題的方式,進行業務挖掘和深入理解

5:不斷進行功能分解,把複雜的、較大的功能,分解為顆粒度較小的功能,直至不可再分

6:對業務功能點:

(1)逐字逐句地去讀需求說明書,讀出顯示的或者是隱含的功能點

(2)對這些功能點,進行從前臺頁面到後臺功能,逐步進行明確,要到實現需要明確下來的地步

(3)換位思考

7:對業務流程

(1)把流程中的每個節點當做一個具體的功能來思考

(2)每個節點的角色是什麼

(3)每個節點相應的頁面是什麼(頁面流)

(4)節點要操作的資料的來源和去向(資料流)

(5)節點的啟動條件和向後流轉的條件(邏輯流)

8:進一步應用 模擬業務運轉的方式 進行業務走查

9:對於不明確的、模糊的功能

(1)跟需求調研人員或者是產品人員討論、或者再次跟使用者討論

(2)暫時擱置,明確後再做這部分

10:對於非功能性需求,需要儘量明確到指標,並準確理解相關的約束條件

 

以上的方法步驟,是多年實戰經驗的總結,有不明之處,可以多交流。

另外提示一點:對於這些方法,在不同的專案實操中,還會有調整和變化,最好是結合實際工作中的專案,多實踐、多思考、多運用,才能真正理解和掌握。

熟能生巧,最後內化成為你自己的能力,形成你自己的一套方法,你也就成了真正的架構師了!

也歡迎各路架構師朋友一起探討,碰撞和完善這些方法,謝謝大家!

更多架構師之路乾貨文章,已在路上,稍後就到!

架構師成長第一步:如何做需求分析(方法經驗總結,純乾貨系列)

 

相關文章