需求分析方法論

1. 需求管理的手段有哪些

本文梳理了什麼是做需求分析與需求管理，以及為什麼要做與如何去做。

01 概述

本文是梳理需求分析與需求管理方法-產品經理工作職責&工作核心技能之一，筆者寫本文的目的一是把自己的知識體系做個輸出，包含來自己的經驗總結和最近學習到的知識總結，其二順便分享。知識方法無定論，任何內容先看思路，實戰為主。

在分析一個問題時，可以用一個通用的框架方法論，WWH法：是什麼？為什麼？怎麼做？這樣可以把思路理清晰。因此引出了本文的主要內容：什麼是需求？為什麼要做需求分析？什麼時候做需求分析？怎麼做需求分析？

說明：時間有限，本文的案例不代表實戰解決方法案例，更為了快速說明和應用方法而舉例。

02 需求定義

1. 什麼是需求？

需是是用戶在某種場景下的未被滿足的期望。

為什麼要明確需求的定義，需求很容易被誤解，這里我們要區分下用戶需求和產品需求。

我們的產品在未被定義之前，我們研究的需求是用戶需求，我們通常也會叫作問題（沒有明確的解決方案），當我們定義產品時，我們就要把用戶需求轉化為產品需求，提供具體的可落地的解決發難，才能實現產品。

我要吃飯睡覺打豆豆，這不是需求，這種需求對於產品沒有任何價值。

看定義，用戶需求是用戶基於某種場景下的未被滿足的期望，在這里提煉出需求的基本結構：用戶+場景+期望。強調：需求不是獨立存在的，是依附於用戶+場景一起存在的。

用戶需求案例： 小明（用戶），每天早上起床後就要趕著去上班，沒有也不想在家吃早餐，但是到了公司就要工作，所以常常沒有早餐吃，又餓又不健康（場景），小明又想多睡會兒又想在上班前吃上早餐（期望）

2. 什麼是需求分析？

需求分析，就是挖掘和提煉用戶需求，解決用戶痛點問題，即找到用戶需求，並把用戶需求轉為產品需求（解決方案）的過程。

這里強調兩點：

找到用戶需求
解決用戶問題
案例： 還是小明吃早餐的案例，目前小明希望在上班前能吃上早餐這個是用戶需求，只找到用戶需求，沒有解決方案，等於0，我們還要幫小明解決問題。如，提供早餐外賣，小明可以提前在手機上預定早餐外賣，一起床就有早餐可以吃。這是一個較完整的產品需求。

03 為什麼要做需求分析

產品首先要滿足的就是用戶需求，為用戶產生價值，才能創造商業價值。滿足用戶需求是產生商業價值的本源。

04 在什麼階段做需求分析

需求分析貫穿在產品整個生命周期。

1. 產品概念期

這個階段做需求分析，更強調需求調研，目的是定位目標用戶群，做產品定位，市場研究並確認細分產品市場。提煉產品核心功能，解決目標用戶群痛點問題。 交付物：BRD需求文檔。（或類似的相關的文檔，如需求調研報告、市場調研報告等）

2. 產品設計開發期

這個階段的需求分析，目的是要設計一個可落地的解決用戶痛點，滿足用戶需求的產品。設計一個目標用戶可用好用的產品。深層次的挖掘和分析用戶，描述需求，解決問題。實現用戶如何通過一步步的使用產品滿足其需求。該階段交付物：產品原型+PRD操作文檔。

3. 上線後-成長期

上線後的需求分析，目的是驗證真實產品滿足真實用戶需求的結果，收集用戶需求，優化產品。

4. 成熟運營期

本階段需求分析，目的在為產品提供更好的運營方案，制定競爭策略。讓產品持續更好的更多的為企業創造商業價值。

5. 產品衰退期

當產品進入衰退期時，需求分析重在研究市場發展趨勢，以幫助決策是調整發展戰略。

05 需求分析方法

需求分析可以分為三大步： 明確問題–拆解需求–提供解決方案。

1. 明確問題

明確問題之前，我們首先要從各方搜集需求，然後經過分析，提出真正的需求。

需求獲取渠道

以下是我們常用的一手需求獲取渠道：

收集到的一手需求還不是真正的需求，要先進行一個清洗過程，把一些無用的無根據的站不住腳的異常的等等都過濾掉。具體過程不做介紹啦。

明確問題（提出要解決的問題）

這里一定要注意，提問題的標准：提出的問題要聚焦，明確、開放。不能泛，模糊。要又用戶、場景、問題。還要明確該需求帶來的價值。需求最終是要交換成價值的。

正確的問題VS錯誤的問題：

明確需求的價值：

2. 拆解問題（需求）

拆解需求指的是把已經明確的問題，從多個維度進行拆解，目的就是為了找到更合適的解決方案。 該方法是某課程老師總結的拆解方法，筆者認為非常好，非常清晰和明確的一個方法，這里直接引用。（該方法也是老師對《六頂思考帽》里的解決問題方法做的靈活應用，同時書也推薦給大家）

拆解問題的5個維度：

積極層面：通常可以拆解出怎麼做對用戶來講可以產生更積極的情感。
否定層面：通常可以拆解，即使不做什麼，依然可以產生好的結果。
轉移層面：轉移指的是不直接單獨解決當前用戶的問題，通過轉移法，用戶轉移、問題轉移等。
拆解：把當前問題刨根問底的拆，挖掘更多的可能性、找到問題本質。
腦洞：這個更多的靠靈感、經驗等進行頭腦風暴，補充其他維度考慮不到的地方。
案例： 問題：某視頻APP，用戶次日留存率低於30%，需要提高次日留存率 拆解過程如下圖：

注意在拆解問題的時候，不要去考慮能不能實現，先去拆解一切想到的問題，最後在分析解決方案的時候再來進一步篩選。

3. 提供解決方案

問題拆解完後，對所有提出的問題列出解決方案，這里注意，一開始思考解決方案的時候也不要去考慮實現的可行性，盡管去提供。等所有的解決方案都列出來之後，再進行方案分析、評估、排序。

06 需求管理

需求管理指的是如何安排已經明確產生的需求，工作中我們通常會遇到四面八方包括產品經理自己給的需求，但是資源和精力無法讓做到有求必應，我們需要去把需求做一個分類和排序，盡可能的去做性價比高的需求開發。 這里我們介紹幾種方法，幫助我們做需求分類和排序。

1. Kano 模型

KANO 模型是東京理工大學教授狩野紀昭（Noriaki Kano）發明的對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。

Kano模型把需求分為5類：

基本型需求

該類需求代表的用戶的核心痛點，是產品的必備功能，如果沒有該功能，用戶會極度不滿，甚至不用你的產品。但是如果有了該功能，用戶並不會對你的產品的滿意度增加。如微博的發布微博功能、社交APP的聊天功能、共享單車的開鎖功能等。

期望型需求

這類需求代表的是用戶的癢點，代表的是品質，對用戶來講是最好有的功能。好比我們的生活，我們都期望我的生活是有一定品質的。擁有此功能，用戶滿意度會明顯提升（過的還可以），沒有此功能，用戶滿意度會明顯下降，但是湊合可以用戶（過得下去）。這種需求一定要去努力挖掘和分析，並做好。代表了產品的競爭優勢。如社交軟體的語音聊天視頻功能。

興奮型需求

這類需求所在暗處，用戶自己都想不到的需求。擁有此功能，即便表現的並不完善或完美，用戶滿意度也顯著提升，但即便沒有此功能，用戶也並不會對產品對滿意度降低。如，在微信剛剛推出紅包功能的時候，這是一個非常典型的興奮型需求。

無差異型需求

該功能對用戶來講，是不痛不癢的需求。可用可不用，有或者沒有都不會影響用戶的滿意度。如，我們在設計某個按鈕，是20px，還是22px，是第一個還是第二個位置。無論怎麼做，對用戶並無明顯影響。我們就盡量不要去花精力在這上面，只需要執行任意一種即可。

反向型需求

該類需求提供對應的功能後，用戶會對產品的滿意度降低。該類需求，最好不做。如，前段時間上熱搜的一款監測學生上課是否集中注意力的智能科技「緊箍咒」，得到的是網友幾乎一邊倒的差評和抵制。

Kano模型實施方法：

如何評估需求屬於Kano模型中的哪一類需求，我們可以實施以下方法：

Kano模型問卷調研法 可以直接設計問卷調研，通過定量問卷調研得出需求屬於哪一種：

按照上表的格式，對每一個功能做一個的調研，充分收集用戶的數據並得出結果。

2. 時間管理四象限法

本方法可以快速幫助我們評估需求開發的時間優先順序。從緊急重要程度兩個維度比較合理的幫助產品有條理的安排開發秩序，避免盲目排序。

3. ICE排序法

ICE排序法也是一種比較嚴謹科學的需求排序方法，通過從幾個維度考慮給需求打分，以總分高低去排序。

I（Impact）：影響范圍
C（confidence）：對上線效果的自信程度評估
E（ease）：開發難易程度（工作量+技術難易程度）評估
應用實例：

本文由 @娟姐 原創發布於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議

2. 論文高手進：軟體開發需求分析的認識和理解

應用軟體開發中的需求分析及方法 軟體工程一般具有以下基本活動：軟體描述：軟體的功能以及軟體操作上的約束定義；軟體設計和實現：軟體要按照描述來設計；軟體有效性驗證：軟體要被確定是有效的，能完成預期的應用；軟體進化：軟體按應用需要的變更來進化。其中，軟體描述的目標是，確定軟體系統需要哪些服務以及開發和運行期間受到哪些約束，對服務和約束的發現、分析、建立文檔、驗證活動，現在常稱為需求工程。為此，筆者談談如何進行需求分析及方法。 一、 需求的過程 需求工程對於軟體過程是一個特別關鍵的階段，這個階段的錯誤將不可避免地帶到後續的系統設計和實現階段中。需求工程階段的獨特之處在於很少有現成模式或特製的文檔可供參考。後續階段可以建立在前期所做工作基礎上（各種相關模型至少在一定程度上可以衍生導出），而需求工程階段的成果卻是靠創建而來的。 需求工程本身就是一個過程，這個過程將產生用以描述系統的需求文檔。通常需求在這個文檔中被分成兩個層次描述：最終用戶需要高層次的需求描述；而系統開發人員需要比較詳細的系統描述。 （一）需求過程的四個主要階段 1、可行性研究：指明現有的軟體、硬體技術能否實現用戶對新系統的要求。從業務角度來決定系統開發是否劃算以及在預算范圍內能否開發出來。可行性研究是初步的，結果就是要得出結論，該系統是否值得進行更細致的分析。 2、需求的導出和分析：這是一個通過對現有系統分析、與潛在用戶討論、進行任務分析等導出系統需求的過程。也可能需要開發一個或多個不同的系統模型和原型。這些都會幫助分析員了解所要描述的系統。 3、需求描述：需求描述就是把在分析活動中收集的信息以文檔的形式確定下來。在這個文檔中有兩類需求。用戶需求是從最終用戶對系統需求的抽象描述；系統需求是對系統要提供的功能的詳盡描述。 4、需求有效性驗證：這個活動檢查需求實現、一致和完備。在這個過程中，可發現需求文檔中的錯誤，並加以修正。 當然，需求過程中的各項活動並不是嚴格按順序進行的。在定義和描述期間，需求分析繼續進行，這樣在整個需求工程過程中不斷有新的需求出現。因此，分析、定義和描述是交替進行的。 （二）需求的進一步認識 1、軟體系統需求 常常分為功能需求、非功能需求和領域需求。 功能需求：包括對系統應該提供的服務、如何對輸入做出反應以及系統在特定條件下的行為的描述。在某些情況下，功能需求可能還需要明確申明系統不應該做什麼。理論上，系統的功能需求描述應該既全面又具有一致性。全面意味著用戶所需的所有服務都應該給出描述。一致性意味著需求描述不能前後矛盾。在實際過程中，對大型而又復雜的系統而言，要做到需求描述既全面又一致幾乎是不可能的。一方面是因為系統固有的復雜性，另一方面是因為觀點不同，需求也會發生矛盾。 非功能需求：對系統提供的服務或功能給出的約束。包括時間約束、開發過程約束、標准等。非功能需求源於用戶的限制，包括預算上的約束、機構政策、與其他軟硬體系統間的相互操作，還包括如安全規章、隱私權利保護等外部因素。 領域需求：這是來自系統的應用程序領域的需求，反映了該領域的特點。他們也可能是功能需求或非功能需求。 2、軟體需求文檔 也稱軟體需求描述（SRS），是對系統開發者要求的正式陳述。IEEE標准為需求文檔提出了以下結構：引言（目的、范圍、縮略詞等），一般描述（產品透視、功能、用戶特徵、約束等），專門需求（功能、非功能、介面），附錄，索引。 二、方法 （一）問題域（應用領域） 是指問題所存在的現實世界中的那個部分。問題域是需求分析員所要研究的首要對象。例如，對一個電梯控制系統來說，它將包含任何現存的硬體（電梯、指示器、感測器、按鈕等）、建築物特徵（樓層和電梯井的數目）、預期的使用模式、用戶特徵、使用約束（如限制短途搭乘）等等。在這個問題域內，問題可以確定為「讓電梯在建築物中更有效使用的控制系統」。為了解決問題，『解系統』顯然有必要在問題域內產生某些效果，構成軟體需求的正是這些想要獲得的效果，也就是為何做軟體需求的原因和目的。 到現在為止，我們得到初步論點。在構建一個新軟體系統之前，最好先決定它應當能夠做些什麼又不要做些什麼；從問題域的研究入手，獲得問題的描述，以及新的解系統在其中將產生效果的陳述（即需求）；確定新系統所需的行為，以便讓它在問題域內產生所需要的效果。 （二）需求分析 通過對問題域的研究，獲得對該領域特性及存在於其中（需要解決）的問題特性的透徹理解並用文檔說明。需求分析旨在揭示一個現有的系統（問題域）的結構，而內部設計則是要創建出一個尚未存在的軟體系統（解系統）的結構。對於這一重要任務其特性如下： 分析關注問題域及對其建立的模型，而不是解系統； 主要目標是要獲得對問題域及存在於其中的問題本質的理解； 分析在本質上先於解系統行為的規格說明（盡管有重疊和反復的過程）。 （三）方法論 方法不只是一種技術，它是解決任務的一種途徑，並且通常由一組技術組成。任何分析方法，要使它得到很好的利用，都應當要求並且做到便於描述以下幾個方面： 問題域的結構，根據其子域及其相互間的關系； 問題域數據，語法和語義方面 問題子域的內在屬性和行為； 問題域中的重要事件及現象； 需求，解系統在問題域中應產生的效果。 具體有以下三個方法： 1、結構化分析（SA） 結構化分析（SA）是一種具有相當長歷史的分析方法，其演化的方式既微妙又顯得很重要。如同結構化編程一樣，它致力於系統范圍內的事物處理，數據流以及存儲數據結構的建模。建模主要包括數據流模型（DFD），數據字典（DD），實體關系圖（ERD）。 結構化分析所用的原型，無論是對開發者還是客戶都顯得直觀易懂，若將初始重點放在對原有系統的建模是對實現理解問題域這一基本的分析目標的有力支持。 結構化分析方法和人們的思維方式很相似，注重的是事物的過程和方面。利用結構化分析很容易去理解一個剛剛接觸的問題域，適合對比較生疏領域做軟體需求。 2、 面向對象分析（OOA） 面向對象方法最初只是一種系統的結構進行建模的方式，後來擴展到了內部設計，如今也已經開始廣泛應用於分析階段。面向對象分析基本思想是：如果把對象類的建模限定在需求問題域，那麼面向對象的基本原理、模型以及表示法均可以用於分析。 OOA（面向對象分析）算不上一種真正的需求方法，OOA的起點是一份原有的需求文檔，或者甚至是一份行為規格說明，並且OOA隱含的假設問題域分析已經完成，即分析員已經了解了所要研究的事物。OOA的真正本質意義是作為解系統的高層體系結構的設計，並且有利於系統的下一步開發設計（如果是OOD開發的話）。 OOA的大致方法是：標識出問題域中的對象類；定義這些類的屬性和方法；定義這些類的行為；對這些類間的關系建模。 3、 面向問題域分析（PDOA） 面向問題域的分析（PDOA）是一種新技術。PDOA更多的強調描述，而較少的強調建模。描述大致劃分為兩個部分：一部分關注於問題域，而另一部分關注於解系統的待求行為。一般建議同時有兩個單獨文檔：第一文檔含有對問題域相關部分的描述以及一個需求在該域中求解的問題列表（即需求）；第二文檔（規格說明書）包含的是對解系統的待求行為的描述以解決需求。其中第一文檔才是通過做分析產生的；第二文檔推遲到後續的規格說明任務中。 PDOA整個方法過程的基本步驟： 搜集基本的信息並開發問題框架（一種模型），以建立問題域的類型 在問題框架類型的指導下，進一步搜集詳細信息並給出一個問題域相關的特性描述 基於以上兩點，收集並用文檔說明新系統的需求問題框架。問題框架是將問題域建模成一系列互相關聯的子域。一個子域可以是那些可能算是精選出來的問題域的任一部分。問題框架的目標就是大量地捕獲更多有關問題域的信息。基於不同問題子域的本質及存在於問題子域間的關系，可以把問題框架分類為： 工件系統——系統必須完成針對只存在於系統中的這些對象的直接操作。 控制系統——系統控制部分問題域的行為，包括待求行為框架和受控行為框架。 信息系統——系統將提供有關的問題域的信息，包括信息是自動提供的和信息只在響應具體的請求時提供。 轉換系統——系統必須將某種特定格式的輸入數據轉換成相應的、另一種特定格式的輸出。 連接系統——系統必須維持那些相互沒有直接連接的子域間的通信。 問題框架法在應用時，建議採用直截了當的策略： 抽象問題域：標識子域；標識子域間的交互；刻畫每個子域的特徵；生成一個上下文圖識別出相關的標准框架；調整框架，盡可能使之適用於問題；使用關於相關框架的內容技術表來指導進一步的分析與文檔編制任務。 問題域的描述與必須滿足的需求二者之間有著明顯的區別，對新的解系統的行為創建與定義應單獨處理並且推遲到下一步的規格說明階段。 4、方法的對比 結構化分析（SA）及其相應的派生方法，曾一度風行了許多年。它最初的版本主要是圍繞對數據流以及問題域的數據結構進行建模，而現代的SA則直接將重點放在開發解系統的模型。描述問題域的SA可以算是想當不錯的，所產生的功效可見一斑。然而，它對其他方面的支持卻不夠完善，在處理一些其他類型問題時顯得有些笨拙。 面向對象分析（OOA）是當今主流的方法。OOA要求所有的系統均可以按照對象的特點來建模。它也繼承了很多結構化分析的思想體系。OOA不能對問題域有個清楚的了解，因而它的起點若是有一份原需求文檔，便可大大簡化問題域的分析。OOA並不區分問題域描述與解系統描述之間的差異，而是直接交付出新的解系統的高層設計。 SA和OOA還有幾點相同特性：主要模型是結構模型；通常焦點集中在對解系統的建模上；兩中方法都較少地應用於需求獲取領域；分析與內部設計之間沒有明顯差異。 面向問題域分析（PDOA）被認為是一種較為理想的方法。PDOA特點是重新將重點定位在問題域及需求上，通過對問題域的分類，向分析人員提供具體問題的相關指南。並且它將規格說明作為另行的任務處理，它的成果只是一份問題域的全面描述和一份需求列表而已。PDOA豐富和完善了現今的「分析」方法，然而人們對它的了解和掌握還有一定距離。 因地制宜的應用三種方法，不僅能夠如實的認識問題域，創建出健全的解系統，還能夠向用戶和設計人員都提供滿意的需求文檔。 三、 總結 在做軟體需求的時候，我們完全沒必要去限定要用或將要使用何種方法。我們的目的在於分析軟體的需求，通常情況是都用到了所介紹的三種方法。首先我們用面向問題域的方法把問題分成幾個部分。接下來用面向結構或面向對象的方法對各個部分進行逐步分析細化。在逐步分析過程運用各種建模技術對問題各部分建立合適的模型來細化需求。隨著需求的進一步進行，我們越來越清晰的認識了軟體系統的需求。 雖然應用方法使我們能夠清楚地去了解軟體需求，但是，大部分的需求文檔和規格說明書都是以文本的形式記錄的，因此，如何去表達我們所了解的需求也是很值得注意的。

3. 企業在制定培訓計劃之前為什麼要進行培訓需求分析,如何進行需求分析

這樣的問題最好不要問，就像問 人為什麼要吃飯，該如何吃飯一樣~不如問該如何做到需求分析和老師課程的直線對接，就好像你問吃點什麼可以保持苗條身材一個道理。真想了解可以加QQ：把三四五三三四期六 資深心理實戰培訓師王家輝老師的助理

4. 什麼叫調查方法論

一、何謂調查

調查系指有系統性地針對某類事物進行觀察及測量，其目的無非是希望藉由簡單且標準的程序，而對整體結構有初步的了解。當我們對於一件事情無法由表面看出整體的時候，通常就會藉由調查來進行了解。而調查的項目無奇不有，例如：大家早餐吃什麼？晚上幾點睡覺？某項產品的銷售量好不好？哪個候選人的支持度高？某項政策民眾支持否？那個人是誰殺的？小至個人的生活瑣事需要問卷調查，大至國家的問題都還要成立調查局來專門做調查，幾乎所有的問題都需要調查。更何況復雜的生態問題，需要更嚴謹的科學調查方法。

以生物資源調查為例，我們想要知道某地區有哪些生物？這些生物隨著季節的消長？哪些生物近年來逐漸減少？種種的問題都必需經過一連串的調查來獲得結果，隨著目的的不同，就必須選用適當的調查方法。通常整個調查過程中，幾乎不只調查一次而已，所以為了使得每次的調查結果都能夠進行比較，研究者必須選定一標準的調查方式，從一而終的採用相同方法，並且具體的描述方法過程，以便後人能夠依循此法進行重復。

因此，任何調查活動都必須注意到：(1)對象、目的為何；(2)選用方法標准否；(3)結果是否具有代表性。在此，我們的調查活動不外乎是：了解某地區的某類生物組成。所以，我們必須知道調查范圍的大小，是要進行整個區域的搜查，還是針對特定區域的抽查；其次，決定調查的對象，而慎選使用的調查方法；最後，再將所調查的資料加以分析，然後討論此結果是否能解答先前的問題。

二、取樣方法

一般調查過程鮮少採用全時全區的地毯式搜索，因為這樣的過程耗時耗力，且相當沒有效率，所以多選取特定時段（調查頻度）、特定地點（調查樣區）及特定方法（取樣方法），藉由系統性的標准方法，研究者才能將每次調查的結果進行比較。由於調查方法眾多，僅介紹一些常用的方法，研究者需明確知道自己的研究目的，慎選調查方法，以免進行結果分析時，才發現一切白做工。

˙調查頻度

就是每次調查之間隔，如：每天、每周、每月、每季或每年，依據不同研究目的，需慎選不同調查頻度。

若想要針對短期的特殊行為，進行密集的觀察，如求偶、產卵、覓食、競爭等行為，則需安排較密集的觀察頻度，必要時得每天觀察，但不用太多天。若想要知道某物種在繁殖季的數量變化，或者針對某短期干擾的影響，則每周進行一次觀察即可，通常維持數月即可。如想要了解該生物的年活動周期，或者該地點的生物組成，則建議每月觀察一次，連續觀察一年。倘若調查范圍大、樣區多，或者僅想要有各概略性的了解，則每季調查一次，最少調查一年，亦可連續調查數年。如果要了解某物種近年來的數量變化，或者針對一大區域內各地的相對數量調查（如：於同一時段於全國各地同時進行蛙類普查），則一年一次即可，但這種調查至少要進行好幾年，甚至成為百年的傳統。

此外，研究者已可針對特殊需求而自訂頻度，如：每月兩次、每陰歷月一次、夏冬季各一次、乾濕季各一次、特殊氣象前後各一次（台風、豪雨、乾旱、寒流）、人為干擾前後各一次...等。

當然，除了目的導向外，人力安排也很重要。研究者需考量團隊的時間，確保在整個調查期間內都能如期進行，避免虎頭蛇尾。另外也需注意，避免過高的調查頻度造成生物的干擾，別讓研究者的美意成為生物的負擔。

˙調查樣區

調查的區域固然越大越好，這樣才能盡量包含所有的狀況。不過，樣區的規劃就像調查頻度一樣，太少—不具有代表性；太多—浪費資源，勞心勞力。所以，樣區的選擇一樣要考慮到研究目的，以及調查人力資源，透過適當的樣區選擇，才能達到兩全其美。

一般來說，樣區的規劃需要注意到每個樣區大小、數量以及代表性。樣區的數量與大小比較相關，主要系考量調查所需之人力時間。很多個小樣區—會浪費許多交通時間；很少個大樣區—不易進行不同棲地類型之比較。另外考量的因素就是樣區代表性，若規劃許多樣區卻無法涵蓋整體區域的各棲地類型，那似乎不具有完整性。所以，一般在進行樣區規劃前，會先將全區內的各棲地類型逐一列出，如：森林、溪流、池塘、耕地、果園、建築物...，再依此規劃樣區地點與數量，若各棲地類型能有重復為佳，最後在考量人力與調查頻度，規劃適當的樣區大小數量。期望以最少的調查量，獲得最大的代表性。

˙取樣方法

因為兩棲類的習性多樣化，為因應不同研究目的，遂發展出許多調查取樣的方式，以下就幾種常見的取樣法進行介紹，並比較各法之優劣。當然取樣法只是概念，各法之間並不相互排斥，選定適合的數種方法來進行，方能契合研究之目的。

1. 徹底資源清查法（Complete species inventories）：
本法主要針對一特定樣區，進行地毯式搜索，將樣區內所有可能的種類與數量全數調查出來；其間，調查時間密集、調查人力眾多，能徹底有效地了解該樣區之蛙類組成。對研究者來說，若能獲得此詳細資料當然是最好的，但有時考量研究目的、調查人力與時間，以及徹底資源調查法過程中對生物造成的干擾，是否需要花費如此多的資源來獲取此資料，倘若僅需要「相對數量」即可達到原先設定的研究目的時，研究者大可不用費力地採用此法，而選擇後續諸法來進行。

2. 目視遇測法（Visual encounter surveys）：
此法系指研究人員在一特地時間內，有系統地走過一特定路線或區域，將眼睛所看到的所有種類與數量記錄下來。此法廣泛應用於蛙類的調查與監測，可獲得族群的相對數量。但有些時候僅看到某蛙逃離的一瞬間，而無法進行辨識，此時寧可不紀錄此資料，也不要誤判種類；但如果調查數量為零或甚少，則補紀錄「未確認種，一隻」。

3. 鳴叫計數法（Audio strip transects）：
本法遂利用蛙類獨特的求偶鳴叫行為，在特定穿越線中將兩側所聽到的種類數量記錄下來。用以了解物種組成、估算雄性成蛙的相對數量，進而估計族群相對數量；亦可針對繁殖行為與棲地或天氣之關系。但本法受限於調查人員對鳴叫聲音之辨識、聽力與辨析數量的能力；再加上各物種繁殖季節不同，且鳴叫的音頻與音量差異甚大，例如：相距100m處有兩蛙同時鳴叫，其中一蛙鳴叫大聲而聽得到；另一蛙卻鳴叫小聲而聽不到，這樣情況下則會低估後者的數量。所以，一般調查鮮少單獨使用此法，多與其他方法配合。

方塊取樣法（隨機挑選調查區塊）

穿越線取樣法（A.橫越馬路、B.沿著溪流、C.特定方向）

4. 方塊取樣法（Quadrat sampling）：
將欲調查之均質區域以特定距離劃設網格，將各方塊給予一編號，再隨機挑選數個方塊，並仔細調查各方塊內之生物組成。可獲得物種名錄、相對豐度、密度。而劃設方格的大小與選取的數量則需考量調查人力與統計的可信度來判定。此法可免除人為挑選樣區時的誤差；但有些選取的方塊並不易到達，而增加調查的困難度。

5. 穿越線取樣法（Transect sampling）：
本法系指樣區或調查路線為線型，而樣區類型主要有二類：其一，通過連續漸變的環境，例如為調查不同海拔的蛙類分布，則選取一條由低至高海拔之穿越線為樣區，於穿越線中選取部分片段進行調查，通常適用較大尺度之調查。其二，通過均值或類似之環境，選取多條穿越線，每一條穿越線為一樣區，通常適用於小尺度的調查。

6. 叢塊取樣法（Patch sampling）：
許多生物通常會有特別偏好某種微棲地或群體聚集的行為，所以我們常常會在這類地方觀察到較多之個體，例如：倒木、石塊、蓄水池...。本法就是以這些高密度的棲地為單位（即一個樣區，稱為一個叢塊），當調查叢塊數量達到一定程度後，便可進行統計分析，通常適用於「微棲地利用」之研究。

掉落式陷阱配置圖

掉落式陷阱近觀圖

7. 陷阱法（Pitfall traps）：

陷阱法主要藉由目標生物的生態習性，並利用相關的設施來圈捕。在誘捕因素方面主要分為「主動誘捕」以及「被動捕捉」兩大類。前者多利用食物或激素來作為引誘的物質，將標的生物引入陷阱中；後者則沒有誘餌，多利用繁殖與活動習性，在該生物的移動路徑中作攔截。
至於陷阱本身則分為致死與非致死的裝置，前者系為了某必要之研究因素，利用酒精、福馬林或其他固定溶液來將掉入陷阱的生物予以固定；後者則僅作暫時的禁錮，不會犧牲該生物之生命，所以此法在設置期間必須定時巡邏，以免遭捕獲的生物餓死或被捕食。
一般常用的底棲蛙類（赤蛙、蟾蜍）陷阱法為「掉落式陷阱」，並同時配合圍籬的設置，來增加捕捉的面積。陷阱本身主要系將塑膠水桶埋設於樣區地下，桶高至少30㎝，桶口與地面同高，桶底鑽小孔以利排水，免得下雨盛水造成捕獲生物淹死或逃脫；亦可於桶上方加設蓋子，防止雨水或樹枝掉落至桶中；桶內可放置水果吸引昆蟲來作為誘餌，增加捕獲的機會。
圍籬的用處主要是藉由生物活動時，在接觸阻隔物之後，經常沿著阻隔物邊緣移動的特性，將生物誘導入陷阱當中。掉落式陷阱法的設置期間至少要連續3～7天，並且1～ 2天巡邏一次。非調查期間，可將蓋子將陷阱緊密蓋住，待下次調查期間再將陷阱打開，直至調查研究完全結束後，將所有裝置移除，並將空洞填補回去。樣區的選擇可采隨機選取的方式，或者設置於蛙類遷徙的路徑中，如：繁殖場所與非繁殖場所間、溪流池塘的周圍。

5. 計算機方法論中最基本的三個概念是

是學科形態，核心概念，學科方法。

1、學科形態：抽象，理論，設計。

2、核心概念：

⑴綁定Binding，

⑵大問題的復雜性Complexing of Large Problems，

⑶概念和形式模型Concentual and Format Models，

⑷一般性和完備性Consistency and Completeness，

⑸效率Efficiency，

⑹演化Evolution，

⑺抽象層次Levels of Abstraction，

⑻按空間排序Ordering in Space，

⑼按時間排序Ordering in Time，

⑽重用Reuse，

⑾安全性Security，

⑿折衷和結論Tradeoff and Consequences。

3、學科方法：相關的數學方法與系統科學方法。如遞歸，系統論，資訊理論等。

(5)需求分析方法論擴展閱讀：

1、抽象形態包括以下4個步驟的內容。

① 形成假設。

② 建造模型並坐車預測。

③ 設計實驗並收集數據。

④ 對結構進行分析。

2、理論形態包括下面4個步驟的內容。

① 表述研究對象的特徵（定義和公理）。

② 假設對象之間的基本性質和對象之間可能存在的關系（定理）。

③ 確定這些關系是否為真（證明）。

④ 結論。

3、設計形態包括以下4個步驟的內容。

① 需求分析。

② 建立規格說明。

③ 設計並實現該系統。

④ 對系統進行測試和分析。

6. 軟體需求分析4個步驟

一、需求分析理論

軟體需求涉及功能性問題非常廣，我們用抽象化理論分析，可以劃分各個功能域，用不同的數字代替，軟體——S，功能域——A1、A2……An

S＝{A1、A2、……An}

但是功能域B又存在若干問題P1、P2……Pm組成，並且每個功能對應於子系統中的一個軟構件，可以表示為-B＝{P1、P2、……Pm}

功能G有若干個行為F1、F2、……Fj，每個行為對應於軟體構件中的實現方法

G＝{F1、F2……Fj}

一個軟體包含了所有功能的集合，同時包含了實現所以功能的所有方法和演算法描述。需求分析是依據用戶動機，經過需求問題識別，進行分析、消除分馳和綜合，編寫用戶故事，評審；形成用戶需求與設計同步，設計滿足用戶需求目標。

需求開發方法貫穿這個產品生命周期，利用不同的開發方法論進行挖掘需求，幫助用戶找到問題，梳理問題，判斷產品實現功能的正確性、一致性和完整性，促使用戶在軟體設計啟動之前進行周密的、全面的思考軟體產品功能，用商業化行為解決需求與現實中存在的矛盾，解決用戶需求與商業化產品功能融合，解決規范和個性化需求。
二、軟體需求開發的目標

1、對實現的軟體做一個全面的描述，幫助用戶找到問題矛盾解決用戶場景痛點，幫助用戶在進行產品規劃時做到周密，全面產品定位需求

2、了解和描述軟體實現所需的全部信息，為產品設計、確認和驗證提供一個基準

3、為軟體產品管理人員進行軟體產品成本評估和編輯軟體開發計劃書提供保障

需求開發-軟體功能需求、軟硬介面、非功能性需求、設計約束、反向需求、閱讀支持信息。

軟體需求分析盡量提供軟體實現功能需求的全部信息，使軟體設計人員和測試人員不在需要和需求方進行接觸，保證需求分析的一致性和完整性。

三、軟體功能需求

描述軟體功能實現注意——

1、功能需求的完整性和一致性

2、功能描述的無異議和可追蹤

3、功能描述清洗和功能可測試

四、軟硬介面

1、人機介面

2、硬體介面

3、軟體介面

4、通訊介面
五、非功能性需求

1、運行環境

2、時間需求

3、處理容限、精度、異常處理機制等

4、可靠性要求、可維護性、安全性

7. 如何進行需求分析

項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。 在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不幹擾承建方的自主權為主，除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足。 為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業務流程不合理，用戶不習慣或不願意去用承建方的軟體。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發范圍上有發言權。 需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再了解細節的問題。 一個應用軟體系統（記為S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應於一個軟體子系統。 S={D1，D2，D3，…Dn} 問題域Di由若干個問題（記為P）組成，每個問題對應於子系統中的一個軟構件。 Di={P1，P2，P3，…Pm} 問題Pj有若干個行為（或功能，記為F），每個行為對應於軟構件中的實現介面。 Pj={F1，F2，F3，…Fk} 需求說明書應該對於那些只想了解宏觀需求的領導，和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題： 1.最好為每個需求注釋「為什麼」，這樣可讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。 2.需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。 重點監控需求分析 由於項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟體需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。 客戶說不清楚需求 有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網路建設時，客戶方的辦公人員大多不清楚計算機網路有什麼用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟體系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。 需求自身經常變動 根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業務水平的提高，他們會在不同的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟體的需求改動少於三次的！所以必須接受「需求會變動」這個事實，在進行需求分析時要懂得防患於未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建築在穩定的需求上，同時留出變更空間。咨詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的准備中來，以便協助客戶方和承建方來界定「做什麼」、「不做什麼」的系統功能界限。 分析人員或客戶理解有誤 軟體系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裡能射出強光……有趣的是，車里住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」所以分析人員知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業務了解程度和注重溝通技巧。 需求分析方法論 根據以往的工程經驗，需求分析工作方法，應該定位在「三個階段」（也稱「三步法」）。 第一階段：「訪談式」（Visitation） 這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的介面人。 實現手段：訪談、調查表格 輸出成果：調查報告、業務流程報告 第二階段：「誘導式」（Incement） 這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬體、軟體實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶採用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、准確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、准確性等等問題，及時地提出改進意見和方法。 實現手段：拜訪（誘導）、原型演示 輸出成果：調研分析報告、原型反饋報告、業務流程報告 第三階段：「確認式」（Afirm） 這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，並能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文檔簽字確認。 實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統 輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔） 整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。

8. 需求分析,系統分析應該看什麼書

瀑布模型：需求調研--調研報告--需求分析--概要設計--差異化分析--詳細設計（介面規范、資料庫設計）--系統開發--單元測試--聯合測試--SIT--UAT--上線；
根據如上的軟體工程方法論，不同的項目有不同的文檔和過程方法，所以需求分析，我覺的沒有固定的模式，也沒有固定的某類教材，具體項目具體分析！
非要看書的話，可以看看軟體過程！

9. 陪訓需求分析報告包括什麼

1．需求分析實施的背景，即產生培訓需求的原因或培訓動議。 3．概述需求分析實施的方法和過程。說明分析方法和實施過程可使培訓組織者對整個評估活動有一個大概的了解，從而為培訓組織者對分析結論的判斷提供一個依據。 4．闡明分析結果。結果部分與方法論部分是密切相關的，撰寫者必須保證兩者之間的因果關系，不能出現牽強附會的現象。 6．附錄。包括收集和分析資料用的圖表、問卷、部分原始資料等。加附錄的目的是讓別人可以鑒定研究者收集和分析資料的方法是否科學，結論是否合理。 7．報告提要。提要是對報告要點的概括，是為了幫助讀者迅速掌握報告要點而寫的，要求簡明扼要。有的評估報告根據需要也可以把提要置於評估報告的開頭。 撰寫評估報告時，在內容上要注意主次有別，詳略得當，構成有機聯系的整體。為此，在撰寫前應當認真草擬寫作提綱，按照一定的主題及順序安排內容。

10. 軟體系統分析與設計的目錄

第1章系統計劃
1.1系統項目的提出與選擇
1.1.1系統項目的立項目標和動機
1.1.2各種項目立項的價值判斷
1.1.3系統項目的選擇和確定
1.1.4系統項目提出和選擇的結果
1.2可行性研究與效益分析
1.2.1可行性研究的意義
1.2.2可行性研究的內容
1.2.3效益分析
1.2.4可行性分析報告的標准
1.3定義問題與歸結模型
1.3.1定義問題和歸結模型的意義
1.3.2定義問題和歸結模型的方法論模型
1.3.3定義問題和歸結模型的步驟
1.3.4定義問題和歸結模型的若干手段
1.4系統方案的制定、評價和改進
1.5新舊系統的分析和比較
1.5.1新舊系統比較的目的
1.5.2新舊系統比較的原則和方式
1.6所需資源的估汁
1.6.1資源評估的意義
1.6.2描述資源
1.6.3項目實施所需要的可能資源
1.7現有軟體、硬體和數據資源的有效利用
1.7.1意義
1.7.2手段
1.8流行的系統分析方法論
第2章需求分析與定義
2.1軟體需求與需求過程
2.1.1什麼是軟體需求
2.1.2需求工程
2.2需求調查與問題定義
2.3可行性研究
2.4現有系統的分析
2.5需求分析
2.5.1需求分析的工作任務
2.5.2需求建模
2.6確認測試計劃
2.7流行的需求分析方法論
2.7.1結構化分析
2.7.2面向對象分析
2.7.3面向問題域的分析
主要參考文獻
第3章系統設計
3.1概論
3.2處理流程設計(工作流設計)
3.3系統人機界面設計
3.4系統的文件設計
3.5資料庫管理系統的選擇和資料庫設計
3.5.1數據組織的分類
3.5.2資料庫選擇實例
3.6網路環境下的計算機應用系統的設計
3.7簡單分布式計算機應用系統的設計
3.8系統運行環境的集成與設計
3.9系統過渡計劃
主要參考文獻
第4章軟體設計
4.1軟體設計基本原則
4.1.1信息隱蔽
4.1.2模塊獨立性
主要參考文獻
4.2結構化設計方法
4.3面向對象設計
4.3.1面向對象的概念
4.3.2面向對象分析方法
4.3.3面向對象設計
4.4用戶界面設計
4.5設計評審
主要參考文獻
第5章軟體測試
5.1軟體測試的定義和目的
5.2測試用例設計
5.2.1黑盒測試
5.2.2白盒測試
5.2.3邏輯覆蓋
5.3軟體測試的策略
5.3.1單元測試
5.3.2集成測試
5.3.3確認測試
5.3.4系統測試
5.3.5測試和測試
5.4軟體測試種類
5.5軟體測試自動化工具
5.5.1軟體測試自動化概述
5.5.2白盒測試工具——NuMegaDevPartnerStudio
5.5.3黑盒測試工具——QACenter
5.6面向對象的軟體測試
5.6.1面向對象分析的測試
5.6.2面向對象設計的測試
5.6.3面向對象編程的測試
5.6.4面向對象的單元測試
5.6.5面向對象的集成測試
5.6.6面向對象的系統測試
主要參考文獻
第6章軟體維護
6.1軟體的可維護性
6.2軟體維護的分類
6.3軟體維護的工作量
6.4軟體維護作業的實施和管理
6.5預防性維護
6.6軟體再生工程
主要參考文獻
第7章系統的可靠性分析與設計
7.1可靠性概述
7.2系統的故障模型和可靠性模型
7.2.1系統的故障模型
7.2.2系統的可靠性模型
7.3系統的可靠性分析和可靠度計算
7.3.1組合模型
7.3.2馬爾柯夫模型
7.4提高系統可靠性的措施
主要參考文獻
第8章系統的安全性和保密性設計
8.1信息安全內容
8.1.1信息安全概念的發展
8.1.2信息安全研究的目標
8.1.3信息安全的常用技術
8.2訪問控制技術
8.2.1訪問控制的實現方法
8.2.2訪問控制策略
8.2.3Bell-Lapala模型
8.3數據機密性
8.3.1對稱密鑰加密與AES
8.3.2非對稱密鑰加密與RSA
8.3.3門限密碼學
8.3.4PKI
8.4數據完整性
8.4.1Biba完整性模型
8.4.2雜湊函數與消息摘要
8.5通信與網路的安全性
8.5.1網路環境下危及安全的因素
8.5.2網路安全層次模型
8.5.3通信與網路的信息安全技術
8.5.4防火牆技術
8.6系統安全管理與安全工程
8.6.1安全管理的必要性
8.6.2系統安全管理
8.6.3系統安全工程
主要參考文獻
第9章文檔編制
9.1軟體文檔
9.1.1文檔的作用
9.1.2文檔的分類
9.1.3文檔編制的要求
9.1.4文檔標准
9.1.5文檔的管理與分發
9.2可行性研究報告
9.2.1可行性研究報告的作用
9.2.2可行性研究報告編寫指南
9.2.3其他相關說明
9.3項目開發計劃
9.3.1項目開發計劃的作用
9.3.2項目開發計劃編寫指南
9.3.3其他相關說明
9.4需求規格說明書
9.4.1需求規格說明書的作用
9.4.2需求規格說明書編寫指南
9.4.3其他相關說明
9.5數據要求規格說明書
9.5.1數據要求規格說明書的作用
9.5.2數據要求規格說明書編寫指南
9.5.3相關技術
9.6用戶手冊
9.6.1用戶手冊的作用
9.6.2用戶手冊編寫指南
9.6.3其他相關說明
9.7操作手冊
9.7.1操作手冊的作用
9.7.2操作手冊編寫指南
9.7.3其他相關說明
9.8測試計劃、測試分析報告
9.8.1測試計劃與測試分析報告的作用
9.8.2測試計劃編制指南
9.8.3測試分析報告編制指南
9.8.4其他相關說明
9.9技術報告
9.9.1技術報告的作用
9.9.2技術報告編制指南
9.9.3其他相關說明
9.10開發進度記錄
9.10.1開發進度記錄的作用
9.10.2開發進度記錄編制指南
9.10.3其他相關說明
9.11項目開發總結報告
9.11.1項目開發總結報告的作用
9.11.2項目開發總結報告編制指南
9.11.3其他相關說明
主要參考文獻
第10章項目管理
10.1項目及項目管理的基本概念
10.1.1項目
10.1.2項目管理
10.2項目計劃
10.3進度管理
10.4人員管理
10.5費用管理
10.5.1費用計劃
10.5.2費用控制
10.6軟硬體和數據資源的計劃與管理
10.7項目環境管理
10.8與用戶的協作
10.9標准化管理
10.10配置管理
10.11項目管理工具
10.12項目信息管理
10.13項目風險管理
10.14項目管理體制
10.14.1美國UCC公司項目管理體制
10.14.2IBM集成產品開發(IPD)體系
主要參考文獻
第11章軟體質量管理
11.1軟體質量概述
11.2軟體質量保證體系
11.2.1軟體質量保證活動
11.2.2軟體質量保證計劃
11.2.3軟體質量保證的實施
11.3軟體質量保證標准
11.3.1標準的層次
11.3.2國家標准
11.3.3ISO標准
11.3.4CMM
11.3.5CMMI
11.4全面質量管理
11.4.1全面質量管理簡介
11.4.2全面質量管理的實施
11.5六西格瑪管理
11.5.1六西格瑪管理的概念
11.5.2六西格瑪管理的理念
主要參考文獻
第12章實時系統分析與設計
12.1實時系統分析與設計方法
12.1.1有限狀態機
12.1.2Petri網
12.2實時系統內核的設計
12.2.1實時系統調度演算法
12.2.2實時任務管理和調度
12.2.3定時器和中斷管理
12.2.4存儲器管理
12.2.5I/O與文件系統
12.2.6網路通信
12.3實時系統分析與設計實例分析
12.3.1測控設備控制計算機實時系統分析與設計
12.3.2WindowsNT與Multibus系統實時串列通信軟體的設
12.3.3全數字模擬計算機實時系統應用
主要參考文獻
第13章嵌入式系統分析與設計
13.1嵌人式系統概述
13.1.1嵌入式系統的應用領域
13.1.2典型的嵌入式系統結構
13.1.3嵌入方式
13.2嵌人式系統開發的特點和要求
13.3嵌入式系統開發流程
13.4嵌人式系統開發的硬、軟體資源
主要參考文獻
第14章信息化基礎知識
14.1信息與信息化
14.1.1信息的定義及其特性
14.1.2信息化
14.1.3信息化對組織的意義
14.1.4組織對信息化的需求
14.2政府信息化與電子政務
14.2.1政府信息化的概念、作用及意義
14.2.2我國政府信息化的歷程和策略
14.2.3電子政務的概念、內容和技術形式
14.2.4電子政務的應用領域
14.2.5電子政務建設的過程模式和技術模式
14.3企業信息化與電子商務
14.3.1企業信息化的概念、目的、規劃、方法
14.3.2企業資源規劃(EfuP)的結構和功能
14.3.3客戶關系管理(CRM)在企業的應用
14.3.4企業門戶
14.3.5企業應用集成
14.3.6供應鏈管理(SCM)的思想
14.3.7商業智能(BI)
14.3.8電子商務的類型、標准
14.4信息資源管理
14.5信息化的有關政策、法規和標准
主要參考文獻
第15章信息系統基礎知識
15.1信息系統
15.1.1信息系統的概念
15.1.2信息系統的功能
15.1.3信息系統的類型
15.1.4信息系統的發展
15.2信息系統建設
15.2.1信息系統建設的復雜性
15.2.2信息系統的生命周期
15.2.3信息系統建設的原則
15.2.4信息系統開發方法
主要參考文獻
……