1 前言
需求分析階段是管理資訊系統（mis）開發最重要的階段。mis開發的需求階段首先是了解和澄清使用者的需求，然後嚴格地定義被開發的軟體系統的需求規格說明書[1]。常用的軟體需求分析方法有面向資料流的結構化分析方法、面向資料結構的jackson方法、物件導向的方法和原型法等。原型法由於改變了系統的分析、設計和實現三個順序階段的觀點[2]，改變了傳統的自頂向下的開發模式，降低了軟體需求的風險，因此得到了廣泛的應用，特別是在致力於某一領域mis開發的軟體公司，如致力於電力mis開發的公司。但作者在長期的mis需求分析過程中，發現原型法有以下缺陷：
1）原型的設計和修改工作量大，增加了系統的開發成本；
2）由於使用者不關心或不理解原型的概念和實現，而且存在較大期望，使得與實際系統差別較大的原型增加了需求分析人員與使用者的交流難度；無論是水平原型，還是垂直原型都不能反映實際系統的全貌；
3）軟體需求主要包括：功能需求、介面需求、效能需求、環境需求、可靠性需求、安全保密需求、資源使用需求、軟體成本消耗與開發進度需求和目標需求[3]。原型法中的原型難以表達軟體的後七項需求；
4）原型法強調使用者和開發人員不斷對原型進行不斷修改和補充，直到使用者感到滿意為止。在時間緊和任務重的大型mis專案中，這種情況實際難以保證，特別是在使用者單位和開發單位距離較遠時。
本文結合管理資訊系統專案實施的實踐，提出一種新的需求分析方法-簡化原型法。這種方法根據資料庫應用的特點，將需求分析分為兩個階段，並簡化了作為需求分析工具的系統原型。
2 簡化原型法需求分析的第乙個階段
2.1 系統的邊界
系統的邊界規定系統覆蓋的作業範圍，主要有地理邊界（規定系統執行的部門、分支單位等）、操作員範圍（規定作業系統的所有操作員身份、分布和大致許可權）和業務範圍（規定系統處理的業務，對於不處理的邊沿業務特別明確指出）。
2.2 系統處理的業務
系統處理的業務涵蓋系統處理的所有業務，包括各種業務的描述、資料**、實現要求。但是業務規定不要求過細，可以對應實際系統中的乙個模組。如：電力mis中輸電設施管理子系統中的線路裝置管理，不詳細描述線路裝置管理中的所有功能。
2.3 與其它系統的介面
與其它系統的介面明確規定介面的系統、功能和實施單位。在介面的實施單位中明確是由開發方完成，還是由開發方協助第三方完成。
2.4 工程的進度控制
工程的進度控制規定工程的開始、結束日期和具體工程專案的名稱、完成時間、地點、完成標誌及責任分工。具體專案一般包括：採購裝置到達現場、採購裝置安裝除錯、完成網路佈線、開發準備階段、業務需求調查、系統分析和設計、軟體編制、現場除錯、資料準備及錄入、功能確認、試執行和系統驗收。責任分工規定雙方對於具體專案的工作內容和配合方式。在配合方式中規定人員組織方式、人員素質要求、提供的裝置和場所。完成標誌規定具體專案完成提供的檔名稱和要求，如：網路佈線驗收報告和硬體裝置驗收報告等。
2.5 培訓安排
訓包括操作員和系統維護人員的培訓。培訓安排包括每種培訓的人員數量、培訓內容、培訓時間、地點、組織方式和教材，並規定教員和學員的素質要求，及培訓後學員達到的水平。
3 簡化原型法需求分析的第二個階段
如果說第乙個階段解決"有什麼"的問題，那麼第二個階段解決"做什麼"的問題。主要工作有需求調查準備、到使用者單位進行需求調查分析和進行需求評審。
3.1 需求調查準備
需求調查準備工作，在系統的技術協議簽訂後，嚴格依照技術協議進行，主要有向使用者單位發放業務調查表、建立需求分析文件原型和建立系統簡化原型。業務調查表在系統的技術協議簽訂後，立即通過傳真傳送到使用者單位，要求使用者單位在需求調查人員到達現場之前完成。業務調查表內容包括：具體業務的名稱、上級業務、下級業務、發生條件、處理的資料和詳細流程（處理崗位、處理方式和審核細節等）。需求分析文件原型是根據技術協議編寫的需求分析說明書原型，它的格式與標準的需求分析說明書相同。其中的狀態遷移圖和各種表證單書等不明確的內容，採用相似系統的或由系統分析人員根據技術協議和以往經驗設計。
系統的簡化模型根據技術協議的要求，仿照相似系統設計。簡化模型採用視覺化的資料庫程式語言設計，一般採用資料庫應用開發人員熟悉的powerbuilder(pb)或delphi。簡化模型的主要設計要求有：1）充分考慮系統的設計與實現，不得與實際系統脫節；2）盡量**實際系統的操作介面，與實際系統的操作過程完全相同；3）可以單機安裝執行，不與實際資料庫連線；4）演示資料的儲存可以通過文字檔案、單機的資料庫或pb外部資料來源的資料視窗；5）對於介面中容易誤解或難以理解的操作，在功能幫助按鈕中給出說明；6）介面中難以實現或工作量很大的功能，以標註方式詳細說明；7）執行穩定，並比實際系統對硬體要求低。
3.2 需求調查分析
需求調查分析在確認需求調查準備的三項工作完成後，由開發單位的系統分析人員到使用者單位進行。系統分析人員與使用者單位安排的業務主管共同討論業務調查表和系統簡化原型，並不斷修改完善系統簡化原型和文件原型，最終形成共識，並要求業務主管在需求分析說明書上簽字。最終系統簡化原型和源**留在使用者現場，便於系統的操作員進一步理解分析，直到最終掌握；而且有利於提出進一步的改進意見。改進意見可以隨時通過郵件或傳真直接發到開發單位，或由使用者單位的系統維護人員修改簡化原型後，隨時發到開發單位，從而便於開發人員及時修改系統的設計和編碼。
3.3 進行需求評審
需求評審一般由使用者單位組織，評審團成員由同行專家、系統分析、設計和測試人員組成。評審的依據不僅有需求分析說明書，還有系統簡化原型；同時在評審過程中，系統簡化原型不斷進行優化。評審的目標是要求需求分析說明書具有正確性、可行性、必要性、具有優先順序屬性、可驗證性和無二義性[5]。需求評審報告作為對需求分析的補充和修正，由雙方負責人簽字，以需求分析說明書附件的形式存在，同樣指導下一步的系統設計工作。
4 幾點說明
1、此方法適合各種mis工程的需求分析，特別適合致力於某一領域mis開發的軟體公司。採用此方法，開發同類專案越多，需求分析工作的效率越高。
2、在需求分析過程中，由於需要設計系統簡化原型和文件原型，並充分考慮到系統的設計與實現，因此與其它需求分析方法向比，提高了對需求分析人員的要求。在實際工作中，一般由資深的軟體分析和設計人員進行。
3、此方法不僅適合mis軟體工程，同樣適合其它大型軟體工程。
4、由於需求分析工作本身的難度和重要性，此方法同樣要求使用者單位和需求分析人員對需求分析所有工作內容，引起足夠重視；科學安排需求分析工作步驟，某些步驟可以同時進行；所有工作步驟不得應負或疏忽。
5 結束語
目前簡化原型法已經在多個電力mis工程中應用，大大提高了需求分析的工作效率。實踐證明，簡化原型法具有以下特點：1）簡化的系統原型開發工作量大大降低，修改和補充方便；2）簡化原型大大縮短了需求分析人員與業務主管之間的距離，便於交流；並大大加強了需求分析人員與業務主管對系統的認識，有利於發現和解決問題；3）簡化原型的設計提前考慮了系統的設計與實現，大大降低了軟體工程的風險；4）簡化原型增加了系統操作員對實際系統的認識，大大簡化了工程實施後系統的操作培訓；5）簡化原型可以直接指導工程的設計和編碼，便於系統開發的組織。這種方法也可以用於其它軟體工程，對於其它需求分析方法的改革也具有指導意義。
採用簡化原型法進行軟體專案需求分析
11 3 2009 10 51 36 am 前言 需求分析階段是管理資訊系統 mis 開發最重要的階段。mis開發的需求階段首先是了解和澄清使用者的需求，然後嚴格地定義被開發的軟體系統的需求規格說明書。常用的軟體需求分析方法有面向資料流的結構化分析方法 面向資料結構的jackson方法 物件導向的方...
需求分析之原型分析法
原型法 prototyping 的理念是指在獲取一組基本需求之後，快速地構造出乙個能夠反映使用者需求的初始系統原型。讓使用者看到未來系統的概貌，以 便判斷哪些功能是符合要求的，哪些方面還需要改進，然後不斷地對這些需求進一步補充 細化和修改。依次類推，反覆進行，直到使用者滿意為止並由此開發出完整 的系...
需求分析 原型設計
需求分析 原型設計 需求分析 訪問軟體專案真實使用者 首先本專案的使用者是這個需要做簡單四則運算的使用者 我們團隊通過對家裡有三四年級小學生 需要做簡單四則運算 的簡單採訪 反映了幾個主要的問題 1 自己出題太麻煩2 批改太麻煩3 統計太麻煩。nabcd n 現在市面上並沒有面向低年級學生的四則運算...