3 、業務場景法:
a) 考慮用例的調用者;考慮每一個用例提供的服務是供哪些外部用例或者系統調用,找出所有的調用者。調用的前提、約束都要考慮。每一個調用都可以考慮成一個大的業務流程。(一般和外部有交互的用例出錯的概率比較大,需要重點關注)
b) 考慮系統內部各個用例之間的交互,形成內部業務流程圖。需要分析每個用例之間的約束關系、執行條件,組織出各種業務流程圖。
4 、功能分解法
a). 業務功能:與用戶實際業務直接相關的功能 或細節。
b). 輔助功能:輔助完成業務功能的一些功能或者是細節,比如,設置過濾條件。
c). 數據約束:功能的細節,主要是用于控制在執行功能時,數據的顯示范圍、數據之間的關系等。
d). 易用性需求:功能的細節,產品中必須提供了,便于功能操作使用的一些細節,比如快捷鍵就是典型的易用性需求。
e). 編輯約束:功能的細節,在功能執行時,對輸入數據項目的一些約束性條件,比如只能輸入數字。
f). 參數需求:功能的細節,在功能中,需要根據參數設置不同,進行不同處理的細節。
g). 權限需求:功能的細節,這里的權限是指在功能的執行過程,根據根據不同的權限進行不同處理的,不包括直接限制某個功能的權限。
一個有趣的例子
某日,老師在課堂上想考考學生們的智商,就問一個男孩:“樹上有十只鳥,開槍打死一只,還剩幾只?”
男孩反問:“是無聲槍么?”
“不是。”
“槍聲有多大?”
“80~100分貝。”
“那就是說會震的耳朵疼?”
“是。”
“在這個城市里打鳥犯不犯法?”
'不犯。“
“您確定那只鳥真的被打死啦?”
“確定。”老師已經不耐煩了,“拜托,你告訴我還剩幾只就行了,OK?”
“OK。鳥里有沒有聾子?”
“沒有。”
“有沒有關在籠子里的?”
“沒有。”
“邊上還有沒有其他的樹,樹上還有沒有其他鳥?”
“沒有。”
“方圓十里呢?”
“就這么一棵樹!”
“有沒有殘疾或餓的飛不動的鳥?”
“沒有,都身體倍棒。”
“算不算懷孕肚子里的小鳥?”
“都是公的。”
“都不可能懷孕?”
“………,決不可能。”
“打鳥的人眼里有沒有花?保證是十只?”
“沒有花,就十只。”
老師腦門上的汗已經流下來了,下課鈴響起,但男孩仍繼續問:“有沒有傻的不怕死的?”
“都怕死。”
“有沒有因為情侶被打中,自己留下來的?”
“笨蛋,之前不是說都是公的嘛!”
“同志可不可以啊!”
“…………,性取向都很正常!”
“會不會一槍打死兩只?”
“不會。”
“一槍打死三只呢?”
“不會。”
“四只呢?”
“更不會!”
“五只呢?”
“絕對不會!!!”
“那六只總有可能吧?”
“除非你他媽的是豬生的才有可能!”
“…好吧,那么所有的鳥都可以自由活動么?”
“完全可以。”
“它們受到驚嚇起飛時會不會驚慌失措而互相撞上?”
“不會,每只鳥都裝有衛星導航系統,而且可以自動飛行。”
“恩,如果您的回答沒有騙人,”學生滿懷信心的回答,“打死的鳥要是掛在樹上沒掉下來,那么就剩一只,如果掉下來,就一只不剩。”
老師當即倒!
舉例說明如何進行測試需求分析
先看一段關于日志文件的需求描述如下:“軟件要將所有的訪問者都要記錄下來,對每次訪問要記錄訪問開始時間、訪問結束時間、訪問者的IP地址這三個信息作為一條日志記錄。要求以天為單位每天生成一個訪問記錄日志文件。
在這段需求描述中,我們首先要想象自己是日志模塊的開發者,根據這段需求描述,是否能夠開發出日志模塊來呢?日志文件要記錄的信息內容上面都提到了:訪問開始時間、結束時間、IP地址。乍一看好像可以根據這個需求描述進行開發。
但仔細來分析一下這段需求的話,就會發現并不是想象的那樣樂觀。先找出需求中涉及的三個顯性元素:
1、訪問者
2、訪問記錄
3、日志文件
首先對訪問者和訪問記錄這兩個元素進行分析,先看訪問者有那些屬性,除了描述中提及的訪問時間和IP地址外,訪問者還有那些屬性呢?顯然訪問者 的訪問內容是最重要的屬性,僅記錄訪問時間和訪問者的IP地址是否足夠呢,從日志能分析出什么有用的信息呢?從時間信息上最多只能看出那段時間訪問的人數 較多,得到用戶的時間分布規律,但很難對用戶的行為有深入的分析,只有知道訪問者在訪問那些內容才能得到更有價值的信息。象Web服務器軟件要記錄下訪問 的URL信息以便知道訪問者訪問的內容,所以訪問記錄中遺漏了關于訪問內容的信息。
從訪問記錄這個元素來分析,訪問記錄主要屬性是記錄格式,每條記錄是以什么格式來記錄呢?沒有描述出來。有經驗的開發者就知道日志記錄格式是一 個很重要的問題,因為日志記錄的分析一般是需要使用專門的分析軟件或者寫專門的分析程序來分析的。如何設計合理的記錄格式來利用已有的日志分析軟件來進行 分析是首要考慮的問題。
原文轉自:http://www.blogjava.net/qileilove/archive/2013/05/20/399492.html