網站設計需求確認表

1、我們應當怎樣做需求確認：評審與簽字確認會

時間過得真快，經過一系列需求研討、需求分析和整理確認，我們整理出了需求列表，編寫出了需求規格說明書，一切似乎該到結束需求分析階段的時候了。但是，敏捷大師的一句話讓我們徹底心涼到了骨頭里。敏捷大師說了，我們不可能在需求分析階段完成所有的需求分析工作，它將延續到設計、開發，甚至測試階段。一直以來，我對這句話非常困惑。既然需求分析階段不能完成所有的需求分析工作，那麼完成多少才算結束呢？80%？60%？或者更少？大師沒有給出一個標准。大師就是大師，生活在太空里的，我們慢慢理解吧。經過多年的實踐，我慢慢理解了。我們說這種需求分析工作不可能完全完成，或者說日後用戶的需求會變，其實並不是毫無規律可循的。通常，用戶對需求的變更只發生在某些固定的范圍內，弄清楚了這些范圍，我們的問題就迎刃而解了。1. 整體需求不變，具體細節變化。我們說需求是分層次的，整體框架、功能模塊、每個操作的細節。如果用戶變更到了將整個框架都推翻了，這個項目就別做了。所以整體框架是必須在需求分析階段完成的，是日後不可能改變的。功能模塊可能要變，但通常是某個部分在變，而更多的是那些具體操作的細節在變。2. 界面風格與操作易用性是最容易發生變更的。我們說用戶看到軟體以後不滿意，其實主要是對界面風格與操作性不滿意，而不是軟體功能。界面不夠美觀，操作不方便，不符合用戶的操作習慣，都是造成用戶不滿意的地方。3. 增加其它功能。軟體是對現實的模擬，而現實也是復雜多變的。我們與用戶在進行業務流程分析時，也許一些流程沒有考慮到，或者還有特殊情況需要處理。這些是客戶要求增加功能的主要動因。OK，萬事俱備只欠東風，當所有工作都完備以後，我們的需求分析工作開始進入最後收尾的階段。我們說，需求分析階段的產出物是需求列表與需求規格說明書，而最終結束的里程碑無疑就是需求評審會了，或者說與用戶的簽字確認會。需求評審會的主要目的就是確認需求，以便以此開始我們的設計開發工作。從理論上說，需求評審會應當由用戶代表，與項目經理、需求分析員、系統架構師、設計人員、測試人員、QA經理，還有公司相關領導參加。但實際上，讓如此多不同角色的人聚集在一起開會是不現實的。因此，我們可以將需求評審會分為內部評審會與外部評審會兩部分來開比較現實。處理外部問題，必先要從內部統一思想。先召開一個內部評審會，聽聽系統架構師、設計人員、測試人員、QA經理對需求分析工作的意見，然後由領導講講話，布置一下後面的工作，是十分有必要的。按照我的經驗，系統架構師這時的作用相當重要，他應當仔細閱讀需求，仔細思考技術是否可行，以及預測該系統是否能夠達到用戶方領導對該項目制訂的目標。如果答案是否定，立即進行調整。最後就是與用戶的外部需求評審會了。外部需求評審會，也可稱為簽字確認會議，就是與用戶就需求規格說明書進行評審，最後簽字確認。用戶簽過字的東西，不可能完全抑制住用戶的變更，但至少從很大程度上抑制住了用戶的大改。然而，在召開外部需求評審會之前，我們建議大家就需求規格說明書，先與各個單位或部門的用戶代表討論並確定下來，避免在最終的簽字確認會上出現分歧，影響工作進度。畢竟大家都不容易，工作一大堆，聚在一起不容易。經過數月的分析討論，最終在一片和諧的氣氛中，雙方領導在需求規格說明書上簽字，項目開始進入一個新的輪回。在這個輪回中，是焦頭爛額、不勝其苦，還是如履薄冰、最終順利交付，是與許多因素有關的。但我想說，一份高質量的需求分析必定起到決定性的作用，必定為日後的軟體開發掃清了許多許多的地雷。我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規格說明書（全文終）

2、我們應當怎樣做需求確認：一個需求列表的實例

1．評審發起人填寫一份評審計劃，詳細記錄評審時間、評審內容、評審者、評審地點，制訂評審組長，並預計評審工作量，發起一個評審任務。
2．評審者在收到郵件後，進入評審任務中，對評審內容進行評審，同時填寫並提交各自的評審意見。
3．評審組長匯總所有的評審意見，並在評審會上依次過所有的評審意見，對評審意見進行修改或刪除，填寫問題跟蹤，形成此次評審會上最終的評審意見及問題跟蹤表。
4．評審組長製作評審報告，並形成評審結論，以郵件的形式通知所有評審者。
6．評審組長跟蹤所有問題，並可以依次關閉每個問題。
當然，在這個需求列表中，客戶提出了一些名詞，比如評審計劃、評審意見、評審組長等。我們在整理需求列表的同時，應當注意整理這些名稱，弄清它的內涵外延，以及它們相互之間的關系、作用。這將為我們後面的領域模型分析提供素材。毫無疑問，這樣的需求列表過於粗略。因而在後面的業務討論中，我們逐項對它們進行了細化：
1．評審發起人填寫一份評審計劃，詳細記錄評審時間、評審內容、評審者、評審地點，制訂評審組長，並預計評審工作量，發起一個評審任務。
1.1 評審時間應當分為數個階段分別制訂時間計劃，如評審准備、評審會議、評審報告；
1.2 評審內容應當可以上傳數個文件，分別描述文件的內容、作者、編寫日期、版本號，供評審者下載與查看；
1.3 填寫評審者時，選擇一個評審者為評審組長，評審發起人不能是評審組長；
1.4 評審地點與預計評審工作量只需直接填寫；
在我們後面的用例分析中，我們對這段需求列表進行了大量的分析設計。但這些都是設計與實現，它們會出現在後面的用例分析及其模型中，卻不應出現在需求列表中。在後來的升級開發中，客戶又提出了發郵件通知的功能。將該功能描述出來，並添加到需求列表中：
1.5 評審計劃提交以後，以郵件的形式發送給每個評審者，通知該評審任務。
有了這樣的需求列表，當需求分析工作完成時，我們將一項一項檢查用例模型是否滿足需求列表的內容；當軟體開發完成時，我們將一項一項檢查軟體功能是否滿足需求列表的內容；當用戶驗收時，我們同樣使用需求列表，一項一項檢查我們的軟體是否滿足用戶需求。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）

3、品牌網站建設需要哪些規劃

程序員鍾振森之前給客戶做好品牌網站需要先規化以下幾點：

1、品牌網站建設的重要性
品牌網站能更快地傳播品牌價值、品牌文化、品牌產品等等品牌屬性給客戶，讓客戶能更快更全面了解到品牌的一切。

2、品牌網站建設的欄目規劃
品牌產品、暢銷榜單、會員積分、最新消息、客戶服務、人氣明星榜、當季熱推、網購專享、品牌故事、官網獨享……

3、品牌網站建設的建站規劃
品牌網站建設品牌故事模塊規劃：描述品牌的誕生時間、品牌所經歷說的比較有紀念意義的時間點跟事件、品牌的文化、品牌傳播的價值觀、品牌的明星產品、品牌明星產品跟別的產品不一樣的特殊地方、品牌的創始人等等多方位盡可能來展示給客戶品牌的魅力跟風采。

4、確定品牌建站目標

建站目標也就是行業門戶網站建設的目的，是網站建設規劃時必須解決的核心問題。行業門戶網站建設的目標必須要明確和具體，對網站建設流程有指導作用。網站建設的目標有：宣傳企業的品牌，進行網上銷售等。

5、品牌網站域名的確定

網站域名是需要企業自己申請的，行業門戶網站在網站建設時需要進行域名的申請，網站域對網路營銷的成功具有重要意義，所以企業一定要重視起來。行業門戶網站域名申請的建議：域名應簡單、易記，應使用英文字母或拼音，申請時應准備三個備選。

6、網站結構和功能的策劃

網站結構和功能的策劃是行業門戶網站建設前對於網站結構和功能的預先計劃，這部分的內是在確定的網站的目標和域名之後的工作。網站結構和功能的策劃的主要內容有：網站結構的布局要求，網站功能的確定和實現等。

5、網站技術需求

網站建設是離不開技術團隊的，所以行業門戶網站建設時一定要及時的解決建設網站的技術需求，並制定出有效可行的網站建設技術解決方案。行業門戶網站建設對網站技術的需求有：伺服器、操作系統、程序開發、網站製作、網站安全措施等。

4、我們應當怎樣做需求確認：快速原型法

常常聽到許多朋友跟我埋怨，需求分析之難，就在於用戶自身就常常弄不清楚自己的需求。起初在需求確認的時候說得好好的，一到軟體上線的時候就不是那麼回事了，這可沒法整。但我們只要坐下來仔細分析就會發現，在需求分析的時候我們跟用戶是在空對空地討論問題。用戶不是專業人士，他也搞不清楚軟體到底會做成啥樣，所以你跟他確認的時候他就點頭了。但是，用戶不是傻子，當你軟體上線時，他拿到了實物了，知道軟體做成啥樣了，一旦不滿意他就開始提變更了。所以，需求分析的症結就在與這個實物。既然症結在此，毫無疑問，我們就應當在需求分析階段拿出實物，用實物與用戶確認需求，這就是快速原型法的基本思想。快速原型法，簡稱原型法（Prototyping），是20世紀80年代提出的一種從設計思想、工具、手段都全新的系統開發方法。它摒棄了那種一步步周密細致地調查分析，然後逐步整理出文字檔案，設計開發，最後才能讓用戶看到軟體結果的繁瑣作法。當我們捕獲了一批業務需求以後，就立即使用快速可視化工具開發出一個原型，交給用戶去試用、補充和修改。再提出一些新的需求以後，再開發一版新的原型。原型法的關鍵就是這個快速開發。不用考慮性能、美觀、可靠，原型的目的就是模擬客戶的需求，與客戶進行確認的。整個需求分析的過程就是「捕獲需求->原型開發->確認需求->再捕獲需求」的過程。原型開發的快速與模擬到什麼程度，是一對矛盾，我們要去把握。要快速開發，必然不可能和最終交付的軟體系統一模一樣，許多復雜問題被簡化，非關鍵性流程被忽略，這就是所謂的模擬。因此，模擬到什麼程度是關鍵，既能說明問題，又不耽誤時間。根據我的經驗，一般能拿出界面，並可以走通關鍵性流程就可以了。一些快速開發平台為快速原型法提供了可能。當用戶拿到原型可以自己操作時，需求研討的氣氛立即變得不太一樣了。當用戶享受原型給他們帶來體驗的快感時，需求被源源不斷地被提出來。這時候的需求，就不再是枯燥無味的文字游戲，而是生動形象的圖形界面。日後，如果項目採用迭代開發，讓用戶看著軟體一點兒一點兒地成長，這又是多麼美妙的體驗啊。與此同時，你與用戶的信任也在一步一步建立起來，軟體風險在降低，項目將朝著正確方向前進。快速原型法是美妙的，它給你與用戶帶來了從未有過的體驗。但美妙的同時，也會帶來一些的尷尬，不必要的誤會，我們一定要注意。最常見的誤會就是讓用戶將原型誤以為最終交付的系統。開發一個系統需要持續數月，但你倒好，幾天就搞定了，為什麼還要在這個系統上投入大量資金呢？如果對方領導開始有這樣的想法時，雙方就開發費用進行的談判就有一些不妙了。所以在給用戶看到原型前，一定要跟用戶解釋清楚。既然是原型，必要的校驗、非正常操作的處理通通都被忽略。因此，當演示原型出錯時，用戶你可千萬不要較真喲！這丑話可得說在前頭，否則用戶跟你較起真來，你在用戶心目中的形象可就要大打折扣了。我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）

5、保護環境網站的需求分析確定風格與定位,設計開設哪些欄目呢

《環境保護》網站設計
一． 前言
20 世紀以來，科技進步和社會生產力的提高，使人類得以創造出前所未有的物質財富。但與此同時，人口劇增、資源過度消耗、環境污染。生態破壞、國家或地區之間貧富差距擴大等全球性問題也日益突出，嚴重阻礙了人類社會的長遠發展和生活質量的提高，甚至對人類未來的生存和發展構成了威脅。特別是這幾年地球生態環境被破壞很大，造成了很多的水土流失，動物滅種，自然災害頻繁發生，從那年的乾旱開始這幾年出現了洪水、雪災、地震差不多每年都會出現一次重大的自然災害。這就是人類破壞了自然的後果，做這個網站就是為了提倡大家關愛自然，尊重生命，保護自然環境，維護生態平衡，畢竟我們只有一個地球。
二． 總體設計
做網站前我瀏覽了國家環保局的網站與各種關於環境保護的網站，最後我、確定我的網站主要實現讓人們可以從我的網站了解環保法規、了解環保知識、宣傳環保廣告等功能，確定了網站要實現的功能後，就是著手畫網站草圖了，瀏覽與參考了很多網站後終於成功畫出網站的草圖，並根據草圖最終完成網站製作。網站邏輯圖如下

三． 詳細設計
1.草圖的設計，瀏覽了各大環保網站後,我已在心中確定了我的環保網站的大體布局,並成功的建立網站草圖.
2.布局的規劃，第一步新建「HTML」 在新建的空白網頁的」工具欄」選項卡中選中」布局」由於在網頁中」層」不好固定位置,所以我選用表格布局,進入布局模式選用」繪制布局單元格」在空白網頁中根據先前設計的個人網站草圖繪出網頁的框架. 根據個人網站顯示的需要更改表格布局的屬性值, 最後成功完成了網站主頁的布局設計,並根據需要調整好頁面的布局表格屬性值.

網站的布局
3. 網頁背景的設計
a.打開Adobe Photoshop CS2根據網頁頁面的要求建立相應大小的空白圖片,然後在新建的圖片上進行處理.
b.使用各工具對網頁背景的大體顏色進行噴繪,為使網站的背景顏色不會太過死板生硬,將各工具的」硬度」調整為0.
c.使用Adobe Photoshop CS2中的鋼筆路徑工具裁取網頁背景所需要的裝飾圖片
1.打開需要摳圖的圖片在Adobe Photoshop CS2的工具欄上選中」鋼筆」工具並將其改為」路徑描點」模式.
2.使用鋼筆工具描出需要摳取圖片,描點完成後同時按住鍵盤上」ctrl」+」enter」完成路徑的合並,將圖選中.
3.切換到剛剛新建的網站背景圖,將剛剛摳取的圖片粘貼進去.
4.重復摳圖步驟剪取背景所需的各種裝飾圖.對網站背景進行美化.
最後運用了Adobe Photoshop CS2將所有網頁頁面的背景模板都按照草圖要求美化。完成了整個網站各頁面的背景模板的美化設計.

我設計的網頁背景圖
4.網頁模板的建立，由於網站有很多網頁是用的同一種風格，所以建立網頁模板可以節省很多時間與精力，模板是做好一個網頁的母版後，選擇「文件「里的」另存為模板「，如果計算機以前沒有建立站點，存模板時會提示建立站點，站點的文件夾要設為網頁保存的文件夾，最後成功的建立了模板並運用模板建立了多個子網頁。

網站的模板
5.廣告頁面flash的設計，1．打開Flash，在開始頁上選擇「從模板創建」中的「幻燈片演示文稿」，在彈出的對話框中選擇一模板，如「科技幻燈片演示文稿」，然後「確定」即可。如果沒有開始頁，不要緊，可以單擊菜單「文件」中的「新建」，也可出現該對話框。2．打開後如下圖所示，在Flash中的幻燈片和PowerPoint結構略有不同，它是一個倒掛的樹形結構。樹根只有一個，在幻燈片演示中一直存在，一般用來做背景；同級之間是兄弟關系，默認情況是「替換」，也就是說第二張幻燈片如果與第一張幻燈片同在一級，當第二張幻燈片出現時，第一張幻燈片消失；還有上下級關系，與上級之間默認情況是「疊加」關系，也就是說，如果第二張幻燈片是第一張幻燈片的下級，當第二張幻燈片出現時，它是加在第一張幻燈片上面的。3．當然，模板給的幻燈片個數可能與所需幻燈片不一樣，也可以自己添加幻燈片或刪除它。在需要添加或刪除的幻燈片上單擊滑鼠右鍵，如下圖，可以很方便地添加或添除它。當選擇「插入屏幕」時，插入的幻燈片與所選幻燈片同級並在所選幻燈片的下方；當選擇「插入嵌套屏幕」時，插入的幻燈片與所選幻燈片是下級關系。好了，只要將每張幻燈片變成自己的內容，然後選擇「文件->存檔」，再選擇「文件->發布」，就會在保存文件的位置發現一個同名的swf文件，這就是製作出的幻燈片文件了。
四． 心得體會
做完這個網站,讓我真正的認識到一個成功的網站，先期的准備工作是很重要的，好的開始等於成功的一半。選擇這個環保網站的建設的樣式後，就要為目標而努力了。熟練掌握網頁設計和圖形處理的技巧是必須的，但經驗是在實戰中獲得的，我們雖然剛開始學也不必因此而畏懼退縮，多多練習才會有提高。網站建設最重要的莫過於兩個問題：設計和內容，素材的准備.
1、設計的要求：
第一、導航清晰，布局合理，層次分明，頁面的鏈接層次不要太深，盡量讓人第一眼看清網站的大體.
第二、保持統一的風格，有助於加深訪問者對的網站的印象。要實現風格的統一，不一定要把每個欄目做得一模一樣，舉個例子來說，可以嘗試讓導航條樣式統一，各個欄目採用不同的色彩搭配，在保持風格統一的同時為網站增加一些變化.
第三、色彩和諧、重點突出：在網頁設計中，根據和諧、均衡和重點突出的原則，將不同的色彩進行組合、搭配來構成美觀的頁面.
第四、界面清爽：要吸引訪問者長時間的停留在的網站，千萬不能讓用戶第一眼就感覺壓抑。大量的文字內容要使用舒服的背景色，前景文字和背景之間要對比鮮明，這樣訪問者瀏覽時眼睛才不致疲勞。
第五、堅持原創：剛開始學做主頁時，適當模仿別人的優秀設計是可取的，但模仿絕不等同於抄襲，一定要把握好其中的尺度。設計是這樣，內容的選取也是如此，多一些原創的內容，的主頁才會帶有更多的個性色彩；
第六、動態效果不宜太多：適當的動態效果可以起到畫龍點睛的作用，過多的動態效果會讓人眼花繚亂而抓不住主題。
2、技術運用中要注意的一些事項：
第一、明確技術是為設計服務的，不要沉迷於技術的運用，堅決摒棄那些華而不實的特效；
第二、先為站點定義好統一的外部CSS，內部頁面都調用這個CSS，這樣不但可以讓的網頁在瀏覽器改變設置時不變形，還有助於保持整個站點的風格統一，並且方便修改；
第三、不要打開過多的新窗口，每個鏈接都會打開不同的新窗口尤其讓人反感；
第四、圖象的製作要兼顧大小和美觀，圖片和文字的混排、圖片的合理壓縮可以讓頁面美觀而且文件小巧。即使是個性十足的設計站點，浪費太多的時間在頁面下載上也會令人生厭；
3.加深了網站設計的技術熟悉
這次對網站的設計讓我對各種網站設計的技術和網站設計中應注意的問題以及網站設計中所運用的工具更加的了解與熟練.

6、功能需求確認書的翻譯是：什麼意思

功能需求確認書
Functional requirements confirmation

7、網站設計需求分析怎麼寫

1）繪制關聯圖：繪制系統關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。同時它也明確了通過介面的信息流和物質流。

2）創建開發原型：創建用戶介面原型當開發人員或用戶不能確定需求時，開發一個用戶介面原型，這樣使得許多概念和可能發生的事更為直觀明了。用戶通過評價原型將使項目參與者能更好地相互理解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。

3）分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙。

4）確定需求優先順序：確定軟體工程需求的優先順序別應用分析方法來確定使用實例、產品特性或單項需求實現的優先順序別。以優先順序為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，並在那個版本計劃中作出需要的變更。

5）為需求建立模型：為需求建立模型需求的圖形分析模型是軟體需求規格說明極好的補充說明。它們能提供不同的信息與關系以有助於找到不正確的、不一致的、遺漏的和冗餘的需求。這樣的模型包括數據流圖、實體關系圖、狀態變換圖、對話框圖、對象類及交互作用圖。

6）編寫數據字典：創建數據字典數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括數據字典組件。

7）應用質量功能調配：使用質量功能調配質量功能調配是一種高級系統技術，它將產品特性、屬性與對客戶的重要性聯系起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。它將需求分為三類：期望需求，即客戶或許並未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備。

8、網站方面專家進，請問，需求，設計，策劃啊，都什麼意思

你是在公司做項目還是學生做設計熟悉流程？
我是學生，我說下我的看法吧
建站首先確定需求：和用戶溝通，了解需求的詳細情況
需求分析文檔應該包括：項目名稱，用戶對象，客戶程序，項目模塊及功能。然後找到用戶確認需求。提交給設計師就OK
設計文檔應該包括：ER圖 DFD圖 根據情況選擇實現技術 資料庫設計 模塊功能實現 UML圖。提交給程序員。
最後編碼：把UML寫成代碼，有DBA的話負責設計維護資料庫
測試：如果需要，就對項目進行測試咯
我知道的大概就這樣。

9、需求確認意味著什麼？

在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。 對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。 需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人員的關系，為項目的成功奠定了堅實的基礎。