一下最近的體會吧。
1. 需求和設計部分應該佔總各項目的80%，coding只佔20%（不算測試），深刻的了
解需求，做出好的設計能讓人事半功倍。
2. 設計部分越詳細越好，不僅能減少你以後的工作量，拿給客戶看後，客戶也覺得
自己的付出物有所值，遇到設想不同的地方也能盡快改正。完成編碼後再改動需求的工作
量會幾何級數增加，導致工期拖後乃至專案流產。
3. 設計部分越規範越好，規範的設計首先是自己需要改動時不至於望而卻步，專案
需求變動時，只改**不該設計的例子數不勝數。大上家公司做二次開發，老大讓從cvs上
接手。規範的文件改動時動作較小，順手就改了。其次以後在寫時能大量減少工作量，讓
自己心情愉快。同時方便後人接手，不至於分太大精力去照顧新同事。當然，讓老闆和客
戶滿意也能提高你在他們心中的價值。
4. 流程圖、用例圖、拓撲圖這種一目了然的東西越多越好，讓人一下了解你專案中
的精華。
5. 想到的問題與多越好，現在列出的問題boss會統一考慮，增加人手或增加工期。
編碼中經常遇到問題boss就會考慮個人能力了。
6. 頁面設計很有必要，有時候想起來很簡單，做起來各種問題就會接踵而來，讓人
防不勝防。
設計文件的內容（概要設計，需求分析，詳細設計）
1，引言 1。1編學目的 1。2背景 1。3定義 1。4參考資料 2，總體設計 2，1需求規定 2，2執行環境 2，3基本設計概念和處理流程 2，4結構 2，5功能需求與程式的關係 2，6人工處理過程 2，7尚未解決的問題 3，介面設計 3，1使用者介面 3，2外部介面 3，3內部介面 4，執行設計...
需求分析文件 概要設計文件 詳細設計文件
由於專案工作需要 需要提供 軟體需求規格說明書 軟體概要設計說明書 和 軟體詳細設計說明書 所以這裡整理學習一下相關文件需要的內容。文章並不設計對所有需求分析，概要設計和詳細設計的詳細描述。因為這其中的任何一點都可以單獨提取出來成為軟體工程學科中的一本書籍內容。2.1 我們為什麼需要 軟體需求規格說...
基於UML的需求分析和系統設計個人體會
閱讀了文章之後，對使用uml進行系統的需求分析和設計有了乙個基礎的理解。在此做一下整理。1.專案開始階段 專案開始階段的初期訪談需要抓住以下幾個重點 必要的業務流程 在摸索業務流程時，初期應該盡可能只捕捉就 必要的 業務流程，在該業務流程中，盡量避免對細節的研究。專案的技術限制 包括使用的技術以及其...