第一篇：論軟件需求分析方法和工具的選用

論軟件需求分析方法和工具的選用

【摘要】

本文討論《企業人事信息系統》項目的需求分析方法與工具的選用。該系統的建設目標是幫助該企業管理好企業內部的人員和人員的活動，人事信息管理指的是企業員工從招聘面試到離職退休的全過程，涉及的主要活動包括面試、報到、培訓、升職、離職或其他的人事變動，也包括電子化考勤、工資性收入的計算與分發、使用其他公司資源的有關記錄（如宿舍、保險、證件辦理等等）。此外，本系統也涉 及到企業在全國各地的人事信息管理，企業的組織架構的設置，級別與職務管理，人力申請直至人力需求報表，從而形成一個對企業真正有用的人事信息管理應用系統。在本文中首先討論了選用面向對象方法與工具的主要理由與策略，進一步通過一個簡例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需求分析中的必要性，最后簡要小結了選用正確工具與方法的意義和作用。

在項目開展期間，我擔任了系統分析、系統設計與數據庫管理等大量工作。

【正文】

人事信息管理系統是一個有著廣泛應用面的實用性系統，但是，我國各個企業有著自身的體制、機制、特點與不同的要求；在開發這類系統時，系統需求分析是極為重要的一環。在整個分析過程中，我們都采用了面向對象的分析方法，這是因為我們在近幾年的實踐中已堅信這種方法能夠更加有效地表達和描述現實世界。軟件要具有適用性和擴展性，就必須更接近于現實世界本身的發展規律。

以一個簡單的例子來看，假設要求設計關于引進人才評估的一個系統，按我們過去的做法，先會要求提供給我們一份相關的引進人才評估表，然后依葫蘆畫瓢地設計相應的表單與界面。在短期來說，這樣做是簡便而實用的，但并不能夠符合現實世界的長遠目標，這套設計方法不具有擴展性，因為任何一份評估表的結構都會有可能發生許多改變的。采用面向對象的方法，可以從中提取出表類型、表結構、評分方法以及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護性。

在工具的選擇過程中，我們選擇了現在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，為什么選取這個系列工具呢？這是基于我們對軟件需求分析目標的看法，我們認為需求分析應當能正確地回答如下的幾個關鍵性問題：

（1）用戶的需求是否已詳盡地被考慮到了？

（2）用戶能理解或明白我們所描述的內容嗎？

（3）分析是否會和設計相脫節，（4）程序員能明白我們的分析與設計要求嗎？等等。

以下對上述幾個問題逐一簡要地加以說明：

（1）詳盡地獲取用戶的需求。

用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當前的與明顯的需求。要達到對需求理解的全面性，不僅僅只是依靠有效的用戶談話和調查，因為我們所面對的用戶需求往往會有些片面的，采用Rational Rose（基于UML）提供的用例，以及多種圖的聯合使用，可以使我們發現其中的遺漏。

（2）使用戶能充分地理解我們的表示方法，能夠真正明白我們描述的內容。

軟件需求分析規格說明書通常會是冗長而枯燥的，一般的用戶不容易深入理解，這樣就削弱了分析的正確性。通過支持面向對象及UML語言的Rational Rose可以更好地和用戶交流，讓用戶了解系統的運作方式甚至細節的操作。

（3）使分析和設計兩個階段互相聯系與貫通。

這是我們選擇面向對象的方法及Rational Rose工具的重要原因，系統分析要向用戶描述的不僅僅是用戶的需求，而且包括解決方法，解決方法當然應包括設計（程序）、數據庫與系統配置，我們當然不希望用戶得到的是一個與需求規格說明不相同的軟件，也不可能要求程序員完成一個不可勝任的任務。然而我們在以前的多項工作中經常發現這類情節，因為系統分析與設計相互脫節，導致一頭扎在分析中不顧設計有關的事宜。

分析與設計的脫節，還不利于設計現格說明的評估，因為分析往往會脫離現實，導致缺乏評估的依據。

因為不可能成功地完成設計而使分析需要重來，就會造成巨大的浪費與損失。一個好的工具可以使分析與設計更緊密地連結起來，甚至于—一對應。面向對象的分析方法使對象之間相對而言有獨立性，減少了任何影響到全局的改動，能避免因需求變化而導致全盤皆動的被動局面。

（4）使程序員明白我們的設計。

一個好的設計應該讓程序員感到清晰明白，更少疑問。一個疑問很多的設計加上溝通不暢，絕對會出現在應用環境下所不需要的另一個軟件，所以設計規格說明書務必清楚、形象與明確，當然，Rational Rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細微到每一個語句（事實上如果使用VB，程序架構都有可能直接生成了）。

（5）選擇UML可能會有更多的理由。

比如用戶文檔的編寫、數據庫設計，我們都需要做到有延續性，有自動化支持和具有質量上的保證。

所以，我們選用了以上的方法和工具。

在分析中，面對考勤班次的問題時，由于過去一直使用紙卡方式考勤，使用戶對班次形成了固定的概念，而現在的許多考勤軟件也采用多次刷卡的方法來形成一天的記錄。經過面向對象的分析可以發現，事實上每天的上班記錄是由多個時段所形成的，時段的多少在各個公司，各個工種與部門都不盡相同，每個時段可能有不同的屬性，時段與時段組合可形成為班次，這更適合于現實的情況，使之能更加靈活與更有擴展性。其實，在天與天之間也都有相互之間的關系。在這一點上，我們又發現必須在考勤與薪金工資中加入與MRP中相似的期段（Periods）的基本概念，比如可以稱之為考勤期段，允許為用戶更加方便地設置考勤期段，可能使之不一定與自然年月日相同等等。

Rational Rose使我們更方便地把上面的想法在類上去實現，更進一步地設計好我們的高效率的數據庫。

當然，使用單一的一個工具去完成一個中大型的應用系統的需求分析，是不可能成功的。因為社會在發展，用戶的需求也在改變，如何把握住用戶的需求是需要時間的，面向對象的方法有時也會忽略外在的與表層的要求，不僅僅是要獲得關鍵的需求，其他更多的需求往往要等到用戶在使用后才知道，然而等到用戶使用是不現實的，作為原型開發模型中的原型也是收集用戶需求，描述與解釋需求的一類相當有效的方法與工具。

在我們的開發過程中，為了更好地讓用戶了解我們的系統和我們的設計方案，讓用戶在見面會上更有方向性與針對性，我們首先用Access開發出原型，讓用戶先試用。這樣，我們在真正的分析與設計時就能更加符合用戶的要求。

總之，軟件需求分析方法和工具的使用，對我們軟件開發過程影響是很深遠的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現實需求，更加具有可用性、可擴展性和可維護性；降低了軟件項目的風險。

評注：（1）寫得有些特色，觀點鮮明。（2）摘要寫得不錯，既反映了項目內容，也小結了本文的寫作要點。（3）文中所舉的例子雖然簡單，但很實際。（4）多種方法與工具的使用，敘述得簡明扼要。（5）內容可更豐富一些，更深入的例子也可再增多一些，則會更有說服力。

（6）對需求分析的全過程的描述太少。

第二篇：6.培訓需求方法和工具

進行培訓需求信息的收集和整理方法和工具

培訓需求信息的收集與整理：組織分析、工作分析、個人分析。包括：動態的需求、靜態的需求

(1)、動態需求，因每個人的能力而異，需求各異；（人崗匹配為終點）(2)、靜態需求，是組織和崗位要求，對個人能力的要求的標準。（人崗匹配為終點）

培訓需求信息可以通過檔案資料來收集

主要來源渠道有：

（1）來自于領導層的主要信息；

（2）來自于積壓部門的主要信息；

（3）來自于外部的主要信息；

（4）來自于組織內部個人的主要信息。

主要方法有：

（一）面談法（又叫訪談法）：是一種非常有效的信息收集方法，培訓者與培訓對象之間面對面進行

交流，充分了解相關信息

（二）小組討論法（含重點團隊分析法）：指在培訓對象中選出一批熟悉問題的員工作為代表參加討論，以調查培訓需求信息

（三）資料分析法（含工作任務分析法）：以工作說明書、工作規范、工作任務分析記錄表作為確定員

工達到要求必須掌握的知識、技能和態度的依據，將其和員工平時工作中的表現進行對比，判定員工要完成工作任務的差距所在。

（四）行為觀察法：指培訓者親自到員工身邊了解員工的具體情況，通過與員工在一起工作，觀察員

工的工作技能、工作態度、了解其在工作中遇到的困難，搜集培訓需求信息的方法。

（五）問卷調查法：

培訓需求信息的工具：（1）培訓需求概況信息調查工具；（2）態度、知識和技能需求信息調查工具；（3）課程選擇式調查工具；（4）外部培訓機構或培訓經銷商、服務商調查工具。

二、簡述需求分析的基本工作程序。

（一）做好培訓前期的準備工作；

1、建立員工背景檔案；

2、同各部門人員保持密切聯系；

3、向主

管領導反映情況；

4、準備培訓需求調查。

（二）制定培訓需求調查計劃；

1、培訓需求調查工作的行動計劃；

2、確定培訓需求調查工作的目

標；

3、選擇合適的培訓需求調查方法；

4、確定培訓需求調查的內容。

（三）實施培訓需求調查工作；

1、提出培訓需求動議和愿望；

2、調查、申報、匯總需求動議；

3、分析培訓需求；

4、匯總培訓需求意見，確認培訓需求。

（四）分析與輸出培訓需求結果；

1、對培訓需求調查信息進行歸類、整理；

2、對培訓需求進行分

析、總結；

3、撰寫培訓需求分析報告。

（六）測試法：

（七）自我分析法：

第三篇：數據分析軟件和工具

以下是我在近三年做各類計量和統計分析過程中感受最深的東西，或能對大家有所幫助。當然，它不是ABC的教程，也不是細致的數據分析方法介紹，它只 是“總結”和“體會”。由于我所學所做均甚雜，我也不是學統計、數學出身的，故本文沒有主線，只有碎片，且文中內容僅為個人觀點，許多論斷沒有數學證明，望統計、計量大牛輕拍。

于我個人而言，所用的數據分析軟件包括EXCEL、SPSS、STATA、EVIEWS。在分析前期可以使用EXCEL進行數據清洗、數據結構調 整、復雜的新變量計算（包括邏輯計算）；在后期呈現美觀的圖表時，它的制圖制表功能更是無可取代的利器；但需要說明的是，EXCEL畢竟只是辦公軟件，它 的作用大多局限在對數據本身進行的操作，而非復雜的統計和計量分析，而且，當樣本量達到“萬”以上級別時，EXCEL的運行速度有時會讓人抓狂。

SPSS是擅長于處理截面數據的傻瓜統計軟件。首先，它是專業的統計軟件，對“萬”甚至“十萬”樣本量級別的數據集都能應付自如；其次，它是統計軟 件而非專業的計量軟件，因此它的強項在于數據清洗、描述統計、假設檢驗（T、F、卡方、方差齊性、正態性、信效度等檢驗）、多元統計分析（因子、聚類、判 別、偏相關等）和一些常用的計量分析（初、中級計量教科書里提到的計量分析基本都能實現），對于復雜的、前沿的計量分析無能為力；第三，SPSS主要用于 分析截面數據，在時序和面板數據處理方面功能了了；最后，SPSS兼容菜單化和編程化操作，是名副其實的傻瓜軟件。

STATA與EVIEWS都是我偏好的計量軟件。前者完全編程化操作，后者兼容菜單化和編程化操作；雖然兩款軟件都能做簡單的描述統計，但是較之 SPSS差了許多；STATA與EVIEWS都是計量軟件，高級的計量分析能夠在這兩個軟件里得到實現；STATA的擴展性較好，我們可以上網找自己需要 的命令文件（.ado文件），不斷擴展其應用，但EVIEWS就只能等著軟件升級了；另外，對于時序數據的處理，EVIEWS較強。

綜上，各款軟件有自己的強項和弱項，用什么軟件取決于數據本身的屬性及分析方法。EXCEL適用于處理小樣本數據，SPSS、STATA、EVIEWS可以處理較大的樣本；EXCEL、SPSS適合做數據清洗、新變量計算等分析前準備性工作，而STATA、EVIEWS在這方面 較差；制圖制表用EXCEL；對截面數據進行統計分析用SPSS，簡單的計量分析SPSS、STATA、EVIEWS可以實現，高級的計量分析用 STATA、EVIEWS，時序分析用EVIEWS。關于因果性

做統計或計量，我認為最難也最頭疼的就是進行因果性判斷。假如你有A、B兩個變量的數據，你怎么知道哪個變量是因（自變量），哪個變量是果（因變量）？

早期，人們通過觀察原因和結果之間的表面聯系進行因果推論，比如恒常會合、時間順序。但是，人們漸漸認識到多次的共同出現和共同缺失可能是因果關 系，也可能是由共同的原因或其他因素造成的。從歸納法的角度來說，如果在有A的情形下出現B，沒有A的情形下就沒有B，那么A很可能是B的原因，但也可能 是其他未能預料到的因素在起作用，所以，在進行因果判斷時應對大量的事例進行比較，以便提高判斷的可靠性。

有兩種解決因果問題的方案：統計的解決方案和科學的解決方案。統計的解決方案主要指運用統計和計量回歸的方法對微觀數據進行分析，比較受干預樣本與 未接受干預樣本在效果指標（因變量）上的差異。需要強調的是，利用截面數據進行統計分析，不論是進行均值比較、頻數分析，還是方差分析、相關分析，其結果 只是干預與影響效果之間因果關系成立的必要條件而非充分條件。類似的，利用截面數據進行計量回歸，所能得到的最多也只是變量間的數量關系；計量模型中哪個 變量為因變量哪個變量為自變量，完全出于分析者根據其他考慮進行的預設，與計量分析結果沒有關系。總之，回歸并不意味著因果關系的成立，因果關系的判定或 推斷必須依據經過實踐檢驗的相關理論。雖然利用截面數據進行因果判斷顯得勉強，但如果研究者掌握了時間序列數據，因果判斷仍有可為，其中最經典的方法就是 進行“格蘭杰因果關系檢驗”。但格蘭杰因果關系檢驗的結論也只是統計意義上的因果性，而不一定是真正的因果關系，況且格蘭杰因果關系檢驗對數據的要求較高（多期時序數據），因此該方法對截面數據無能為力。綜上所述，統計、計量分析的結果可以作為真正的因果關系的一種支持，但不能作為肯定或否定因果關系的最 終根據。科學的解決方案主要指實驗法，包括隨機分組實驗和準實驗。以實驗的方法對干預的效果進行評估，可以對除干預外的其他影響因素加以控制，從而將干預實施后的效果歸因為干預本身，這就解決了因果性的確認問題。關于實驗

在隨機實驗中，樣本被隨機分成兩組，一組經歷處理條件（進入干預組），另一組接受控制條件（進入對照組），然后比較兩組樣本的效果指標均值是否有差 異。隨機分組使得兩組樣本“同質”，即“分組”、“干預”與樣本的所有自身屬性相互獨立，從而可以通過干預結束時兩個群體在效果指標上的差異來考察實驗處 理的凈效應。隨機實驗設計方法能夠在最大程度上保證干預組與對照組的相似性，得出的研究結論更具可靠性，更具說服力。但是這種方法也是備受爭議的，一是因 為它實施難度較大、成本較高；二是因為在干預的影響評估中，接受干預與否通常并不是隨機發生的；第三，在社會科學研究領域，完全隨機分配實驗對象的做法會 涉及到研究倫理和道德問題。鑒于上述原因，利用非隨機數據進行的準實驗設計是一個可供選擇的替代方法。準實驗與隨機實驗區分的標準是前者沒有隨機分配樣本。

通過準實驗對干預的影響效果進行評估，由于樣本接受干預與否并不是隨機發生的，而是人為選擇的，因此對于非隨機數據，不能簡單的認為效果指標的差異 來源于干預。在剔除干預因素后，干預組和對照組的本身還可能存在著一些影響效果指標的因素，這些因素對效果指標的作用有可能同干預對效果指標的作用相混淆。為了解決這個問題，可以運用統計或計量的方法對除干預因素外的其他可能的影響因素進行控制，或運用匹配的方法調整樣本屬性的不平衡性——在對照組中尋 找一個除了干預因素不同之外，其他因素與干預組樣本相同的對照樣本與之配對——這可以保證這些影響因素和分組安排獨立。

隨機實驗需要至少兩期的面板數據，并且要求樣本在干預組和對照組隨機分布，分析方法就是DID（倍差法，或曰雙重差分法）；準實驗分析用截面數據就 能做，不要求樣本在干預組和對照組隨機分布，分析方法包括DID（需兩期的面板數據）、PSM（傾向性得分匹配法，需一期的截面數據）和PSM-DID（需兩期的面板數據）。從準確度角度來說，隨機實驗的準確度高于準實驗和非實驗分析。

關于分析工具的選擇

如果根據理論或邏輯已經預設了變量間的因果關系，那么就無需使用實驗方法。我對非實驗數據分析工具的選擇原則如下。

? ? ? ? ? ? ? ? 因變量為連續變量，自變量至少有一個連續變量，進行多元線性回歸； 因變量為連續變量，自變量全部為分類變量，進行方差分析；

因變量為分類變量，自變量至少有一個連續變量，使用Logit模型或Probit模型； 因變量為分類變量，自變量全部為分類變量，進行交叉表分析和卡方檢驗；

因變量在某個閉區間內分布，并且有較多樣本落在閉區間的邊界上，使用Tobit模型；

因變量不唯一，如多產出問題，進行數據包絡分析（DEA）；

因變量為整數、數值小、取零個數較多，使用計數（Count）模型； 數據具有層次結構（嵌套結構），使用多層線性模型（HLM）。

隨著統計和計量經濟學的發展，各種前沿分析工具層出不窮，但我認為最靠譜的分析工具不外乎以下四種：DID（針對隨機實驗），多元線性回歸，固定效 應變截距模型（FE，針對面板數據），Logit模型或Probit模型（針對分類因變量數據）。其他方法或適用條件苛刻，或分析過程折騰，或方法本身不 可靠（尤其是聚類分析、判別分析，超級不靠譜），因此能用以上四種方法分析問題時，不必為“炫方法”而瞎折騰。關于擬合優度、變量選擇原則及估計值絕對大小的意義

在人人的“數據分析”小站中，某同學提出這樣一個問題：“多元回歸分析中，怎么選擇自變量和因變量，可以使R方達到80%以上？”

很顯然，問這個問題的同學要么沒學好計量，要么就是犯了功利主義的錯誤，或者二者皆有。擬合優度的大小很大程度上取決于數據本身的性質。如果數據是 時序數據，只要拿有點相關關系的變量進行回歸就能使擬合優度達到80%以上，但這樣的高R方根本說明不了什么，很可能使分析者陷入偽回歸的陷阱，嚴謹的做 法當然是做平穩性檢驗和協整檢驗；如果是截面數據，根本沒必要追求R方到80%的程度，一般來說，有個20%、30%就非常大了。

如果一定要增大R方，那么最應該做的的確是對納入模型的變量進行選擇。選擇納入模型的原則我認為有三條。第一，從理論和邏輯出發，將可能影響因變量 的變量作為自變量納入模型，即理論上或邏輯上能影響因變量的自變量必須納入模型，即使該自變量的回歸系數不顯著。第二，奧姆剃刀原則——如無必要，勿增實體，即理論上或邏輯上不能影響因變量的自變量不能納入模型，即使該自變量的回歸系數顯著。第三，防止納入具有多重共線性的自變量。

前面說了，對截面數據進行計量分析，R方能達到20%、30%是非常了不起的事情。但是，如果擬合優度（或類似擬合優度的指標）在20%、30%或 更低時，回歸系數只具有定性或定序上的意義，強調其絕對數值的大小沒什么意義。譬如lnY=alnA+blnB+?+zlnZ+c回歸的R方為20%，a 為0.375，b為0.224，且二者的T檢驗顯著，那么我們可以說，A、B對Y有影響，也可以說一百分點的A變化對Y的影響大于一百分點的B變化對Y的影響（控制其他因素的情況下），但說一百分點的A變化對Y的影響較一百分點的B變化對Y的影響大0.151%，就沒什么意義了。

第四篇：軟件測試需求分析與定義方法

軟件測試需求分析與定義方法

如何確定測試工作的范圍？

對于一個存在生命周期的軟件產品來說，它的開發和測試往往都不是一次性的，因為隨著新的需求的出現，以及對原有版本的改進，新的版本會不斷的發布（即使對于一些以客戶定制方式運作的項目，在開發過程中以及發布后的維護期內，也會產生眾多的內部版本）。隨著版本的迭代，我們的測試工作也會一直繼續下去。而在每一次迭代時，可能在整個工作階段的開始就受到一些因素的影響，比如市場需求、既定的發布時間、并發的工作導致的資源緊張等等，使我們不得不考慮對軟件質量要求的適度，最終使得我們在每個階段的測試工作的要求或者說所涉及到的內容有可能是不同的。這種變化，最終將會影響到測試需求的確定。那么到底該如何確定每次迭代是測試工作的范圍呢？在筆者的實踐中，通常把測試工作范圍的確定，等價的認為是軟件需求的確定。

不過現在有一個很實際的問題是這樣：軟件需求在開發過程中不斷發生變化，有時候到了后期還會有新的需求添加進來，還有些需求在交付內部測試版本之后又發現原來的需求本身就存在缺陷，之后再次返工，在軟件最終發布之前，怎么可能確定的下來呢。啊，這些都是讓我們的開發人員和測試人員極其頭痛的事情。到底應該怎樣在頻繁變更的需求中確定哪些部分是我們在某個階段要測試的內容呢？或者說通過什么樣的方法可以改善我們上面提到的那些問題呢？一個實際的做法就是實現軟件需求的版本化控制。（用軟件需求的版本化控制來解決軟件需求的頻繁變更）既然說到了這里，就不免要說些題外話。筆者一直都認為軟件需求是開發工作和測試工作在制定計劃、開展工作時所共同參照的源頭和依據，而我們只有在源頭上控制好，才能保證下面工作的平穩開展。如果希望某個階段工作的進度和內容可以明確的定義下來，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個軟件產品的生命周期中，當要進行一個新版本的迭代時，要盡早的確定這個版本中將要實現的需求，并同上個版本做出比較，哪些內容是新增的，哪些內容是被調整過的。在該階段工作開始之初的工作會議上，明確的向所有需要了解軟件需求的涉眾傳達這部分信息。而如果在該版本的開發過程中不斷的出現需求變更的情況，則應該根據市場策略、已公布的發布時間、客戶需求、實現的代價、難易程度以及對現有工作的影響等方面，對需求進行適度劃分，嚴格定義當前版本中需要實現的需求，而其他部分，則作為未來版本的軟件需求進行考慮。如果有的朋友認為上面的內容還是太理論化，需要一個更實際的、可操作的方法。那么只能說，對于需求的變更，以及因為需求變更而引起的設計的變更，必須要早發現，早討論，早決定，早調整。這可能更多的要依靠一個團隊中相關負責人員的主動工作來保證，而不是依靠一個明確的方法。注意，這里的一個關鍵是，對于軟件需求，同樣需要嚴格按照版本進行管理，或者說使用“基線”進行管理。如何整理測試需求？一旦當前階段測試工作的范圍確定下來，我們就可以開始考慮測試需求的整理——也就是明確的定義現階段要“測什么”。測試需求的確定將為我們制定進度時間表、分配資源以及如何確定某個階段測試工作是否完成提供一個可供衡量的標準。當然，還有更重要的一點，已被確定的測試需求是我們進行測試用例設計和考慮測試覆蓋的依據。整理測試需求的第一步，就是要“測試需求”。測試需求？對，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞，指的是對軟件需求本身的檢查。

啊？這不是已經超出了測試工作的范圍了嗎？測試人員不是應該只關心軟件的實現同需求是否相符嗎？這樣對測試人員要求未免太高了。——這是筆者過去同一些朋友談到測試人員必須對需求進行檢查時聽到的一些不同的聲音。在這里，首先要明確一個問題，就是軟件測試的工作到底做什么？

在《軟件測試》（Ron Patton〔美〕，中文版由機械工業出版社出版，這本書是測試新手入門的經典教材）一書的第10頁，有一個明確而簡潔的定義：軟件測試員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復。

瞧！這里說要“盡可能早”的“找到軟件缺陷”。那這“盡可能早”要早到什么時候呢？

不知道大家對《軟件工程》這本書還有什么印象。至少在筆者看過的多個不同版本的軟件工程方面的書中，對于軟件缺陷都會有一段類似的描述：缺陷發現的越早，則修復這個缺陷的代價就越小，在需求、設計、編碼、測試、發布等不同的階段，發現缺陷后修復的代價都會比在前一個階段修復的代價提高10倍（參見下圖）。這樣看來，上面問題的答案自然就變成了“禿子頭上的虱子”：從需求階段開始！從“測試需求”開始！

注意，筆者這里的觀點并不是說可以取消團隊中的“需求評審會議”，這里并不存在沖突。筆者所希望講述的，是測試人員應該如何看待軟件需求，而并不是把“需求評審會議”所承擔的責任攬到自己身上。?在論壇上也偶爾看到有的朋友問：如何測試需求呢？每次看到這樣的提問，筆者內心就禁不住的一陣激動，因為一直以來，討論這方面問題的朋友的確少之又少。

在筆者的實際工作中，對軟件需求的檢查包括兩個方面的內容。

一是對軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內容是真實可靠的。在進行這部分工作時，不要迷信所謂的“都是用戶提出的真實的需求”，因為我們必須考慮，提出這些需求的涉眾，是否真的可以正確的描述自己的需求？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認為在業務處理上是理所當然、極其平常的事情，而沒有作為需求提出來？有沒有一些被用戶認為他們過去使用的軟件已經提供了相應的功能，所以認為我們也應當提供，而沒有提出來的？關于這個問題，也曾經有朋友提過不同的看法，認為這樣對測試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業的業務。但筆者還是固執的認為，作為測試人員，還是需要對軟件產品所涉及的行業的業務有一個全面的、深入的了解——當然，這不是對一個剛剛入門的測試者的要求，但是如果想稱為一個優秀的測試者，是難免要付出這部分努力的。

二是要保證軟件需求的可測試性。對于“可測試性”，筆者的概念是：對于一條軟件需求或者一個需要實現的特性，必須存在一個可以明確預知的結果，并且可以通過設計一個可以重復的過程來對這個明確的結果進行驗證。說的具體一點，就是要保證所有的需要實現的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述。如果對于某條需求或某個特性，無法通過一個明確的方法來進行驗證，或者無法預知它的結果，那么就意味著這條需求的描述存在缺陷，應該請需求人員對需求文檔進行修改或補充——我們有理由相信，如果作為測試人員對需求無法產生準確的理解，那么開發人員也同樣無法對同一條需求產生準確的理解。對于一條確定的軟件需求理解的二義性，是在不規范的開發過程中導致返工的一個主要原因。如果認為有必要，那應該在“需求評審會議”上確認所有涉眾對需求的理解是一致的。當然，對于如何提高軟件需求的質量，在網絡上或者已經出版的書刊中都已經有了很多更加具體、實用的方法，如果有興趣，大家也可以找來參考。不過，如果您是一位測試者，那么上面這部分內容對您仍然是非常有用的。相信您只要在工作中進行嘗試，慢慢的體會，一定會發現這種方法給您帶來的好處。?現在當前的測試工作范圍已經確定，相應版本的軟件需求也通過了評審，我們就可以在這個已經確定的范圍內進行測試需求的整理。我們手頭上可以參考的東西，通常會有軟件需求規約（以下簡稱SRS）和用例（以下簡稱UC）——當然，也可能是一份包含UC的SRS。通過對SRS和UC的閱讀，我們可以從文檔對特性和業務流程的描述中獲得對軟件所涉及的業務的一個基本的認識。比如用戶在處理實際業務時都要作些什么，多個業務之間的先后順序是怎樣的，用戶在處理業務是對于哪些地方有特別的要求，等等。這部分規則，將成為我們的測試需求中最基本的一部分。

至于測試需求的表現形式，筆者認為大家都可以根據自己的需要進行設計，而沒有必要把思路限制在到底使用表格方式還是使用文本方式，只要把握一個原則就行了：在一條測試需求中，用容易理解的自然語言，明確的描述一項需要測試的內容。對于多項測試內容，應盡可能的剝離開來，保證一條測試需求只包含一項測試內容。

另外，大家也可能注意到了，在軟件開發過程的這個階段，通常是沒有用戶界面（以下簡稱UI）可供參考的——雖然RUP中對于需求階段的工作描述包括了UI設計的部分，但很多時候在這個階段還是無法提供一個確定的UI的——也就是說我們這時獲得的測試需求，將是完全基于業務的，而并不包括基于UI的那部分規則，是同軟件的最終具體實現相獨立的。

隨著開發工作的繼續，開發部門的架構設計文檔和詳細設計文檔也將陸續提交，這時候，我們可以根據設計文檔來對已有的測試需求進行增補。注意，這里我們對于設計文檔中提到的內容要有選擇的采用，只有同SRS或UC中已經定義的部分相符的內容，才可以用來調整我們的測試需求。而同軟件需求不相符的部分，則需要同設計人員和需求人員一起討論，確定下以哪一方作為基準，決定是否需要調整軟件需求，然后對測試需求進行相應的增補或者調整。比如對于一些算法，需要考慮設計文檔中定義的，同系統實現相關的那些計算公式，是否同軟件需求中描述的算法表達的是否是同一個意思？而對于一些約束或者業務規則，設計文檔中描述的是否同需求中的相應部分一致？呵呵，看完上面這部分內容，恐怕又有一部分朋友暈倒在地了，而沒有暈倒的那部分朋友也要提出異議：啊？！你這不是又包含了對開發人員所作的設計工作的檢查嗎？！剛剛讓我們檢查需求，現在又讓我們檢查設計，真的把我們當成全才了！沒辦法，為了讓軟件交到我們手上的時候只包含盡量少的缺陷，大家只能再辛苦一下了。我們的工作不應當僅僅限制在軟件交付后盡力找到存在的缺陷，而更應該努力及早發現軟件缺陷出現的苗頭，盡量預防缺陷的出現。雖然并不是說在所有的團隊中都應該由測試人員承擔“測試需求”和“測試設計”的工作，但是測試人員對這些工作起到的作用，是其他團隊中的其他角色所無法替代的。開發部門完成編碼實現工作，提交供內部測試的應用程序時，測試人員手頭上應該已經準備好了絕大部分測試用例和測試數據，測試部門將開始執行測試。通常在我們執行測試的過程中，即使我們已經從“通過測試”和“失敗測試”兩個不同的角度準備了非常充分的測試用例和測試數據，但總是有些缺陷的出現是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那么，對于這部分缺陷，也應當添加到測試需求中，并設計相應的測試用例，以便于下次版本迭代時進行參考。OK，相信說到這里，各位看客也應該可以理解我的觀點了：對于一個長期發展的團隊或者持續開發的產品，它的所有東西都是要不斷積累的、不斷迭代的。無論對于軟件需求還是測試需求，不僅僅是在一個版本的開發過程中，在不同的階段進行迭代，在產品的整個生命周期中的不同版本間，也是不斷迭代和積累的。

第五篇：軟件需求-案例分析

1、問題描述

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統所涉及的用戶

本系統的用戶包含患者、醫生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。

對于患者來說，他們在年齡、計算機使用能力等方面存在較大差異，但面對的情景都一樣，就是要預約掛號，掛號成功過后就診。

對于醫生來說，普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。所面對的情景有查看掛號信息，確定要就診的病人。

對于管理員來說，他們負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。

不同的用戶，對系統的要求也不相同。患者希望通過完成注冊和登錄后能夠進行掛號預約，查詢醫生的出診信息和個人預約信息，并且能夠在規定的時間內完成掛號預約或者取消已有的預約；醫生則希望能夠在登錄系統后可以查看病人的預約情況；而管理員希望可以修改出診信息和調整預約掛號。這些都是功能性的需求。

同時對于所有用戶都希望該系統是易用的，而且能夠對自己的信息起到保護即系統安全性的要求，還有比如說系統的性能比較高效，能夠及時處理自己的預約申請。當然開發系統的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標和關鍵成功因素

預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。關鍵成功因素，要保證系統能夠24小時正常穩定的運行，系統里的信息要是實時變化的，即可以預約的醫生要和實際在值班的醫生要匹配，不能出現掛上號了卻沒有醫生就診的情況。

? 物理上下文和邏輯上下文 物理上下文：醫院用于掛號的計算機可以正常的使用，情景中的可以被預約的醫生應該是在醫院值班的；而對于患者可以選擇在醫院進行預約，也可選擇在家中進行預約，只要在預約時間內能到達醫院就可。邏輯上下文：事件發生的條件是患者在系統中進行了預約，然后管理員會根據現有的資源（可以預約的醫生）對預約進行處理，如果同意，下一步就是醫生就診；如果沒有可以預約的醫生或合適的時間，患者的預約就不成功，患者需要重新選擇醫生或時間進行預約。

? 組成情景的主要事件和活動 主要事件：患者預約掛號，管理員對預約掛號的處理，醫生就診。主要活動：患者注冊、登錄系統，患者在系統中查詢可以預約的醫生和時間，患者取消已有預約，患者進行就診；管理員接受或拒絕預約，管理員分配醫生；醫生查詢預約信息。

? 涉及的執行者和其他參與者

執行者：醫院的醫生，預約掛號系統的管理員。其他參與者：醫院的相關人員，比如患者，前臺咨詢員等。

? 要使用的信息和資源 要使用的信息和資源包括，可以預約的醫生數量，所在科室等，醫院中的設備，病房等。? 要考慮的約束條件和要使用的規則 約束條件：同一醫生同一時間段內只能接受一名患者的預約，根據醫療設備的屬性決定是否要排他性的使用。

3、情景需求分析的步驟

需求規格說明輸入過程需求目標列表1.目標分析系統模型目標,目的使用情景用戶問題實例2.輸入事件分析初始系統模型用戶,環境事件情景腳本4.輸出需求分析3.刻畫系統輸出情景結構模型系統輸出類型信息需求5.社會影響分析Agent目標6.涉眾分析需求規格說明

3.1 目標分析

在第2部分情景描述的主要成分中已經對目標進行了分析，即：預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。3.2 輸入事件分析

對于該系統的輸入事件可能會包括如下情況：初始使用該系統的用戶需要先注冊，而對于已經注冊的用戶在使用系統預約掛號時首先要登錄系統。這是最基本的兩個輸入事件。3.3 刻畫系統輸出

對于系統輸出我們要考慮系統輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統是輸入的用戶名和密碼不匹配的時候要給出對應的提示信息，比如用戶名未注冊或密碼不對等。在提交預約掛號申請后系統也應給出預約成功與否的提示。3.4輸出需求分析

對于輸出需求要根據用戶的輸入給出對應的輸出。比如用戶輸入查詢請求，那么系統應該能夠給出詳細的信息。系統只給出對應的輸出還不夠，同時要考慮輸出的信息是否合適。比如用戶要查詢眼科醫生的資料，系統的輸出就應該只是眼科醫生的信息，而沒有必要把所有醫生的信息都輸出。3.5 社會影響分析

在進行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統的意識，導致人對意外處理的能力降低，比如系統臨時出現問題，是否有一套應急措施使醫院日常工作能夠正常的進行。

4、需求說明文檔

基于之前構建的模型，并參照IEEE 830-1998標準模板，撰寫的系統需求說明文檔如下。

4.1 引言

引言部分將對本文檔的編寫目的、系統的開發目的、名詞定義以及參考資料進行說明，并對文檔的后續內容進行概述。4.1.1 編寫目的

網上預約掛號系統是基于Web開發技術完成的網站。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。因此，基于之前構建的各類模型，撰寫系統的需求說明文檔，并將其作為后續項目設計、項目開發和項目測試的指導。

本文檔連同之前構建的模型，可用來與客戶進一步明確需求，同時可供項目經理、設計人員、開發人員參考。4.1.2 系統目的

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。4.1.3 名詞定義 ? 患者預約系統

網上預約掛號系統的子系統，主要用于為患者提供預約掛號、信息查詢等功能。? 醫生工作查詢系統

網上預約掛號系統的子系統，主要用于為醫生提供各時段預約患者的信息。? 醫務管理系統

網上預約掛號系統的子系統，主要用于為管理員提供出診信息修改、預約掛號調整等功能。? 賬號控制系統

網上預約掛號系統的子系統，主要用于用戶賬號的注冊及登錄控制。? 安全保障系統

網上預約掛號系統的子系統，主要用于保障系統的程序、網絡及數據庫安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網上預約掛號系統設計與實現[J].醫學信息學雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說明文檔主要分為三個部分。本節屬于引言部分，主要用于對文檔本身進行定義和描述。文檔的第二部分為系統的整體描述，包括系統的預期目標、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統需求的明確定義。

4.2 整體描述

本節將對系統預期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進行說明。

4.2.1 系統預期

為了方便用戶在不需安裝任何軟件的情況下使用系統，本系統整體采用B/S結構，用戶可以通過瀏覽器對其進行訪問。4.2.2 用戶需求

參照之前完成的目標模型，對用戶的需求進行整理和定義。由于系統整體較為復雜，因此本小節只包含已構建目標模型的功能性需求和非功能性需求。? 功能性需求

1.患者進行預約選擇

為了實現患者進行預約選擇的目標，系統應完成的需求如下。（1）系統擁有患者預約頁面以及預約按鈕：

系統的預約頁面可以顯示未來1至3天的出診醫生及其所有可被預約的出診時段。其中，尚未被預約的時段擁有預約按鈕；已被預約的時段無法被其他患者預約，因此無預約按鈕。（2）系統接收到預約請求：

當患者點擊預約按鈕，系統可以接收到預約請求。（3）患者被告知預約選擇結果：

系統可以對患者是否預約成功進行判定，如果成功則跳轉至信息確認頁面，否則彈出對話框給予患者相應提示。2.患者確認預約信息

為了實現患者確認預約信息的目標，系統應完成的需求如下。（1）系統擁有預約信息確認頁面以及預約提交按鈕：

系統的預約信息確認頁面會顯示預約的醫生和時段，患者的個人信息，以及預約提交按鈕，患者可以在提交預約前核對這些信息。（2）系統接收到預約提交請求：

當患者點擊提交按鈕，系統可以接收到預約提交請求。（3）患者被告知預約提交結果：

系統可以對預約是否提交成功進行判定，并彈出對話框給予患者相應提示。? 非功能性需求 1.安全的系統

為了保證預約掛號系統的安全性，系統應完成的需求如下。（1）用戶程序安全：

系統應明確區分不同類別用戶的權限。并且在用戶登錄時，輸入的密碼不可見、不可復制。（2）系統網絡安全：

系統應采取安全的網絡傳輸協議，網絡數據在被傳輸前應進行加密。（3）數據庫安全：

數據庫中存儲的數據應具備完整性，且密碼應在加密后被存儲到數據庫中。此外，數據庫中的數據應該可以被備份和恢復。2.低成本的系統 為了保證預約掛號系統的低成本，系統應完成的需求如下。（1）系統開發成本低：

開發團隊應具備合理的項目管理，且在開發前應盡可能明確系統的需求。（2）系統運營成本低：

系統在運行過程中，應該盡可能少的占用資源。（3）系統維護成本低：

系統應該健壯可靠，出現問題后應該易于修復，且系統的功能應該易于擴展。考慮到系統健壯可靠與系統開發成本低存在一定的沖突，因此需要進行一定的權衡。4.2.3 用戶特征

本系統的用戶包含患者、醫生以及管理員三類，其特征如下。? 患者

個體間在年齡、計算機使用能力等方面存在較大差異。? 醫生

普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。? 管理員

負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。4.2.4 條件與限制

為了保證系統的可移植性和可擴展性，本系統應使用Java語言進行開發。4.2.5 假定與依賴

本系統假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統的引導和提示下正常使用系統。4.2.6 需求分配

由于文檔中并未列出系統的全部需求，因此無法對所有需求進行優先級排序。但已經列出的均為系統較為核心的功能性需求和非功能性需求，應具有高優先級。

4.3 需求說明

需求說明部分將參照之前完成的模型，對系統結構、對象模型以及操作過程模型進行詳細描述。

4.3.1 系統結構

本部分將主要參照圖 3-1所示的責任模型，根據主體對需求進行劃分。考慮到系統較為復雜，因此只列出主體“患者預約系統”的相關需求。? 患者預約系統

系統擁有患者預約頁面以及預約按鈕。

系統接收到預約請求。

患者被告知預約選擇結果。

系統擁有預約信息確認頁面及預約提交按鈕。

系統接收到預約提交請求。

患者被告知預約提交的結果。4.3.2 對象模型

本部分將主要對圖 4-1所示的對象模型的結構進行解釋。

網上預約掛號系統可以被詳細劃分為患者預約系統、醫生工作查詢系統、醫務管理系統、賬號控制系統、安全保障系統等五個子系統。患者預約系統、醫生工作查詢系統、醫務管理系統的使用者分別為患者、醫生和管理員，這些用戶通過系統提供的頁面與系統進行交互。

對象模型中所涉及的名詞在4.1.3小節中有具體解釋。4.3.3 操作過程模型

本部分將主要對圖 5-1，圖 5-3和圖 5-4所示的操作過程模型進行說明，并以表格的形式列出各操作過程的參與主體及對應需求。? 患者進行預約選擇

患者點擊預約按鈕后，患者預約系統會收到患者的預約請求，并觸發預約驗證操作，得到預約驗證結果。接下來，患者預約系統會以得出的預約結果為基礎，進行預約結果判定，進而執行頁面跳轉或消息框彈出操作。? 患者確認預約信息

患者點擊提交按鈕后，患者預約系統會收到患者的預約提交請求，并觸發預約提交操作。接下來，患者預約系統會根據提交結果彈出包含相應信息的提示框。

以上部分涉及到的操作過程及與之對應的主體、需求如下表所示。

以上部分涉及到的操作過程及與之對應的主體、需求如表 4-1所示。

操作 預約驗證 參與主體

對應需求

患者預約系統 系統接收到預約請求，患者被告知預約選擇結果

預約結果判定 患者預約系統 患者被告知預約選擇結果 預約提交 患者預約系統 系統接收到預約提交請求，患者被告知預約提交結果