產(chǎn)品需求與設(shè)計過程(1)-用例

0 評論 18944 瀏覽 43 收藏 9 分鐘

  1.前言

看過太多的稱得上“三無”的軟件,就是無需求、無設(shè)計、無注釋。嚴(yán)格的說來,他們的需求和設(shè)計其實還是有的,只是沒有用文檔記錄下來而已,但是注釋確實真的沒有。這些軟件從大到小都有,但是他們都有一個共同的特點,就是“難維護”。前幾天和同事聊天,聽說一個XAML的實現(xiàn)要重寫了,用本地協(xié)議代替,然后再去考慮和XAML兼容。雖然我沒有看過這個項目的代碼,但是我知道這個項目基本也是“三無”。當(dāng)然這個情況也是三無的重大特征之一,就是前腳走人之后,后腳是“看不懂、下不了手”,結(jié)果是還不如重寫來得簡單。從員工角度,當(dāng)然不會有什么不妥,但是從公司和產(chǎn)品的角度,則是屬于“無謂的損失”。

一個對自己有要求的程序員,應(yīng)該保證自己不出產(chǎn)“三無”項目

“規(guī)范化”可以解決項目的“三無”問題。而且這個一直是我所推崇的,正好有網(wǎng)友開始了12306ng項目,所以也就拿這個例子過來,跟大家匯報一下我的設(shè)計思路,同時也作為我在公司開設(shè)此類課程的備課。

  2.關(guān)于設(shè)計

軟件的設(shè)計過程其實也是一個推導(dǎo)的過程,這個過程的每一個步驟之間都有著各種關(guān)系:要么細化,要么印證,要么補充。我之前學(xué)習(xí)設(shè)計的時候,以為看著課本,依據(jù)什么“自頂向下”或“自底向上”就可以一步一步將系統(tǒng)設(shè)計出來,可是后來發(fā)現(xiàn)我錯了。相信正在學(xué)習(xí)設(shè)計的朋友也應(yīng)該會有這樣的感受。

電腦和人腦相比,最大的區(qū)別是前者一個線性系統(tǒng),而后者是一個非線性系統(tǒng)。所謂的非線性,通俗點講,就是顛三倒四,左右開弓,文藝點講,就是講究“螺旋式上升”,總之就是說“機械式”的“一蹴而就”動作,人腦是不擅長的,當(dāng)然,天才除外。

設(shè)計也是如此,它本來就是人腦的處理結(jié)果,所以它的過程也必然是非線性的。一種設(shè)計方法,要想被人容易學(xué)習(xí)和接收,它本身就要是一種包含“螺旋式”改進的機制,也就是戴明環(huán)的PDCA過程(Plan-Do-Check-Adjust),不過在設(shè)計過程中Plan的因素不明顯,主要是DCA的過程。

在做系統(tǒng)設(shè)計的過程中,最大的感受就是不要限制自己。記得當(dāng)年我為了完成設(shè)計,滿足“自頂向下”的要求,刻意地限制自己不去深入地思考,結(jié)果當(dāng)然是失敗。當(dāng)然,“限制”不僅是剛談到的思考層次的限制,更重要的是突破工具的限制。所有的工具都會給思想甚至工作進度帶來限制。迄今為止,最好的設(shè)計工具依然是“帶橡皮頭的鉛筆”和“紙”,所以諸位要好好地利用它。

  3.需求

12306是目前最著名的公認(rèn)的人機交互體驗較差的網(wǎng)站,如何做出一個比它更好的系統(tǒng)呢?答案就是“更仔細地設(shè)計”。在“更仔細地”設(shè)計之前,我們需要“更仔細地”收集好需求。

軟件的需求就是軟件要實現(xiàn)的“目的”。各位千萬不要一提到“需求”就當(dāng)作了“需求文檔”,文檔只是需求的一種表現(xiàn)形式而已,另外一種常見的表現(xiàn)形式就是程序員們大腦中的記憶。蹩腳的程序員經(jīng)常通過嘴傳遞需求,他們寧可不厭其煩、一遍又一遍地說,也不愿意花一點時間一次性寫下來,他們無法忍受客戶的一次次需求變更,但卻不在意自己每次說出的同一個需求都有些走樣。

3.1.第一步:用例分層

這里我們用UML的用例圖(UseCase)來表示需求。

用例圖也是分層次描述的。所有系統(tǒng)最頂層的用例圖(零級用例)都差不多,都是一個圓圈圍繞著很多角色,區(qū)別就是角色有多少,以及圓圈里寫的字不一樣。這次我們的圓圈里寫的是“12306ng火車票訂票系統(tǒng)”,外圍的角色只有2個:用戶和管理員。

一級的用例圖就完全不一樣了。我把它分為了7個部分,一級用例名稱和其包含的二級用例名稱說明如下:

1. 用戶管理:注冊,登錄,退出,密碼找回,信息查看,信息修改,用戶驗證,用戶查詢

2. 查詢:時刻表,余票,聯(lián)程規(guī)劃,晚點

3. 訂單:下單,取消訂單,修改訂單,訂單查詢,預(yù)訂

4. 票務(wù):訂票,取票,改簽,退票,車票查詢

5. 資金:付款,退款,查詢到帳,銀行對賬

6. 票池:入票,出票,查詢票池,修改票池

7. 維護:參數(shù)設(shè)置,詞典維護,拓撲管理,日志查詢,備份,恢復(fù)

以上直接列出是為了方便大家閱讀,實際上我也是用這樣提綱來思考的。然后補圖如下:

2203241T6-1
 

220324L91-2
 

220324GO-3
 

2203242555-44
 

220324OC-51
 

2203243117-6
 

2203244924-7
 

2203245G9-812
 

當(dāng)然,以上的部分既不是最初的狀態(tài),也不是最終的狀態(tài),而是我經(jīng)過多次調(diào)整和改進之后,到現(xiàn)在的狀態(tài),未來還會根據(jù)分析的情況進一步調(diào)整。另外,大家一定要注意,一個系統(tǒng)的用例表示不是唯一的,不同的人給出的用例是不同的,但是理論上應(yīng)該是等價的。

用例圖中的每一個部分,都必須是真實存在的,而且是可以面向客戶的東西,它所描述的最小單位應(yīng)該是業(yè)務(wù)模塊。評判用例的標(biāo)準(zhǔn)是“具有業(yè)務(wù)意義”,所謂的“業(yè)務(wù)意義”就是指這個業(yè)務(wù)模塊完成之后,可以將整個業(yè)務(wù)或者業(yè)務(wù)流程向前推進,這個“推進”的結(jié)果應(yīng)該包含了角色的轉(zhuǎn)變或者目標(biāo)的變化。

從以上的定義來看,“資金.查詢到帳”和“票池.鎖票”可能就不是一個用例。直到寫本文的時候,我依然還在猶豫,但后來還是決定剔除,因為他們沒有外部關(guān)聯(lián)的actor,雖然確實這兩個用例能夠推動業(yè)務(wù)向前推進。從這里我還得到一個經(jīng)驗,就是在一級和二級用例最好不要出現(xiàn)actor是內(nèi)部模塊或系統(tǒng)的情況。

來源:http://www.cnblogs.com/BigTall/archive/2012/10/17/2727012.html

(未完待續(xù))

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!