第一篇：焦油坑—項目需求分析讀后感

《焦油坑-項目需求分析》讀后感

《焦油坑-項目需求分析》是作者以自己的實際項目經驗為基礎寫的一篇關于項目過程管理的文章。文章中作者結合實際項目的開發進程進行一步一步的詳細分析和解說，讓我在閱讀中有了深刻的感受。

文中首先提到的是項目開發前期的調研過程，確實也是我們在許多項目的開發前期就如作者所說的一樣，項目調研就是開座談會，只要有點點相關的部門或人員都會通知到參與進來。一堆無關的人發表了一堵亂七八糟的意見，為了誰都不能得罪，需求都整理出來后又沒有人能確認下來，最后還是得大領導出來做決定。大領導出來又只是說一些大方面或框框的話沒有什么實際上的內容。到最后還得各個業務部門在猜測琢磨。這樣不僅拖延了項目的進度，也會給項目后期的開發帶來諸多的壓力，需求不明確、需求經常變更等等。

是的，在做項目的時候經常碰到這樣的問題，可是一直沒有找到好的處理辦法，我只知道抱怨客戶這不好那不好，而沒有找到實際解決問題的辦法。而接著作者提到了他的實際解決辦法，寫得相當好很實際很直觀個辦法。現在還沒有能力能到達作者那樣在短時間內去分析清楚各個領導的情況和看透這個項目的盤子有多大。但是我覺得首先就本著真心真意的為客戶去解決他們的實際問題的基本思想去做這個項目就是沒錯的。

有了基本思想，接著就是細化，要落實到點上才能把目標給完成了，要不永遠是空的。作者在文中也寫到了，到業務部門中去調研，去了解他們實際的業務需求，去了解他們最最想解決的問題。最主要的是，作者細到了一個一個人的去了解。這個很讓我佩服和感慨。是要用心去做的才能做到這個程度的。

接著就是在調研中去發現問題。作者在文中是這么寫的：所以發現異常流程，發現新流程，全靠調研人自己細心發現和甄別。可能，他無意的一句話，你直追著下去就會發現他日常處理的空白和漏洞和矛盾的地方。從這句話中又能在次感受到用心去做事這個道理，只有用心去這件事情，才會全身心的融入到客戶的這個角色上，才能對客戶的體驗深有感觸，才能中發現問題和想辦法解決問題。

用心做每一件事情，用細心去分化用心這個大目標，細化到每個實際點上，一步一步，一個點一個點去完成，沒有攻不破的項目。做事情不是一帆風順，難免有挫折和失敗，但是我們不去畏懼，我們善于學習和總結，我們在進步。

第二篇：項目需求分析報告

福州八中鰲峰初級中學項目的網絡需求分析報告

一、項目名稱：福州八中鰲峰初級中學

二、引言

該網絡是校園網站信息發布系統,學校主站，含各個學科子站點，包含德育處，團委，學生會，教務處，總務處，辦公室，工會子站。主要欄目設置：學校概況、信息中、黨群工作、校務公開、德育教育、教學管理、教學科研、學生園地、中高考專題、心靈驛站、校友之窗、友情鏈接、數字校園

三、系統目標描述和功能描述

1、信息發布系統

網站前臺模塊

首頁：學校網站的索引頁，還包括模糊搜索站內資源的功能。

一中概況：發布學校的簡介、發展狀況和學校自身的相關信息，并動態歸類。

黨團組織：發布學校黨團建設的相關資訊，并動態歸類。

學校資訊：發布學校近期活動和新聞。

學校管理：發布學校各部門的相關通知與文件，并動態歸類。

教學教研：發布學校在教學研討和課題研究方面的相關信息，并動態歸類。

教學資源：管理和發布論文、課件、教案和考卷等方面的資源。

電子像冊：１．可以上傳圖片格式，FLASH格式等（格式要求：Jpg、GIF、ＰＮＧ、ＢＭＰ、SWF、TIF等）２．實現圖片漸變編輯功能。３．新增、刪除、修改４．權限管理 新課程：發布學校在新課程方面取得的成績，并動態歸類。

班級&社團：為各班級各社團開設空間，供發布信息和照片。

教師博客管理系統：自我簡介，消息管理，空間管理，好友管理，日志管理等。

電子相冊：可包含多個相冊，數量不限；

班級&社團：可在不影響界面整體效果的基礎上讓相應班級修改部分界面元素（包括自定義班級主頁的標志性圖片、班級主頁的背景圖片和班級主頁的顏色主題），另外，該模塊還包含有班級電子相冊。

留言板：實現留言與答復的功能。

學生論壇：學習網絡上開源論壇的實現方式，實現一個學生交流活動的平臺。相對獨立于學校網站。

后臺功能模塊

權限管理使用指南權限管理下共分3個模塊：[角色管理] [給角色分配權限][給用戶分配權限]

（1）通知公告只有系統管理員ADMIN才有權發布通知公告。發布的內容將顯示在各部門首頁的公告欄里。

（2）網上調查只有系統管理員ADMIN才有權發布網上調查。發布的內容將顯示在各部門首頁的網上調查里。

（3）友情鏈接只有系統管理員ADMIN才有權編輯友情鏈接。發布的內容將顯示在各部門

首頁的友情鏈接里。

2、辦公信息化管理系統

主要功能：今日工作：是用戶進行日常辦公的主要場所，用來存放待處理的有關文件、網絡報送以及工作消息等信息。

公文系統：用于公文的登記、發布、存檔以及生成報表。

工作消息：用戶發布日常工作中的通知等信息。

網絡報送：傳遞相關工作資料。

交流登記：記錄學校大事件以及每次對外交流情況等。

教師檔案：有關教師檔案管理，全程維護每一位教師檔案的變動情況。

系統設置：系統日常運作與環境設置。

3網絡性能需求

核心交換機（機箱式）

1、背板帶寬≥640Gbps2、交換容量≥480Gbps3、包轉發率≥350Mpps4、雙電源模塊冗余5、10/100/1000Base-T口≥12個，千兆SFP光纖接口≥24個

6、萬兆XFP接口≥1個

7、支持IP ACL，支持基于源/目的IP或MAC、三層IP協議類型、TCP/UDP四層端口號、IP優先級、基于VLAN、Tag/Untag、CoS等

9、支持802.3ad(LACP)，支持負載均衡

10、支持802.1Q VLAN數量≥4K11、支持的路由協議，如RIPv1/V2,并支持MD5認證、OSPFv2、BGP4等。

12、支持MPLS、MPLS VPN、MPLS TE功能。

接入層交換機

1、固化10/100M電口≥242、固化千兆Combo(SFP/GT)接口≥

23、交換容量≥32Gbps4、包轉發速率≥6.6Mpps，全線速

5、MAC表容量≥16K6、Vlan表項≥4K7、堆疊或者集群管理數量≥248、每個端口提供4個優先級隊列，可分別設定隊列帶寬，支持WRR/SP/SWRR等調度方式。

9、內置 DHCP Server,可對用戶分配IP地址。

10、支持標準和擴展ACL，完全硬件線速實現。

11、支持防IP報文DOS攻擊。

12、支持ARP安全功能，可以防止ARP欺騙、防止ARP掃描。

13、設備與核心交換機同一品牌；

光纖模塊SFP-SX-L SFP-SX-L，1000Base-SX SFP接口卡模塊（MMF,550m），LC接口 設備與核心交換機同一品牌；按廠家規定保修.防火墻在服務器與路由器之間加個防火墻很有必要。網絡操作系統，網絡服務器軟件等可能存在一些安全漏洞，應當及時對系統進行補丁程序升級，加固系統的安全性。網絡系統遵循安全規范和達到的安全級別，采用各種殺毒軟件。

網絡管理系統

基本特性:全中文圖形化界面。支持平臺:WINDOWS平臺，系統呈現網絡的真實拓撲圖，支持三層網絡拓撲、二層物理拓撲、VLAN子網拓撲等不同的呈現方式，支持拓撲的自動發現設備，WEB拓撲視圖。能夠發現VLAN中所有終端PC設備，并計算出終端設備IP地址、MAC地址、接入交換機端口等信息，自動在拓撲圖上顯示終端設備連接和出入流量、丟包等等情況。

根據我們的預算和資源限制，完成該項目大約需要半年。客戶想重新購置設備并賣掉現存的舊設備。

第三篇：項目需求分析報告

項目需求分析報告

（一）一、項目名稱

今日事

二、設計背景

隨著社會的發展，我們的生活節奏逐漸加快，與此同時，網絡的大量普及，導致大量的信息不斷的沖擊著我們。在這種生活節奏下，我們難免會出現一不小心忘掉一些重要的事情，這是讓我們產生這個想法的一個方面。

另一方面，現如今的學生總是計劃很多，卻很少付諸行動，這不僅與個人的堅持與否有關，同樣是因為步入大學時代后，大家心中充滿了迷茫所致，往往計劃趕不上變化，因此，我們決定開發這樣一款軟件，來改變這種情況。

三、項目風險

該軟件開發項目的風險承擔者有：

任務提出者：需要承擔的風險是產品是否能達到用戶的需求，該產品是否能帶來收益。

軟件開發者：需要承擔的風險是產品是否能滿足需求報告說明書里的各種功能需求等。

產品使用者：需要承擔的風險是產品是否能滿足自己所需。

四、功能需求

日歷功能，可以查詢日期

制定計劃功能，分為長期，中期，短期三個層次，短期即為今日事，中期為1周或1月，長期為數月或1年，這些可以由用戶自己設置。

完成計劃功能，可以通過勾選來標注哪些是已經完成的，哪些是還為完成的。

成就系統，通過統計各期所完成計劃數量給予用戶相應稱號，同時可以與其他用戶進行競爭。

提醒功能，手機解屏時提醒用戶今日需要做的事，而在每天結束時，匯報今日完成進度。

五、運行環境

移動端android平臺

六、性能要求

為保證軟件能夠長期，安全，穩定，高效的運行，應滿足以下性能要求：

時間特性：系統響應時間應在人的感覺和視覺范圍內（<1S），系統響應時間足夠迅速（<5s）。

適應性：在操作方式，運行環境，軟件接口或開發計劃發生變化時，應具有適應能力。

項目需求分析報告

（二）一、引言

引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔

1.1編寫目的：

本需求分析報告的目的是規范化本軟件的編寫，旨在于提高軟件開發過程中的能見度，便于對軟件開發過程中的控制與管理，同時提出了本學校排課系統的軟件開發過程，便于程序員與客戶之間的交流、協作，并作為工作成果的原始依據，同時也表明了本軟件的共性，以期能夠獲得更大范圍的應用，同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。

1.2背景及范圍

本項目的名稱：學校排課系統。

本項目的任務提出者及開發者是：計算機應用三班張哲，用戶是學校。

本產品是針對電腦進行排課的需求設計的，可以完成：基本數據錄入與維護、課程表編排、課表沖突分析報告、課表輸出、可以直接或導出至Excel打印總課表、教師課表、()班級課表、場地課表、系統管理。

1.3定義 縮寫詞

學校排課系統軟件：學校排課系統軟件是為了幫助學校老師對學校的排課更加方便和快速制作處課程表及其管理學校的課程的軟件。

二、項目描述：

使用改程序后，學校的排課可以很輕松的安排好，而卻可以盡量避免平時排課時出現的排課沖突，還可以臨時加補課等功能。

2.1軟件開發的目標：

改善目前有些學校人工排課是常常出現的沖突以及浪費的大量時間。同時也通過實踐來提高自己的動手能力。

2.2應用范圍：

理論上能實現中小學排課，職業中學排課。

2.3子集說明：

軟件主要分為兩個模塊，一個基本信息的錄入，一個是進行排課的管理。

2.4軟件功能描述：

外部功能：實現了可視化窗口，排課，調課。

內部功能：基本信息的錄入、固定課的設置、科目的錄入、年級的錄入、任課老師的錄入、場地限制的錄入和課表的查看；排課操作、調課操作、場地調課操作、老師課表及學生課表生成。

2.5軟件操作人員的要求

軟件的操作人員要求具有一定的電腦常識，并且具有排課的初步常識。

三、軟件結構化描述

自己添加一些

四、環境要求：

4.1數據錄入精度需求

在進行向數據庫錄入數據時，要求數據記錄準確。

4.2軟件自身時間特性需求

程序排課響應時間：由于生成課表是需要看電腦的配置，所有時間可能會不一樣，有時候需要等上幾分鐘

五、軟件屬性

5.1可用性

本軟件由于自身的能力限制，所有只限現在所有的功能。

5.2安全性

由于軟件運行數據放在數據庫中，所以參數不容易被錯改、破壞，萬一參數受到破壞，可以從新錄入信息進行更正

5.3可維護性

本軟件利用數據庫進行編程，系統結構由程序基本確定，大量的參數及文本內容全部放于數據庫中。修改、更新數據只要在數據庫進行修改添加，而不需要對系統結構進行修改，這樣系統維護性十分方便。

5.4兼容性

由于尚未測試，故無法對兼容性進行評析。

第四篇：項目需求分析

（1）簡單介紹項目的開發目標（5%）；

（2）簡單介紹項目需求的獲取過程（5%）；

（3）采用UML或其他有序的、結構化的方法，描述項目的主要功能需求和部分非功能性需求（20%）；

哪部分功能需要描述，需要哪些uml圖

（4）描述項目的需求邊界，并說明范圍限定的理由（10%）；

需求邊界說明，根據用例圖中各個用例，進行細化。（理由，簡要說明）

（5）通過一、二個例子，介紹項目的需求分析過程，包括：需求排序、需求平衡與取舍等過程的例子（10%）；

（7）通過示例，展現一、二個功能需求與非功能需求的可檢驗性（10）：

可檢測性，具體說明，dis

（6）通過一、二個例子，介紹對需求進行文檔化、或數據庫化、或采用需求管理工具，進行處理、記錄、存儲、管理的過程，展示部分經過上述處理后的需求項（20%）；

（8）通過示例，展示一、二個需求項的狀態與基線，靜態可定義、動態可追蹤、可比較、可報告的過程（10）；

軟件tfs，caliber

（9）——舉例說明，當發生需求變更時，可能的需求變更的影響分析和變更實現對策（5%）需求樹

（10）其他需要補充說明的內容（5%）。

第五篇：怎么做項目需求分析報告

項目需求分析，看了聽棠的“客戶需求何時休”，深有感觸，何曾自己不是被這個問題整天困擾：客戶需求，為什么總在變阿？做項目真辛苦阿！這樣的感嘆整天都掛在口上。客戶需求變動確實是一個軟件開發永遠不變的話題。為什么小的軟件企業面對經常變動的需求是如此的狼狽？到底要怎么做才能滿足客戶的需求？

聽棠的“客戶需求何時休”深刻的披露了這個問題存在的根源。

需求分析，不僅僅是拿到客戶的需求，更重要的是還需進行分析，了解細節，并就細節跟客戶咨詢，獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題并不在他們考慮的范圍之內，如果作為項目承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。

聽棠所說到的幾點，感受特別深：

“其實問題出在開頭，客戶需求只是軟件需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析”

“客戶本身是不怎么懂技術的，客戶只知道自己的業務需求，而在軟件設計時，是在把業務需求抽象到系統中實現的，把業務轉變為邏輯時，一切都應該符合邏輯的，但客戶的業務思想有時候在軟件系統實現時會有問題的，這就需要分析時分析出來的。少了分析，問題也會在后面的開發中暴露出來，到時可就更麻煩了。”

還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這里的矛盾，而這些問題，如果在期初時，軟件負責人不分析，而是純粹的“聽從”客戶要求去做，當暴露這些問題時，你怪客戶也沒用啊。

項目需求分析報告，在了解客戶需求時，不要不動腦子，不要一味的點頭說“I C”，其實在表面的業務里面可能包含著N多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓項目越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣了解客戶需求未免太麻煩了。至于一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。

客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，后面的變動也將在邏輯上變動，相信代價已經不會那么大了。這其實也體現了系統的擴展性。

需求分析，是一個項目提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的制造者，在系統制造過程中，只有雙方相互配合，共同對系統進行設計才能最后達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的了解，但是，對于軟件需求方面的描述是不了解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常復雜的。我們拿到客戶需求后，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，并減少后期的修改。

謹記一點，需求是經常變動的，只有先做好需求的分析，了解業務以后的發展趨勢，做好具有拓展性的系統設計，才會給系統更大的擴展空間，從而在需求發生變化的時候可以更從容的修改。