第一篇：需求分析與測試的重要性

需求分析與測試的重要性

讀《軟件工程案例教程》有感

對于學(xué)習(xí)軟件工程這門課程，我認(rèn)為有許多東西要學(xué)習(xí)。其實在我看來學(xué)習(xí)這門課程的精髓是學(xué)習(xí)一種方法。是一個如何去分析和處理問題的過程，應(yīng)該說其范疇已經(jīng)遠(yuǎn)遠(yuǎn)不止局限于該門課程，成為了一個綜合的一個能夠解決問題的思想集合。讀完軟件工程案例教程這本書，我覺得自己受益匪淺。

整本書的內(nèi)容邏輯很清晰明了，由淺入深循序漸進，首先我就大概描述下我們所學(xué)的內(nèi)容，第一章是從整體分析軟件工程這門學(xué)科的發(fā)展和所處的社會環(huán)境，接著后面的幾章深入分析了軟件開放過程和模式、軟件項目管理、計算機工程、需求分析、結(jié)構(gòu)化分析建模以及基于UML面向?qū)ο蠓治鼋：蜏y試等。對于這本書我主要對需求分析和測試比較感興趣，在這我要著重的談一些自己的心得體會以及自己的看法。

一．需求分析

1.1需求分析的重要性

一款成功的軟件是建立在成功的需求分析之上的，而高質(zhì)量的需求來源于用戶與開發(fā)人員之間有效的溝通與合作。當(dāng)用戶有一個問題可以用計算機系統(tǒng)來解決，而開發(fā)人員開始幫助用戶解決這個問題，溝通就開始了。由此我們可以看出需求分析的重要性。需求獲取可能是最困難、最關(guān)鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認(rèn)識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統(tǒng)的目標(biāo)特征，什么是要完成的，什么樣的系統(tǒng)能適合商業(yè)需要就可以了，但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題范圍，系統(tǒng)的邊界往往是很難明確的，用戶不了解技術(shù)實現(xiàn)的細(xì)節(jié)，這樣造成了系統(tǒng)目標(biāo)的混淆。

其次是對問題的理解，用戶對計算機系統(tǒng)的能力和限制缺乏了解，任何一個系統(tǒng)都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統(tǒng)，而不知道系統(tǒng)的整體情況，他們不知道系統(tǒng)作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發(fā)人員的協(xié)助和指導(dǎo)，但是用戶與開發(fā)人員之間的交流很容易出現(xiàn)障礙，忽略了那些被認(rèn)為是“很明顯”的信息。最后是需求的確認(rèn)，因為需求的不穩(wěn)定性往往隨著時間的推移產(chǎn)生變動，使之難以確認(rèn)。為了克服以上的問題，必須有組織的執(zhí)行需求的獲取活動。

1.2需求分析的原則

（1）需求分析必須能夠表達和理解問題的數(shù)據(jù)域和功能域。數(shù)據(jù)域包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)，而功能域反映上述3方面的控制信息。

（2）需求分析要把一個復(fù)雜問題按功能進行分解并逐層細(xì)化。通常，軟件系統(tǒng)要處理的問題如果太大、太復(fù)雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體的功能。在需求分析過程中，軟件系統(tǒng)的用戶需求中的數(shù)據(jù)、功能和行為都應(yīng)細(xì)化。

（3）需求建模。模型可以幫助系統(tǒng)分析人員更好地理解軟件系統(tǒng)的數(shù)據(jù)、功能和行為，這些模型是軟件工程中下一階段進行系統(tǒng)設(shè)計的基礎(chǔ)。

1.3需求分析的注意事項（1）確定詳細(xì)的需求，否則經(jīng)費就算不準(zhǔn)。經(jīng)費估計錯誤的原因多為：用戶需求頻繁變動、遺漏重要需求、與用戶交流不夠、需求規(guī)格說明書質(zhì)量低劣、需求分析不充分等。（2）在編寫需求規(guī)格說明書之前，應(yīng)明確要解決的問題。在試圖解決問題之前，要保證已考察了全部可替代的方案。要搞清哪地方有問題，真正的問題出在哪里。這樣，在編寫需求規(guī)格說明書時做到有的放矢，把存在的問題暴露出來。

（3）立即確定需求，并記錄下該需求的背景。沒有明確問題，就進行下一步的設(shè)計，想回避矛盾，可能會帶來更大的問題。用戶不確定需求，軟件設(shè)計人員自己決定需求，將會帶來嚴(yán)重的問題。為了避免將來可能出現(xiàn)的問題和軟件工程項目能夠盡快地進入到下一個階段的系統(tǒng)設(shè)計中，要盡可能迅速地把用戶需求確定下來。任何決定總比沒有決定要好。

（4）一旦在需求規(guī)格說明書中發(fā)現(xiàn)問題，立即改正。如果把存在的問題拖延到系統(tǒng)設(shè)計階段去改正，就可能要花數(shù)倍的時間和精力才能糾正同一錯誤。

（5）在眾多用戶需求中確定各個需求的優(yōu)先順序，并確定可能存在的子集，以便為軟件設(shè)計、實施和項目管理等后續(xù)階段提供有利條件。

（6）需求分析時，不要進行系統(tǒng)設(shè)計的工作。需求分析的主要目的是確定軟件系統(tǒng)的外部特征，充分反映軟件系統(tǒng)應(yīng)有的面貌，便于讓軟件設(shè)計人員根據(jù)用戶需求，去全面地考慮軟件系統(tǒng)的體系結(jié)構(gòu)、算法等。在需求分析階段要集中精力解決用戶需求存在的問題，盡可能避免產(chǎn)生遺留問題。

（7）對于復(fù)雜的軟件系統(tǒng)，要從多種視角進行需求分析。根據(jù)軟件系統(tǒng)的本質(zhì)，切合實際地組織多種視角的需求。例如，可從根據(jù)用戶的類型，或根據(jù)響應(yīng)的類型，或根據(jù)對象的軟件工程案例教程類型，或根據(jù)系統(tǒng)的模式等視角來組織用戶需求。通過多個視角來研究用戶需求問題，把可得到的不同的“投影”組合起來形成完整系統(tǒng)的描述。當(dāng)試圖從整體觀點來描述軟件系統(tǒng)發(fā)生困難，或者有可能發(fā)生錯誤，或者很有可能遺失軟件系統(tǒng)的某些特性。而從不同的視角來 描述軟件系統(tǒng)，因為每個視角限制了研究的范圍并能夠?qū)⒆⒁饬杏诖?，所以很容易保證所研究的問題是真正完整的。

（8）重視形式化方法，但不放棄自然語言。為了用戶需求表達的精確性和方便用戶的可理解性，一個好方法是把自然語言的表達與形式化規(guī)格說明并立，互相對照，而且在一般情況下，先用自然語言寫出，再給出它的形式模型。

（9）用戶需求中不應(yīng)存在“待確定”的條款。如若有這種需要，應(yīng)同時說明：何時由誰來解決該問題。

1.4用戶需求的類型

需求分析是從用戶最初的非形式化需求到滿足用戶要求的軟件產(chǎn)品的映射過程。它實際上是一個對用戶意圖不斷進行揭示和判斷的過程，其目的在于細(xì)化、精化軟件的作用范圍，確定擬開發(fā)軟件的功能和性能、約束、環(huán)境等?？蓪⒂脩舻男枨蠓譃閮纱箢悾汗δ苄孕枨蠛头枪δ苄孕枨?。

（1）功能性需求。功能性需求主要說明了系統(tǒng)各功能部件與環(huán)境之間的相互作用的本質(zhì)，即擬開發(fā)軟件在職能上實際應(yīng)做到什么。一般來說，它是用戶最主要的需求，通常包括系統(tǒng)的輸入、系統(tǒng)能完成的功能、系統(tǒng)的輸出以及其他反應(yīng)。在功能性需求中還應(yīng)包括備選功能的定義識別。

（2）非功能性需求。非功能性要求主要從各個角度對所考慮的可能的解決方案起約束和限制作用。1.5需求分析的方法

在軟件工程中，常用的需求分析方法有面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（簡稱 SA）和面向?qū)ο蟮姆治龇椒ǎê喎Q OOA）。此外，還有以用戶為中心的需求分析方法。這些方法都采用圖文結(jié)合的方式，可以直觀地描述軟件的邏輯模型。這里僅介紹結(jié)構(gòu)化分析方法和以用戶為中心的需求分析方法。

二.軟件測試

2.1軟件測試概述

軟件本身無形態(tài)，它是復(fù)雜的知識高度密集的邏輯產(chǎn)品，其中不可能沒有錯誤。軟件實施工程過程中必須伴隨著軟件質(zhì)量保證的活動，而軟件測試是主要活動之一。在開發(fā)軟件的過程中，人們使用了許多保證軟件質(zhì)量的方法分析、設(shè)計和實現(xiàn)軟件，但難免還會在工作中犯錯誤。這樣，在軟件產(chǎn)品中就會隱藏許多錯誤和缺陷。對于規(guī)模大、復(fù)雜性高的軟件更是如此。在這些錯誤中，有些是致命的錯誤，如果不排除，就會導(dǎo)致生命與財產(chǎn)的重大損失。

2.2軟件測試的目的

測試的目的是“說明程序能正確地執(zhí)行應(yīng)有的功能”，還是“表明程序沒有錯誤”？基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產(chǎn)品。而從軟件開發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質(zhì)量的信心。因此，他們會選擇那些導(dǎo)致程效概率小的測試用例，回避那些易于暴露程序錯誤的測試用例。同時，也不會刻意去檢測、排除程序中可能包含的副作用。顯然，這樣的測試對完善和提高軟件質(zhì)量毫無價值。因為在程序中往往存在著許多預(yù)料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來。如果不把著眼點放在盡可能查找錯誤這樣一個基礎(chǔ)上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運行階段中去。如果站在用戶的角度，替他們設(shè)想，就應(yīng)當(dāng)把測試活動的目標(biāo)對準(zhǔn)揭露程序中存在的錯誤。在選取測試用例時，考慮那些易于發(fā)現(xiàn)程序錯誤的數(shù)據(jù)。

2.3軟件測試的原則

（1）應(yīng)當(dāng)把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。由于原始問題的復(fù)雜性、軟件的復(fù)雜性和抽象性、軟件開發(fā)各個階段工作的多樣性，以及參加開發(fā)各種層次人員之間工作的配合關(guān)系等因素，使得開發(fā)的每個環(huán)節(jié)都可能產(chǎn)生錯誤。所以不應(yīng)把軟件測試僅僅看成是軟件開發(fā)的一個獨立階段，而應(yīng)當(dāng)把它貫穿到軟件開發(fā)的各個階段中。在需求分析階段就應(yīng)該制訂測試計劃，以保證每個需求，每個設(shè)計單元都是可測試的，便于測試。堅持在軟件開發(fā)的各個階段的技術(shù)評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預(yù)防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些隱患，提高軟件質(zhì)量。

（2）測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。測試以前應(yīng)當(dāng)根據(jù)測試的要求，選擇在測試過程中使用的測試用例（Test Case）。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果。如果對測試輸入數(shù)據(jù)沒有給出預(yù)期的程序輸出結(jié)果，那么就缺少了檢驗實測結(jié)果的基準(zhǔn)，就有可能把一個似是而非的錯誤結(jié)果當(dāng)成正確結(jié)果。

（3）程序員應(yīng)避免檢查自己的程序。測試工作需要嚴(yán)格的作風(fēng)、客觀的態(tài)度和冷靜的情緒。自己測試自己的軟件不容易發(fā)現(xiàn)錯誤，程序員應(yīng)避免測試自己的程序。測試是一種“挑剔性”的行為，人們常常由于各種原因具有一種不愿否定自己工作的心理，認(rèn)為揭露自己程序中的問題總不是一件愉快的事，這一心理狀態(tài)就成為測試自己程序的障礙。心理狀態(tài)和思維定式是測試自己程序的兩大障礙，應(yīng)由別人或另外的機構(gòu)來測試程序員編寫的程序。另外，程序員對軟件規(guī)格說明理解錯誤而引入的錯誤則更難發(fā)現(xiàn)。如果由別人來測試程序員編寫的程序，可能會更客觀、更有效，并更容易取得成功。要注意的是，這點不能與程序的調(diào)試（Debugging）互相混淆，調(diào)試由程序員自己來做可能更有效。

（4）在設(shè)計測試用例時，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問題變異的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應(yīng)該做的事情，而忽視了不合法的和預(yù)想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶軟件工程案例教程 在鍵盤上按錯了鍵或打入了非法的命令。如果開發(fā)的軟件遇到這種情況時不能做出適當(dāng)?shù)姆磻?yīng)，給出相應(yīng)的信息，那么就容易產(chǎn)生故障，輕則給出錯誤的結(jié)果，重則導(dǎo)致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸件測試程序時，往往比用合理的輸入條件進行測試能發(fā)現(xiàn)更多的錯誤。

小結(jié)：經(jīng)過一學(xué)期的軟件工程的學(xué)習(xí)，深刻感到其重要性的同時也學(xué)到了不少的東西，將對我在今后的軟件開發(fā)過程中起極大的作用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第三篇：員工培訓(xùn)的需求分析重要性!

員工培訓(xùn)的需求分析重要性！

明陽天下拓展培訓(xùn)

所謂的培訓(xùn)需求分析是指在規(guī)劃與設(shè)計每項培訓(xùn)活動之前，由培訓(xùn)部門、主管人員、工作人員等采取各種方法和技術(shù)，對各種組織及其成員的目標(biāo)、知識、技能等方面進行系統(tǒng)的鑒別與分析，以確定是否需要培訓(xùn)及培訓(xùn)內(nèi)容的一種活動或過程。培訓(xùn)需求分析是確定培訓(xùn)目標(biāo)、設(shè)計培訓(xùn)規(guī)劃的前提，也是進行培訓(xùn)評估的基礎(chǔ)，因而它是搞好培訓(xùn)工作的關(guān)鍵。如何進行培訓(xùn)的需求分析，一般來說應(yīng)從以下幾個方面人手： 1．組織分析。

培訓(xùn)需求的組織分析主要是通過對組織的目標(biāo)、資源、特質(zhì)、環(huán)境等因素的分析，準(zhǔn)確地找出組織存在的問題與問題產(chǎn)生的根源，以確定培訓(xùn)是否是解決這類問題的最有效的方法。一般而言，組織分析主要包括下列幾個重要步驟：

（1）組織目標(biāo)分析。明確、清晰的組織目標(biāo)既對組織的發(fā)展起決定性作用，也對培訓(xùn)規(guī)劃的設(shè)計與執(zhí)行起決定性作用，組織目標(biāo)決定培訓(xùn)目標(biāo)。比如說，如果一個組織的目標(biāo)是提高產(chǎn)品的質(zhì)量，那么培訓(xùn)活動就必須與這一目標(biāo)相一致。假若組織目標(biāo)模糊不清時，培訓(xùn)規(guī)劃的設(shè)計與執(zhí)行就顯得很困難。

（2）組織資源分析。如果沒有確定可被利用的人力、物力和財力資源，就難以確立培訓(xùn)目標(biāo)。組織資源分析包括對組織的金錢、時間、人力等資源的描述。組織所能提供的經(jīng)費將影響培訓(xùn)的范圍和深度?！r間。對組織而言，時間就是金錢，培訓(xùn)是需要相當(dāng)?shù)臅r間的，如果時間緊迫或安排不當(dāng)，極有可能造成粗略的培訓(xùn)結(jié)果?！と肆ΑM織人力狀況的了解非常重要，它是決定是否培訓(xùn)的關(guān)鍵因素。組織的人力狀況包括：工作人員的數(shù)量、工作人員的年齡、工作人員對工作與單位的態(tài)度、工作人員的技能水平和知識水平、工作人員的工作績效等。

（3）組織特質(zhì)與環(huán)境分析。主要包括如下內(nèi)容：

系統(tǒng)特質(zhì)。指組織的輸入、運作、輸出、次級系統(tǒng)互動以及與外界環(huán)境間的交流特質(zhì)，使管理者能夠系統(tǒng)地面對組織，避免組織分析中以偏概全的缺失。

文化特質(zhì)。指組織的軟硬體設(shè)施、規(guī)章、制度、組織經(jīng)營運作的方式、組織成員待人處事的特殊風(fēng)格，使管理者能夠深入了解組織，而非僅僅停留在表面。

資訊傳播特質(zhì)。指組織部門和成員收集、分析和傳遞信息的分工與運作，促使管理者了解組織信息傳遞和溝通的特性。對上述問題和特性的了解，將有助于管理者及培訓(xùn)部門全面真實地了解組織。2．工作分析。

工作分析的目的在于了解與績效問題有關(guān)的工作的詳細(xì)內(nèi)容、標(biāo)準(zhǔn)，和達成工作所應(yīng)具備的知識和技能。工作分析的結(jié)果也是將來設(shè)計和編制相關(guān)培訓(xùn)課程的重要資料來源。工作分析依據(jù)分析目的的不同可分為兩種：

（1）一般工作分析。其內(nèi)容為：工作簡介-主要說明一項工作的性質(zhì)與范圍，使閱讀者能很快建立一個較為正確的印象。其內(nèi)容包括：工作名稱、地點、單位、生效及取消日期、分析者、核準(zhǔn)者等基本資料。工作清單-工作清單是將工作內(nèi)容以工作單元為主體，并以條列方式組合而成，使閱讀者能對工作內(nèi)容一目了然。

（2）殊工作分析。特殊工作分析可分為下列數(shù)項：程序性工作分析。程序性工作就是具有固定的工作起點、一定順序的工作步驟和固定的工作終點等特性。程序性工作分析主要強調(diào)工作者和器物間的互動關(guān)系。程序性工作分析就是通過詳細(xì)記錄工作單元的名稱、特點、標(biāo)準(zhǔn)、應(yīng)具的知識技能、安全及注意事項、完整操作程序等，為員工的培訓(xùn)和培訓(xùn)評估提供依據(jù)?！こ淌叫怨ぷ鞣治?。3．工作者分析。

工作者分析主要是通過分析工作人員個體現(xiàn)有狀況與應(yīng)有狀況之間的差距，來確定誰需要和應(yīng)該接受培訓(xùn)以及培訓(xùn)的內(nèi)容。工作者分析的重點是評價工作人員實際工作績效以及工作能力。其中包括下列數(shù)項：

（1）個人考核績效記錄。主要包括員工的工作能力、平時表現(xiàn)（請假、怠工、抱怨）、意外事件、參加培訓(xùn)的記錄、離（調(diào)）職訪談記錄等。

（2）員工的自我評量。自我評量是以員工的工作清單為基礎(chǔ)，由員工針對每一單元的工作成就、相關(guān)知識和相關(guān)技能真實地進行自我評量。

（3）知識技能測驗。已實際操作或筆試的方式測驗工作人員真實的工作表現(xiàn)。

（4）員工態(tài)度評量。員工對工作的態(tài)度不僅影響其知識技能的學(xué)習(xí)和發(fā)揮，還影響與同事間的人際關(guān)系，影響與顧客或客戶的關(guān)系，這些又直接影響其工作表現(xiàn)。因此，運用定向測驗或態(tài)度量表，就可幫助了解員工的工作態(tài)度。4．培訓(xùn)需求的戰(zhàn)略分析。

傳統(tǒng)上，人們習(xí)慣于把培訓(xùn)需求分析集中在個體和組織需求的層次上，并以此作為設(shè)計培訓(xùn)規(guī)劃的依據(jù)。一般說來，集中于個體與組織的需求，往往是對組織過去與現(xiàn)在的需求比較敏感。但是，當(dāng)組織狀況發(fā)生了重大變化時，那種集中于過去和現(xiàn)在的需求分析將會引起組織資源的無效應(yīng)用。但現(xiàn)在這種狀況已經(jīng)發(fā)生了巨大的變化，培訓(xùn)需求的未來分析，即戰(zhàn)略分析，已越來越受到人們的重視并被提到一個重要的戰(zhàn)略位置之上。培訓(xùn)需求的戰(zhàn)略分析，主要包括以下幾個方面：（1）組織優(yōu)先權(quán)的改變。引起組織優(yōu)先權(quán)改變的因素是多種多樣的，主要包括：

新技術(shù)的引進。如資料處理能力的提高使組織的結(jié)構(gòu)、功能、性質(zhì)等發(fā)生**性改造。

財政上的約束。由于面臨財政緊缺問題，各種層級的組織都把它們的規(guī)劃削減到前所未有的程度，或者干脆完全終止規(guī)劃。

組織的撤銷、分割或合并。隨著外界環(huán)境的變化，原有組織承擔(dān)的任務(wù)已經(jīng)完成或根本不存在，這就需要撤銷組織。分割或合并是指把一個單位分成幾個單位或把幾個單位合并成一個單位，工作重心發(fā)生轉(zhuǎn)移。

各種臨時性、突發(fā)性任務(wù)的出現(xiàn)。外界環(huán)境的變化，引起各種臨時性、突發(fā)性任務(wù)的出現(xiàn)，需要建立新的組織，或改變原有的組織，以解決這些任務(wù)。

以上因素的變更，則要求培訓(xùn)部門在進行培訓(xùn)需求分析中不能僅僅考慮現(xiàn)在的需要和建立在過去傾向基礎(chǔ)上的服務(wù)提供，它必須是前瞻性的。它必須決定未來的需要并為他們作準(zhǔn)備，盡管這些需要同現(xiàn)在的需要可能完全不同。

（2）人事預(yù)測。由于組織的大部分預(yù)算是花在人事部門上，因此，人事預(yù)測是很重要的。人事預(yù)測主要包括需求預(yù)測和供給預(yù)測。需求預(yù)測主要是考察一個組織所需要的人員數(shù)量以及這些人員必須掌握的技能。對于穩(wěn)定性組織而言，過去的傾向無疑是未來需求的指示燈，而對于經(jīng)歷巨大變革的組織來說，過去的傾向需要只有和其他預(yù)測技術(shù)結(jié)合起來才可確定未來的需求。供給預(yù)測不但要考察可能參加工作的人員的數(shù)量，而且要考察這些人員所具有的技能狀況，以便為人員的雇傭、培訓(xùn)與再培訓(xùn)提供依據(jù)。在人事預(yù)測過程中，還應(yīng)注意和發(fā)揮各方面專家的作用，并注意征求工作人員的意見，這樣培訓(xùn)需求分析才切實可行，才可真實反映組織的未來發(fā)展?fàn)顩r。

（3）組織態(tài)度調(diào)查。在培訓(xùn)需求的戰(zhàn)略分析中，收集全體工作人員對其工作、補償金、救濟金、同事等的態(tài)度和滿意程度也是很有用處的。因為，對組織態(tài)度的調(diào)查能夠幫助查出組織內(nèi)最需要培訓(xùn)的領(lǐng)域；是否需要培訓(xùn)以外的方法；而且還能找出和確認(rèn)那些阻礙改革和反對培訓(xùn)的領(lǐng)域。一般來說，了解工作人員對組織的態(tài)度及滿意程度應(yīng)立足于利益領(lǐng)域。例如，根據(jù)工作人員對組織滿意程度的不同，就可以表明他們對組織的態(tài)度與看法。我收到的補償金是可觀的。我為之匯報的人設(shè)置了清晰的問題。在我的工作團體中有一種信任和開放意識。告訴別人為組織工作我感到很自豪。

通過調(diào)查，我們就可以清楚地知道并了解到：是否有人認(rèn)為組織中的個人或團體缺乏技能？是否有人認(rèn)為組織缺乏和諧的人際關(guān)系和管理技能？組織是否被認(rèn)為觀念復(fù)雜？組織和個人利益被認(rèn)為是一致還是沖突？對這些問題的不同回答，將產(chǎn)生不同的培訓(xùn)與組織開發(fā)。如果是技術(shù)能力方面的問題，那么進行傳統(tǒng)的培訓(xùn)是適宜的；如果是人際關(guān)系方面的原因，則需要進行管理培訓(xùn)；如果是觀念認(rèn)同的問題，就需要重新確定組織目標(biāo)或作出解釋；如果是工作人員與組織之間的一致性較差，就需要加強職業(yè)生涯的開發(fā)?？傊?，組織態(tài)度的分析對組織的培訓(xùn)與開發(fā)規(guī)劃是非常重要的。

本文轉(zhuǎn)自明陽天下拓展培訓(xùn)官網(wǎng)，轉(zhuǎn)載請注明出處。

第四篇：需求分析在軟件開發(fā)中的重要性

需求分析在軟件開發(fā)中的重要性

摘要：

“需求分析”,就是對需要解決的問題進行詳細(xì)分析,弄清楚需要解決的問題。開發(fā)人員需要了解顧客的需求,然后體現(xiàn)在軟件中。如果說軟件開發(fā)過程中,開發(fā)人員需要了解自己做什么,顧客需要告訴開發(fā)人員自己需要什么,而需求分析就是連接開發(fā)人員和顧客之間的重要紐帶。只有真正理解顧客的需求,才能設(shè)計出顧客所需要的軟件。

在過去很長一段時間,開發(fā)人員的認(rèn)為需求分析是整個開發(fā)過程中最簡單的一個環(huán)節(jié)。然后越來越多的開發(fā)人員認(rèn)識到它才是整個開發(fā)過程中的核心部分。正所謂“磨刀不誤砍柴工”。只有真正理解了顧客的需求,才能順利開發(fā)出顧客真正需要的軟件。如果一味追求進度,而忽略需求分析,很可能南轅北轍,開發(fā)變得毫無意義。

關(guān)鍵字：需求分析，詳細(xì)分析，開發(fā)過程，進度，開發(fā)人員。

一、緒論

隨著計算機在日常工作中的普及，軟件開發(fā)行業(yè)作為其必不可少的組成部分，被人們所認(rèn)可。在我國，軟件行業(yè)日漸成熟，小作坊式的開發(fā)形式，已經(jīng)不能滿足我國對于軟件規(guī)范化、實用性的要求，軟件開發(fā)流程化及各個職能部門工作的有效劃分和正確協(xié)作，是現(xiàn)在軟件行業(yè)面臨的一個較大的問題。軟件需求分析是軟件開發(fā)的出發(fā)點，為設(shè)計起到指導(dǎo)性作用，所以需求分析在軟件行業(yè)及開發(fā)流程中起著非常重要的作用。

“需求分析”,就是對需要解決的問題進行詳細(xì)分析,弄清楚需要解決的問題。開發(fā)人員需要了解顧客的需求,然后體現(xiàn)在軟件中。如果說軟件開發(fā)過程中,開發(fā)人員需要了解自己做什么,顧客需要告訴開發(fā)人員自己需要什么,而需求分析就是連接開發(fā)人員和顧客之間的重要紐帶。只有真正理解顧客的需求,才能設(shè)計出顧客所需要的軟件。

在過去很長一段時間,開發(fā)人員的認(rèn)為需求分析是整個開發(fā)過程中最簡單的一個環(huán)節(jié)。然后越來越多的開發(fā)人員認(rèn)識到它才是整個開發(fā)過程中的核心部分。正所謂“磨刀不誤砍柴工”。只有真正理解了顧客的需求,才能順利開發(fā)出顧客真正需要的軟件。如果一味追求進度,而忽略需求分析,很可能南轅北轍,開發(fā)變得毫無意義。

一、什么是軟件需求分析

通俗地說，軟件需求分析是解決做什么，怎么做的問題。告訴客戶及開發(fā)人

員，需要實現(xiàn)哪些功能，以何種方式，在什么平臺去進行操作，開發(fā)結(jié)束后，應(yīng)交付哪些東西。

需求分析就是分析軟件用戶的需求是什么.如果投入大量的人力，物力,財力,時間,開發(fā)出的軟件卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發(fā)一個軟件,最后卻不滿足用戶的要求,從而要重新開發(fā),這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟件,而你在軟件開發(fā)前期忽略了軟件的運行環(huán)境,忘了向用戶詢問這個問題,而想當(dāng)然的認(rèn)為是開發(fā)for windows的軟件,當(dāng)你千辛萬苦地開發(fā)完成向用戶提交時才發(fā)現(xiàn)出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.(這個問題是最典型也是最常見的,現(xiàn)在這個問題一般很好避免,都知道項目的一些敏感性的東西,例如想會有哪些地方設(shè)計的不好可能導(dǎo)致以后的使用出現(xiàn)BUG.)

二、需求分析的任務(wù)

簡言之,需求分析的任務(wù)就是解決“做什么”的問題,就是要全面地理解用戶的各項要求,并準(zhǔn)確地表達所接受的用戶需求.(一)了解顧客的要求

這是需求分析的重點任務(wù),也是最基本的任務(wù)。只有正確了解、理解顧客的要求,才能順利完成需求分析。

(二)分析系統(tǒng)的數(shù)據(jù)要求

軟件產(chǎn)品是指軟件開發(fā)商根據(jù)市場需要開發(fā)的、具有一定適用性和潛在客戶的、可銷售的軟件成品。它區(qū)別于應(yīng)特定客戶需求或根據(jù)訂單開發(fā)的軟件商品，通常應(yīng)具有更高的通用性和適應(yīng)性。但它的通用性和適應(yīng)性不是輕而易舉就能達到的。要實現(xiàn)軟件的產(chǎn)品化，就必須在軟件產(chǎn)品的設(shè)計上下一番功夫。

本文結(jié)合一個“多媒體遠(yuǎn)程教學(xué)系統(tǒng)”實例，探討軟件產(chǎn)品設(shè)計中的一些經(jīng)驗與看法。

三、需求分析的過程

需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規(guī)格說明,評審.（一）、問題識別

就是從系統(tǒng)角度來理解軟件,確定對所開發(fā)系統(tǒng)的綜合要求,并提出這些需求的實現(xiàn)條件,以及需求應(yīng)該達到的標(biāo)準(zhǔn).這些需求包括：功能需求(做什么),性能需求(要達到什么指標(biāo)),環(huán)境需求(如機型,操作系統(tǒng)等),可靠性需求(不發(fā)生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟件運行是所需的內(nèi)存,CPU等),軟件成本消耗與開發(fā)進度需求,預(yù)先估計以后系統(tǒng)可能達到的目標(biāo).（二）、分析與綜合逐步細(xì)化所有的軟件功能,找出系統(tǒng)各元素間的聯(lián)系,接口特性和設(shè)計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最后,綜合成系統(tǒng)的解決方案,給出要開發(fā)的系統(tǒng)的詳細(xì)邏輯模型(做什么的模型).（三）、制訂規(guī)格說明書

即編制文檔,描述需求的文檔稱為軟件需求規(guī)格說明書.請注意,需求分析階段的成果是需求規(guī)格說明書(好象軟考曾經(jīng)考過這個問題),向下一階段提交.（四）、評審

對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審?fù)ㄟ^才可進行下一階段的工作,否則重新進行需求分析。

四、需求分析的方法

需求分析的方法有很多.這里只強調(diào)原型化方法,其它的方法如:結(jié)構(gòu)化方法,動態(tài)分析法等(個人認(rèn)為,對初學(xué)者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.原型化方法是十分重要的(是軟考等?？嫉闹R點).原型就是軟件的一個早期可運行的版本,它實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能.原型化方法就是盡可能快地建造一個粗糙的系統(tǒng),這系統(tǒng)實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能,但是這個系統(tǒng)可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統(tǒng)的目的是為了考察某一方面的可行性,如算法的可行性,技術(shù)的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟件工具快速的建造一個原型系統(tǒng),這個系統(tǒng)只是一個界面,然后聽取用戶的意見,改進這個原型.以后的目標(biāo)系統(tǒng)就在原型系統(tǒng)的基礎(chǔ)上開發(fā).原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目的是要弄清楚對目標(biāo)系統(tǒng)的要求,確定所希望的特性,并探討多種方案的可行性.實驗型:用于大規(guī)模開發(fā)和實現(xiàn)前,考核方案是否合適,規(guī)格說明是否可靠.進化型:目的不在于改進規(guī)格說明,而是將系統(tǒng)建造得易于變化,在改進原型的過程中,逐步將原型進化成最終系統(tǒng)。

在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，針對這個系統(tǒng)反復(fù)進行修改,形成比較好的思想,據(jù)此設(shè)計出較完整,準(zhǔn)確,一致,可靠的最終系統(tǒng).系統(tǒng)構(gòu)造完成后,原來的模型系統(tǒng)就被廢棄不用.探索型和實驗型屬于這種策略。

追加策略:先構(gòu)造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心,然后通過不斷地擴充修改,逐步追加新要求，發(fā)展成為最終系統(tǒng)。進化型屬于這種策略.五、總結(jié)

需求分析為軟件的開發(fā)起到了決策的作用，提供了開發(fā)的方向，并指明了開發(fā)的策略，在軟件開發(fā)及維護中均起到了舉足輕重的作用。大家一定要足夠重視需求分析，可以說在一個大型軟件系統(tǒng)的開發(fā)中,它的作用要遠(yuǎn)遠(yuǎn)大于程序設(shè)計。永遠(yuǎn)別忘了：需求分析和程序設(shè)計不盡相同，合理、可行是才是重要的。跳出程序設(shè)計的圈子，站在系統(tǒng)的角度上來看問題，你的結(jié)論會截然不同。

第五篇：需求分析

需求性分析

（網(wǎng)絡(luò)書店管理系統(tǒng)）

一、概述

隨著網(wǎng)絡(luò)通訊技術(shù)的發(fā)展，網(wǎng)上書店作為出版社一種全新的銷售手段，越來越受到人們的關(guān)注。它打破了傳統(tǒng)銷售模式在時間、空間上的限制，采用了先進的銷售手段和銷售方法，大大提高了經(jīng)濟效益和資源利用率，使商務(wù)活動上了一個新臺階。它可以使顧客足不出戶，就能通過網(wǎng)絡(luò)選購商品，并由相應(yīng)的網(wǎng)絡(luò)經(jīng)銷商送貨上門。本系統(tǒng)的好處就是不僅能讓消費者可以方便地得到所需商品，而且還能有效的減少銷售環(huán)節(jié)，從而最大限度地降低了商品的最終價格。本項目所用的操作系統(tǒng)是windows 7，開發(fā)系統(tǒng)是Visual Studio 2008，數(shù)據(jù)庫采用SQL Sever 2005。

三、數(shù)據(jù)字典

編號名稱類型說明

1書籍信息數(shù)據(jù)存儲書籍信息=書名+作者+年代+編號+采編人員

2會員信息數(shù)據(jù)存儲會員信息=姓名+性別+出生日期+住址+聯(lián)系電話

3圖書細(xì)目數(shù)據(jù)存儲圖書細(xì)目=編號+購買記錄