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

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

【摘要】

本文討論《企業(yè)人事信息系統(tǒng)》項(xiàng)目的需求分析方法與工具的選用。該系統(tǒng)的建設(shè)目標(biāo)是幫助該企業(yè)管理好企業(yè)內(nèi)部的人員和人員的活動(dòng)，人事信息管理指的是企業(yè)員工從招聘面試到離職退休的全過程，涉及的主要活動(dòng)包括面試、報(bào)到、培訓(xùn)、升職、離職或其他的人事變動(dòng)，也包括電子化考勤、工資性收入的計(jì)算與分發(fā)、使用其他公司資源的有關(guān)記錄（如宿舍、保險(xiǎn)、證件辦理等等）。此外，本系統(tǒng)也涉 及到企業(yè)在全國各地的人事信息管理，企業(yè)的組織架構(gòu)的設(shè)置，級(jí)別與職務(wù)管理，人力申請(qǐng)直至人力需求報(bào)表，從而形成一個(gè)對(duì)企業(yè)真正有用的人事信息管理應(yīng)用系統(tǒng)。在本文中首先討論了選用面向?qū)ο蠓椒ㄅc工具的主要理由與策略，進(jìn)一步通過一個(gè)簡例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需求分析中的必要性，最后簡要小結(jié)了選用正確工具與方法的意義和作用。

在項(xiàng)目開展期間，我擔(dān)任了系統(tǒng)分析、系統(tǒng)設(shè)計(jì)與數(shù)據(jù)庫管理等大量工作。

【正文】

人事信息管理系統(tǒng)是一個(gè)有著廣泛應(yīng)用面的實(shí)用性系統(tǒng)，但是，我國各個(gè)企業(yè)有著自身的體制、機(jī)制、特點(diǎn)與不同的要求；在開發(fā)這類系統(tǒng)時(shí)，系統(tǒng)需求分析是極為重要的一環(huán)。在整個(gè)分析過程中，我們都采用了面向?qū)ο蟮姆治龇椒?，這是因?yàn)槲覀冊(cè)诮鼛啄甑膶?shí)踐中已堅(jiān)信這種方法能夠更加有效地表達(dá)和描述現(xiàn)實(shí)世界。軟件要具有適用性和擴(kuò)展性，就必須更接近于現(xiàn)實(shí)世界本身的發(fā)展規(guī)律。

以一個(gè)簡單的例子來看，假設(shè)要求設(shè)計(jì)關(guān)于引進(jìn)人才評(píng)估的一個(gè)系統(tǒng)，按我們過去的做法，先會(huì)要求提供給我們一份相關(guān)的引進(jìn)人才評(píng)估表，然后依葫蘆畫瓢地設(shè)計(jì)相應(yīng)的表單與界面。在短期來說，這樣做是簡便而實(shí)用的，但并不能夠符合現(xiàn)實(shí)世界的長遠(yuǎn)目標(biāo)，這套設(shè)計(jì)方法不具有擴(kuò)展性，因?yàn)槿魏我环菰u(píng)估表的結(jié)構(gòu)都會(huì)有可能發(fā)生許多改變的。采用面向?qū)ο蟮姆椒?，可以從中提取出表類型、表結(jié)構(gòu)、評(píng)分方法以及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護(hù)性。

在工具的選擇過程中，我們選擇了現(xiàn)在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，為什么選取這個(gè)系列工具呢？這是基于我們對(duì)軟件需求分析目標(biāo)的看法，我們認(rèn)為需求分析應(yīng)當(dāng)能正確地回答如下的幾個(gè)關(guān)鍵性問題：

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

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

（3）分析是否會(huì)和設(shè)計(jì)相脫節(jié)，（4）程序員能明白我們的分析與設(shè)計(jì)要求嗎？等等。

以下對(duì)上述幾個(gè)問題逐一簡要地加以說明：

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

用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當(dāng)前的與明顯的需求。要達(dá)到對(duì)需求理解的全面性，不僅僅只是依靠有效的用戶談話和調(diào)查，因?yàn)槲覀兯鎸?duì)的用戶需求往往會(huì)有些片面的，采用Rational Rose（基于UML）提供的用例，以及多種圖的聯(lián)合使用，可以使我們發(fā)現(xiàn)其中的遺漏。

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

軟件需求分析規(guī)格說明書通常會(huì)是冗長而枯燥的，一般的用戶不容易深入理解，這樣就削弱了分析的正確性。通過支持面向?qū)ο蠹癠ML語言的Rational Rose可以更好地和用戶交流，讓用戶了解系統(tǒng)的運(yùn)作方式甚至細(xì)節(jié)的操作。

（3）使分析和設(shè)計(jì)兩個(gè)階段互相聯(lián)系與貫通。

這是我們選擇面向?qū)ο蟮姆椒癛ational Rose工具的重要原因，系統(tǒng)分析要向用戶描述的不僅僅是用戶的需求，而且包括解決方法，解決方法當(dāng)然應(yīng)包括設(shè)計(jì)（程序）、數(shù)據(jù)庫與系統(tǒng)配置，我們當(dāng)然不希望用戶得到的是一個(gè)與需求規(guī)格說明不相同的軟件，也不可能要求程序員完成一個(gè)不可勝任的任務(wù)。然而我們?cè)谝郧暗亩囗?xiàng)工作中經(jīng)常發(fā)現(xiàn)這類情節(jié)，因?yàn)橄到y(tǒng)分析與設(shè)計(jì)相互脫節(jié)，導(dǎo)致一頭扎在分析中不顧設(shè)計(jì)有關(guān)的事宜。

分析與設(shè)計(jì)的脫節(jié)，還不利于設(shè)計(jì)現(xiàn)格說明的評(píng)估，因?yàn)榉治鐾鶗?huì)脫離現(xiàn)實(shí)，導(dǎo)致缺乏評(píng)估的依據(jù)。

因?yàn)椴豢赡艹晒Φ赝瓿稍O(shè)計(jì)而使分析需要重來，就會(huì)造成巨大的浪費(fèi)與損失。一個(gè)好的工具可以使分析與設(shè)計(jì)更緊密地連結(jié)起來，甚至于—一對(duì)應(yīng)。面向?qū)ο蟮姆治龇椒ㄊ箤?duì)象之間相對(duì)而言有獨(dú)立性，減少了任何影響到全局的改動(dòng)，能避免因需求變化而導(dǎo)致全盤皆動(dòng)的被動(dòng)局面。

（4）使程序員明白我們的設(shè)計(jì)。

一個(gè)好的設(shè)計(jì)應(yīng)該讓程序員感到清晰明白，更少疑問。一個(gè)疑問很多的設(shè)計(jì)加上溝通不暢，絕對(duì)會(huì)出現(xiàn)在應(yīng)用環(huán)境下所不需要的另一個(gè)軟件，所以設(shè)計(jì)規(guī)格說明書務(wù)必清楚、形象與明確，當(dāng)然，Rational Rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細(xì)微到每一個(gè)語句（事實(shí)上如果使用VB，程序架構(gòu)都有可能直接生成了）。

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

比如用戶文檔的編寫、數(shù)據(jù)庫設(shè)計(jì)，我們都需要做到有延續(xù)性，有自動(dòng)化支持和具有質(zhì)量上的保證。

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

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

Rational Rose使我們更方便地把上面的想法在類上去實(shí)現(xiàn)，更進(jìn)一步地設(shè)計(jì)好我們的高效率的數(shù)據(jù)庫。

當(dāng)然，使用單一的一個(gè)工具去完成一個(gè)中大型的應(yīng)用系統(tǒng)的需求分析，是不可能成功的。因?yàn)樯鐣?huì)在發(fā)展，用戶的需求也在改變，如何把握住用戶的需求是需要時(shí)間的，面向?qū)ο蟮姆椒ㄓ袝r(shí)也會(huì)忽略外在的與表層的要求，不僅僅是要獲得關(guān)鍵的需求，其他更多的需求往往要等到用戶在使用后才知道，然而等到用戶使用是不現(xiàn)實(shí)的，作為原型開發(fā)模型中的原型也是收集用戶需求，描述與解釋需求的一類相當(dāng)有效的方法與工具。

在我們的開發(fā)過程中，為了更好地讓用戶了解我們的系統(tǒng)和我們的設(shè)計(jì)方案，讓用戶在見面會(huì)上更有方向性與針對(duì)性，我們首先用Access開發(fā)出原型，讓用戶先試用。這樣，我們?cè)谡嬲姆治雠c設(shè)計(jì)時(shí)就能更加符合用戶的要求。

總之，軟件需求分析方法和工具的使用，對(duì)我們軟件開發(fā)過程影響是很深遠(yuǎn)的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現(xiàn)實(shí)需求，更加具有可用性、可擴(kuò)展性和可維護(hù)性；降低了軟件項(xiàng)目的風(fēng)險(xiǎn)。

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

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

第二篇：6.培訓(xùn)需求方法和工具

進(jìn)行培訓(xùn)需求信息的收集和整理方法和工具

培訓(xùn)需求信息的收集與整理：組織分析、工作分析、個(gè)人分析。包括：動(dòng)態(tài)的需求、靜態(tài)的需求

(1)、動(dòng)態(tài)需求，因每個(gè)人的能力而異，需求各異；（人崗匹配為終點(diǎn)）(2)、靜態(tài)需求，是組織和崗位要求，對(duì)個(gè)人能力的要求的標(biāo)準(zhǔn)。（人崗匹配為終點(diǎn)）

培訓(xùn)需求信息可以通過檔案資料來收集

主要來源渠道有：

（1）來自于領(lǐng)導(dǎo)層的主要信息；

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

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

（4）來自于組織內(nèi)部個(gè)人的主要信息。

主要方法有：

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

交流，充分了解相關(guān)信息

（二）小組討論法（含重點(diǎn)團(tuán)隊(duì)分析法）：指在培訓(xùn)對(duì)象中選出一批熟悉問題的員工作為代表參加討論，以調(diào)查培訓(xùn)需求信息

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

工達(dá)到要求必須掌握的知識(shí)、技能和態(tài)度的依據(jù)，將其和員工平時(shí)工作中的表現(xiàn)進(jìn)行對(duì)比，判定員工要完成工作任務(wù)的差距所在。

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

工的工作技能、工作態(tài)度、了解其在工作中遇到的困難，搜集培訓(xùn)需求信息的方法。

（五）問卷調(diào)查法：

培訓(xùn)需求信息的工具：（1）培訓(xùn)需求概況信息調(diào)查工具；（2）態(tài)度、知識(shí)和技能需求信息調(diào)查工具；（3）課程選擇式調(diào)查工具；（4）外部培訓(xùn)機(jī)構(gòu)或培訓(xùn)經(jīng)銷商、服務(wù)商調(diào)查工具。

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

（一）做好培訓(xùn)前期的準(zhǔn)備工作；

1、建立員工背景檔案；

2、同各部門人員保持密切聯(lián)系；

3、向主

管領(lǐng)導(dǎo)反映情況；

4、準(zhǔn)備培訓(xùn)需求調(diào)查。

（二）制定培訓(xùn)需求調(diào)查計(jì)劃；

1、培訓(xùn)需求調(diào)查工作的行動(dòng)計(jì)劃；

2、確定培訓(xùn)需求調(diào)查工作的目

標(biāo)；

3、選擇合適的培訓(xùn)需求調(diào)查方法；

4、確定培訓(xùn)需求調(diào)查的內(nèi)容。

（三）實(shí)施培訓(xùn)需求調(diào)查工作；

1、提出培訓(xùn)需求動(dòng)議和愿望；

2、調(diào)查、申報(bào)、匯總需求動(dòng)議；

3、分析培訓(xùn)需求；

4、匯總培訓(xùn)需求意見，確認(rèn)培訓(xùn)需求。

（四）分析與輸出培訓(xùn)需求結(jié)果；

1、對(duì)培訓(xùn)需求調(diào)查信息進(jìn)行歸類、整理；

2、對(duì)培訓(xùn)需求進(jìn)行分

析、總結(jié)；

3、撰寫培訓(xùn)需求分析報(bào)告。

（六）測(cè)試法：

（七）自我分析法：

第三篇：數(shù)據(jù)分析軟件和工具

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

于我個(gè)人而言，所用的數(shù)據(jù)分析軟件包括EXCEL、SPSS、STATA、EVIEWS。在分析前期可以使用EXCEL進(jìn)行數(shù)據(jù)清洗、數(shù)據(jù)結(jié)構(gòu)調(diào) 整、復(fù)雜的新變量計(jì)算（包括邏輯計(jì)算）；在后期呈現(xiàn)美觀的圖表時(shí)，它的制圖制表功能更是無可取代的利器；但需要說明的是，EXCEL畢竟只是辦公軟件，它 的作用大多局限在對(duì)數(shù)據(jù)本身進(jìn)行的操作，而非復(fù)雜的統(tǒng)計(jì)和計(jì)量分析，而且，當(dāng)樣本量達(dá)到“萬”以上級(jí)別時(shí)，EXCEL的運(yùn)行速度有時(shí)會(huì)讓人抓狂。

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

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

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

做統(tǒng)計(jì)或計(jì)量，我認(rèn)為最難也最頭疼的就是進(jìn)行因果性判斷。假如你有A、B兩個(gè)變量的數(shù)據(jù)，你怎么知道哪個(gè)變量是因（自變量），哪個(gè)變量是果（因變量）？

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

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

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

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

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

關(guān)于分析工具的選擇

如果根據(jù)理論或邏輯已經(jīng)預(yù)設(shè)了變量間的因果關(guān)系，那么就無需使用實(shí)驗(yàn)方法。我對(duì)非實(shí)驗(yàn)數(shù)據(jù)分析工具的選擇原則如下。

? ? ? ? ? ? ? ? 因變量為連續(xù)變量，自變量至少有一個(gè)連續(xù)變量，進(jìn)行多元線性回歸； 因變量為連續(xù)變量，自變量全部為分類變量，進(jìn)行方差分析；

因變量為分類變量，自變量至少有一個(gè)連續(xù)變量，使用Logit模型或Probit模型； 因變量為分類變量，自變量全部為分類變量，進(jìn)行交叉表分析和卡方檢驗(yàn)；

因變量在某個(gè)閉區(qū)間內(nèi)分布，并且有較多樣本落在閉區(qū)間的邊界上，使用Tobit模型；

因變量不唯一，如多產(chǎn)出問題，進(jìn)行數(shù)據(jù)包絡(luò)分析（DEA）；

因變量為整數(shù)、數(shù)值小、取零個(gè)數(shù)較多，使用計(jì)數(shù)（Count）模型； 數(shù)據(jù)具有層次結(jié)構(gòu)（嵌套結(jié)構(gòu)），使用多層線性模型（HLM）。

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

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

很顯然，問這個(gè)問題的同學(xué)要么沒學(xué)好計(jì)量，要么就是犯了功利主義的錯(cuò)誤，或者二者皆有。擬合優(yōu)度的大小很大程度上取決于數(shù)據(jù)本身的性質(zhì)。如果數(shù)據(jù)是 時(shí)序數(shù)據(jù)，只要拿有點(diǎn)相關(guān)關(guān)系的變量進(jìn)行回歸就能使擬合優(yōu)度達(dá)到80%以上，但這樣的高R方根本說明不了什么，很可能使分析者陷入偽回歸的陷阱，嚴(yán)謹(jǐn)?shù)淖?法當(dāng)然是做平穩(wěn)性檢驗(yàn)和協(xié)整檢驗(yàn)；如果是截面數(shù)據(jù)，根本沒必要追求R方到80%的程度，一般來說，有個(gè)20%、30%就非常大了。

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

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

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

軟件測(cè)試需求分析與定義方法

如何確定測(cè)試工作的范圍？

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

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

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

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

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

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

注意，筆者這里的觀點(diǎn)并不是說可以取消團(tuán)隊(duì)中的“需求評(píng)審會(huì)議”，這里并不存在沖突。筆者所希望講述的，是測(cè)試人員應(yīng)該如何看待軟件需求，而并不是把“需求評(píng)審會(huì)議”所承擔(dān)的責(zé)任攬到自己身上。?在論壇上也偶爾看到有的朋友問：如何測(cè)試需求呢？每次看到這樣的提問，筆者內(nèi)心就禁不住的一陣激動(dòng)，因?yàn)橐恢币詠?，討論這方面問題的朋友的確少之又少。

在筆者的實(shí)際工作中，對(duì)軟件需求的檢查包括兩個(gè)方面的內(nèi)容。

一是對(duì)軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內(nèi)容是真實(shí)可靠的。在進(jìn)行這部分工作時(shí)，不要迷信所謂的“都是用戶提出的真實(shí)的需求”，因?yàn)槲覀儽仨毧紤]，提出這些需求的涉眾，是否真的可以正確的描述自己的需求？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認(rèn)為在業(yè)務(wù)處理上是理所當(dāng)然、極其平常的事情，而沒有作為需求提出來？有沒有一些被用戶認(rèn)為他們過去使用的軟件已經(jīng)提供了相應(yīng)的功能，所以認(rèn)為我們也應(yīng)當(dāng)提供，而沒有提出來的？關(guān)于這個(gè)問題，也曾經(jīng)有朋友提過不同的看法，認(rèn)為這樣對(duì)測(cè)試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業(yè)的業(yè)務(wù)。但筆者還是固執(zhí)的認(rèn)為，作為測(cè)試人員，還是需要對(duì)軟件產(chǎn)品所涉及的行業(yè)的業(yè)務(wù)有一個(gè)全面的、深入的了解——當(dāng)然，這不是對(duì)一個(gè)剛剛?cè)腴T的測(cè)試者的要求，但是如果想稱為一個(gè)優(yōu)秀的測(cè)試者，是難免要付出這部分努力的。

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

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

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

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

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

1、問題描述

許多醫(yī)院存在高峰期掛號(hào)排隊(duì)時(shí)間長，就診等待時(shí)間長，倒號(hào)現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個(gè)網(wǎng)上預(yù)約掛號(hào)系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時(shí)間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對(duì)系統(tǒng)進(jìn)行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統(tǒng)所涉及的用戶

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

對(duì)于患者來說，他們?cè)谀挲g、計(jì)算機(jī)使用能力等方面存在較大差異，但面對(duì)的情景都一樣，就是要預(yù)約掛號(hào)，掛號(hào)成功過后就診。

對(duì)于醫(yī)生來說，普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識(shí)，有一定的計(jì)算機(jī)使用能力。所面對(duì)的情景有查看掛號(hào)信息，確定要就診的病人。

對(duì)于管理員來說，他們負(fù)責(zé)對(duì)出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。

不同的用戶，對(duì)系統(tǒng)的要求也不相同?；颊呦Ｍㄟ^完成注冊(cè)和登錄后能夠進(jìn)行掛號(hào)預(yù)約，查詢醫(yī)生的出診信息和個(gè)人預(yù)約信息，并且能夠在規(guī)定的時(shí)間內(nèi)完成掛號(hào)預(yù)約或者取消已有的預(yù)約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預(yù)約情況；而管理員希望可以修改出診信息和調(diào)整預(yù)約掛號(hào)。這些都是功能性的需求。

同時(shí)對(duì)于所有用戶都希望該系統(tǒng)是易用的，而且能夠?qū)ψ约旱男畔⑵鸬奖Ｗo(hù)即系統(tǒng)安全性的要求，還有比如說系統(tǒng)的性能比較高效，能夠及時(shí)處理自己的預(yù)約申請(qǐng)。當(dāng)然開發(fā)系統(tǒng)的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標(biāo)和關(guān)鍵成功因素

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

? 物理上下文和邏輯上下文 物理上下文：醫(yī)院用于掛號(hào)的計(jì)算機(jī)可以正常的使用，情景中的可以被預(yù)約的醫(yī)生應(yīng)該是在醫(yī)院值班的；而對(duì)于患者可以選擇在醫(yī)院進(jìn)行預(yù)約，也可選擇在家中進(jìn)行預(yù)約，只要在預(yù)約時(shí)間內(nèi)能到達(dá)醫(yī)院就可。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進(jìn)行了預(yù)約，然后管理員會(huì)根據(jù)現(xiàn)有的資源（可以預(yù)約的醫(yī)生）對(duì)預(yù)約進(jìn)行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預(yù)約的醫(yī)生或合適的時(shí)間，患者的預(yù)約就不成功，患者需要重新選擇醫(yī)生或時(shí)間進(jìn)行預(yù)約。

? 組成情景的主要事件和活動(dòng) 主要事件：患者預(yù)約掛號(hào)，管理員對(duì)預(yù)約掛號(hào)的處理，醫(yī)生就診。主要活動(dòng)：患者注冊(cè)、登錄系統(tǒng)，患者在系統(tǒng)中查詢可以預(yù)約的醫(yī)生和時(shí)間，患者取消已有預(yù)約，患者進(jìn)行就診；管理員接受或拒絕預(yù)約，管理員分配醫(yī)生；醫(yī)生查詢預(yù)約信息。

? 涉及的執(zhí)行者和其他參與者

執(zhí)行者：醫(yī)院的醫(yī)生，預(yù)約掛號(hào)系統(tǒng)的管理員。其他參與者：醫(yī)院的相關(guān)人員，比如患者，前臺(tái)咨詢員等。

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

3、情景需求分析的步驟

需求規(guī)格說明輸入過程需求目標(biāo)列表1.目標(biāo)分析系統(tǒng)模型目標(biāo),目的使用情景用戶問題實(shí)例2.輸入事件分析初始系統(tǒng)模型用戶,環(huán)境事件情景腳本4.輸出需求分析3.刻畫系統(tǒng)輸出情景結(jié)構(gòu)模型系統(tǒng)輸出類型信息需求5.社會(huì)影響分析Agent目標(biāo)6.涉眾分析需求規(guī)格說明

3.1 目標(biāo)分析

在第2部分情景描述的主要成分中已經(jīng)對(duì)目標(biāo)進(jìn)行了分析，即：預(yù)約掛號(hào)情景的目標(biāo)是“讓患者能夠及時(shí)的掛號(hào)，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊(cè)賬號(hào)，患者能夠登錄賬號(hào)，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。3.2 輸入事件分析

對(duì)于該系統(tǒng)的輸入事件可能會(huì)包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊(cè)，而對(duì)于已經(jīng)注冊(cè)的用戶在使用系統(tǒng)預(yù)約掛號(hào)時(shí)首先要登錄系統(tǒng)。這是最基本的兩個(gè)輸入事件。3.3 刻畫系統(tǒng)輸出

對(duì)于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對(duì)話框等形式。不如用戶在登錄系統(tǒng)是輸入的用戶名和密碼不匹配的時(shí)候要給出對(duì)應(yīng)的提示信息，比如用戶名未注冊(cè)或密碼不對(duì)等。在提交預(yù)約掛號(hào)申請(qǐng)后系統(tǒng)也應(yīng)給出預(yù)約成功與否的提示。3.4輸出需求分析

對(duì)于輸出需求要根據(jù)用戶的輸入給出對(duì)應(yīng)的輸出。比如用戶輸入查詢請(qǐng)求，那么系統(tǒng)應(yīng)該能夠給出詳細(xì)的信息。系統(tǒng)只給出對(duì)應(yīng)的輸出還不夠，同時(shí)要考慮輸出的信息是否合適。比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應(yīng)該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。3.5 社會(huì)影響分析

在進(jìn)行社會(huì)影響分析時(shí)要同時(shí)考慮到積極和消極兩個(gè)方面的問題。系統(tǒng)是否可以提高效率，減少人員的工作量。同時(shí)也要考慮過多的自動(dòng)化是否會(huì)削弱人對(duì)整個(gè)系統(tǒng)的意識(shí)，導(dǎo)致人對(duì)意外處理的能力降低，比如系統(tǒng)臨時(shí)出現(xiàn)問題，是否有一套應(yīng)急措施使醫(yī)院日常工作能夠正常的進(jìn)行。

4、需求說明文檔

基于之前構(gòu)建的模型，并參照IEEE 830-1998標(biāo)準(zhǔn)模板，撰寫的系統(tǒng)需求說明文檔如下。

4.1 引言

引言部分將對(duì)本文檔的編寫目的、系統(tǒng)的開發(fā)目的、名詞定義以及參考資料進(jìn)行說明，并對(duì)文檔的后續(xù)內(nèi)容進(jìn)行概述。4.1.1 編寫目的

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)是基于Web開發(fā)技術(shù)完成的網(wǎng)站。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對(duì)系統(tǒng)進(jìn)行需求建模和分析是十分必要的。因此，基于之前構(gòu)建的各類模型，撰寫系統(tǒng)的需求說明文檔，并將其作為后續(xù)項(xiàng)目設(shè)計(jì)、項(xiàng)目開發(fā)和項(xiàng)目測(cè)試的指導(dǎo)。

本文檔連同之前構(gòu)建的模型，可用來與客戶進(jìn)一步明確需求，同時(shí)可供項(xiàng)目經(jīng)理、設(shè)計(jì)人員、開發(fā)人員參考。4.1.2 系統(tǒng)目的

許多醫(yī)院存在高峰期掛號(hào)排隊(duì)時(shí)間長，就診等待時(shí)間長，倒號(hào)現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個(gè)網(wǎng)上預(yù)約掛號(hào)系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時(shí)間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。4.1.3 名詞定義 ? 患者預(yù)約系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為患者提供預(yù)約掛號(hào)、信息查詢等功能。? 醫(yī)生工作查詢系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為醫(yī)生提供各時(shí)段預(yù)約患者的信息。? 醫(yī)務(wù)管理系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于為管理員提供出診信息修改、預(yù)約掛號(hào)調(diào)整等功能。? 賬號(hào)控制系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于用戶賬號(hào)的注冊(cè)及登錄控制。? 安全保障系統(tǒng)

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡(luò)及數(shù)據(jù)庫安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網(wǎng)上預(yù)約掛號(hào)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].醫(yī)學(xué)信息學(xué)雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說明文檔主要分為三個(gè)部分。本節(jié)屬于引言部分，主要用于對(duì)文檔本身進(jìn)行定義和描述。文檔的第二部分為系統(tǒng)的整體描述，包括系統(tǒng)的預(yù)期目標(biāo)、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對(duì)系統(tǒng)需求的明確定義。

4.2 整體描述

本節(jié)將對(duì)系統(tǒng)預(yù)期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進(jìn)行說明。

4.2.1 系統(tǒng)預(yù)期

為了方便用戶在不需安裝任何軟件的情況下使用系統(tǒng)，本系統(tǒng)整體采用B/S結(jié)構(gòu)，用戶可以通過瀏覽器對(duì)其進(jìn)行訪問。4.2.2 用戶需求

參照之前完成的目標(biāo)模型，對(duì)用戶的需求進(jìn)行整理和定義。由于系統(tǒng)整體較為復(fù)雜，因此本小節(jié)只包含已構(gòu)建目標(biāo)模型的功能性需求和非功能性需求。? 功能性需求

1.患者進(jìn)行預(yù)約選擇

為了實(shí)現(xiàn)患者進(jìn)行預(yù)約選擇的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕：

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

當(dāng)患者點(diǎn)擊預(yù)約按鈕，系統(tǒng)可以接收到預(yù)約請(qǐng)求。（3）患者被告知預(yù)約選擇結(jié)果：

系統(tǒng)可以對(duì)患者是否預(yù)約成功進(jìn)行判定，如果成功則跳轉(zhuǎn)至信息確認(rèn)頁面，否則彈出對(duì)話框給予患者相應(yīng)提示。2.患者確認(rèn)預(yù)約信息

為了實(shí)現(xiàn)患者確認(rèn)預(yù)約信息的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有預(yù)約信息確認(rèn)頁面以及預(yù)約提交按鈕：

系統(tǒng)的預(yù)約信息確認(rèn)頁面會(huì)顯示預(yù)約的醫(yī)生和時(shí)段，患者的個(gè)人信息，以及預(yù)約提交按鈕，患者可以在提交預(yù)約前核對(duì)這些信息。（2）系統(tǒng)接收到預(yù)約提交請(qǐng)求：

當(dāng)患者點(diǎn)擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請(qǐng)求。（3）患者被告知預(yù)約提交結(jié)果：

系統(tǒng)可以對(duì)預(yù)約是否提交成功進(jìn)行判定，并彈出對(duì)話框給予患者相應(yīng)提示。? 非功能性需求 1.安全的系統(tǒng)

為了保證預(yù)約掛號(hào)系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（1）用戶程序安全：

系統(tǒng)應(yīng)明確區(qū)分不同類別用戶的權(quán)限。并且在用戶登錄時(shí)，輸入的密碼不可見、不可復(fù)制。（2）系統(tǒng)網(wǎng)絡(luò)安全：

系統(tǒng)應(yīng)采取安全的網(wǎng)絡(luò)傳輸協(xié)議，網(wǎng)絡(luò)數(shù)據(jù)在被傳輸前應(yīng)進(jìn)行加密。（3）數(shù)據(jù)庫安全：

數(shù)據(jù)庫中存儲(chǔ)的數(shù)據(jù)應(yīng)具備完整性，且密碼應(yīng)在加密后被存儲(chǔ)到數(shù)據(jù)庫中。此外，數(shù)據(jù)庫中的數(shù)據(jù)應(yīng)該可以被備份和恢復(fù)。2.低成本的系統(tǒng) 為了保證預(yù)約掛號(hào)系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)開發(fā)成本低：

開發(fā)團(tuán)隊(duì)?wèi)?yīng)具備合理的項(xiàng)目管理，且在開發(fā)前應(yīng)盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運(yùn)營成本低：

系統(tǒng)在運(yùn)行過程中，應(yīng)該盡可能少的占用資源。（3）系統(tǒng)維護(hù)成本低：

系統(tǒng)應(yīng)該健壯可靠，出現(xiàn)問題后應(yīng)該易于修復(fù)，且系統(tǒng)的功能應(yīng)該易于擴(kuò)展?？紤]到系統(tǒng)健壯可靠與系統(tǒng)開發(fā)成本低存在一定的沖突，因此需要進(jìn)行一定的權(quán)衡。4.2.3 用戶特征

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

個(gè)體間在年齡、計(jì)算機(jī)使用能力等方面存在較大差異。? 醫(yī)生

普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識(shí)，有一定的計(jì)算機(jī)使用能力。? 管理員

負(fù)責(zé)對(duì)出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。4.2.4 條件與限制

為了保證系統(tǒng)的可移植性和可擴(kuò)展性，本系統(tǒng)應(yīng)使用Java語言進(jìn)行開發(fā)。4.2.5 假定與依賴

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

由于文檔中并未列出系統(tǒng)的全部需求，因此無法對(duì)所有需求進(jìn)行優(yōu)先級(jí)排序。但已經(jīng)列出的均為系統(tǒng)較為核心的功能性需求和非功能性需求，應(yīng)具有高優(yōu)先級(jí)。

4.3 需求說明

需求說明部分將參照之前完成的模型，對(duì)系統(tǒng)結(jié)構(gòu)、對(duì)象模型以及操作過程模型進(jìn)行詳細(xì)描述。

4.3.1 系統(tǒng)結(jié)構(gòu)

本部分將主要參照?qǐng)D 3-1所示的責(zé)任模型，根據(jù)主體對(duì)需求進(jìn)行劃分。考慮到系統(tǒng)較為復(fù)雜，因此只列出主體“患者預(yù)約系統(tǒng)”的相關(guān)需求。? 患者預(yù)約系統(tǒng)

系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕。

系統(tǒng)接收到預(yù)約請(qǐng)求。

患者被告知預(yù)約選擇結(jié)果。

系統(tǒng)擁有預(yù)約信息確認(rèn)頁面及預(yù)約提交按鈕。

系統(tǒng)接收到預(yù)約提交請(qǐng)求。

患者被告知預(yù)約提交的結(jié)果。4.3.2 對(duì)象模型

本部分將主要對(duì)圖 4-1所示的對(duì)象模型的結(jié)構(gòu)進(jìn)行解釋。

網(wǎng)上預(yù)約掛號(hào)系統(tǒng)可以被詳細(xì)劃分為患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)、賬號(hào)控制系統(tǒng)、安全保障系統(tǒng)等五個(gè)子系統(tǒng)。患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過系統(tǒng)提供的頁面與系統(tǒng)進(jìn)行交互。

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

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

患者點(diǎn)擊預(yù)約按鈕后，患者預(yù)約系統(tǒng)會(huì)收到患者的預(yù)約請(qǐng)求，并觸發(fā)預(yù)約驗(yàn)證操作，得到預(yù)約驗(yàn)證結(jié)果。接下來，患者預(yù)約系統(tǒng)會(huì)以得出的預(yù)約結(jié)果為基礎(chǔ)，進(jìn)行預(yù)約結(jié)果判定，進(jìn)而執(zhí)行頁面跳轉(zhuǎn)或消息框彈出操作。? 患者確認(rèn)預(yù)約信息

患者點(diǎn)擊提交按鈕后，患者預(yù)約系統(tǒng)會(huì)收到患者的預(yù)約提交請(qǐng)求，并觸發(fā)預(yù)約提交操作。接下來，患者預(yù)約系統(tǒng)會(huì)根據(jù)提交結(jié)果彈出包含相應(yīng)信息的提示框。

以上部分涉及到的操作過程及與之對(duì)應(yīng)的主體、需求如下表所示。

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

操作 預(yù)約驗(yàn)證 參與主體

對(duì)應(yīng)需求

患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約請(qǐng)求，患者被告知預(yù)約選擇結(jié)果

預(yù)約結(jié)果判定 患者預(yù)約系統(tǒng) 患者被告知預(yù)約選擇結(jié)果 預(yù)約提交 患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約提交請(qǐng)求，患者被告知預(yù)約提交結(jié)果