需求 需求分析能力之二 引入領域模型

2021-04-13 14:45:17 字數 1359 閱讀 4407

2023年07月10日 16:09:00

許多人或許會對我的這種做法提出質疑,不錯,很多的流行書籍都告訴我們,在整理完需求以後,可以提取領域模型。但不管怎麼說,我仍然堅持我自己的做法,原因有n:

書上的知識是教我們思考,不是教我們教條主義的。

說白了,一句話,書可能是對的,也可能是錯的,流行的未必就是對的代名詞。有個笑話曰:"感冒也是流行的。"很多方法,在實際中工作得很好,但是,在理論上,就是行不通。也有很多方法,在理論上是可行的,不過,放到現實中,就是行不通。

人的思維過程,不是乙個線性的過程。有時候,我們就是先想到乙個簡單的領域模型,而這個領域模型,就可能是我們開發過程中最重要的突破。我們沒有必要去強調先後:"這樣是不行的,你必須先整理出需求文件,然後我再提煉領域模型。",那麼,當遇到工期緊張而要需要你仿製乙個已有系統的時候,你不用這種需求逆工程,還能用什麼辦法?

領域模型是和需求同時存在的,也如同需求一樣,散落在許多人的頭腦中,但需求文件在書寫的過程中,極容易讓人陷於細節,而領域模型,比較適合抓大放小。

在需求分析過程中,我們已經在不自覺的使用領域模型了。例如,我們在描述乙個需求文件時,會說到"actor開啟乙個訂單,系統顯示其所有可編輯的訂單行",這裡面就隱含了"訂單","訂單行"和它們之間的關聯關係,這是在我們寫需求之間就已經在腦子裡形成的簡單模型。有了這個模型,可以在描寫需求的時候,將領域模型元素做為通用的詞彙表,這樣就不會出現前面寫"訂單",後面寫"銷售訂單"的現象了。

在實際的應用過程中,這種方法是有效的。我個人的理解,我們在需求分析做了如此多的工作,對於設計和實現人員來講,主要就是為了傳遞乙個統一的領域模型。(當然,對測試人員和介面設計、文件編寫人員來講也是如此,不過除了這個領域模型外,還要傳遞其他的東西)。也就是說,如果乙個需求分析人員,在提交需求文件的同時,把自己書寫文件時,腦中形成的領域模型一起提交,會取得事半功倍的效果。

閒話不多說,讓我們切入正題:

領域模型,當然不隻類,關聯和圖這麼簡單,但這確實也是構成領域模型的最基本元素。同時,也要注意,領域模型是系統的抽象,而不是全部,我們要在此刻建立的領域模型,只是屬於架構檢視的那部分。這也就是28原則中的那20%。

將系統中有價值的類,關聯等提取出來,只是完成了領域建模的50%,剩下的50%,就是基於需求,對領域模型構造塊的重新歸類、和組織。

常採用的做法有:

在專案交流和需求調研過程中,你可以根據領域模型,特化出乙個物件圖,這樣非常有助於跟業務專家的交流,並且極容易在領域模型中發現矛盾甚至錯誤的需求。

需求 需求分析能力之二 引入領域模型

2006年07月10日 16 09 00 許多人或許會對我的這種做法提出質疑,不錯,很多的流行書籍都告訴我們,在整理完需求以後,可以提取領域模型。但不管怎麼說,我仍然堅持我自己的做法,原因有n 書上的知識是教我們思考,不是教我們教條主義的。說白了,一句話,書可能是對的,也可能是錯的,流行的未必就是對...

需求 需求分析能力之二 引入領域模型

2006年07月10日 16 09 00 許多人或許會對我的這種做法提出質疑,不錯,很多的流行書籍都告訴我們,在整理完需求以後,可以提取領域模型。但不管怎麼說,我仍然堅持我自己的做法,原因有n 書上的知識是教我們思考,不是教我們教條主義的。說白了,一句話,書可能是對的,也可能是錯的,流行的未必就是對...

怎樣做需求分析(之二)

撥開需求分析的迷霧 像這樣的對話經常出現在軟體開發的過程中。客戶 專案經理的需求對分析人員來講,像 霧裡看 花 般模糊並令開發者感到困惑。那麼,我們就撥開霧影,分析一下需求的具體內容 業務需求 反映了組織機構或客戶對系統 產品高層次的目標要求,通常在專案定義與範圍文件中予以說明。使用者需求 描述了使...