最近幾周都在根據新的功能需求編寫相對應的文件，先編寫專案立項報告，編寫結束後開始編寫需求規格說明書，之後便是詳細設計說明書，下個階段便是編寫階段了。以前也編寫過需求規格說明書和詳細設計說明書，因為以前經驗少，寫的東西不夠深度沒有特點，有一種為了完成文件而寫。
這次完全把自己當做設計，想要讓自己設計的功能，能盡量站在使用者的角度，使功能簡單、易用、互動性強。寫了這麼其他的，我們轉向文章重點，文件的總結。
首先為什麼要寫文件，在大學的軟體工程，
寫的第乙個文件是專案立項報告，這份文件是給使用者或上級領導檢視的，他們將決定功能的去和留，所以要站在使用者的角度編寫該文件。編寫時應描述功能的主要業務場景，因為功能的實現方式有很多種，根據業務場景能提高功能的可用性，切入使用者最關心的內容。
需求規格說明書也是對需求的描述，提供研發人員使用，所以要站在研發人員的角度進行編寫，需求文件需要注意功能點要詳細不能遺漏，防止需求遺漏，需求規格說明書要開始使用ea製作用例圖、時序圖、和事件流，感興趣的同學可以去試試。
詳細設計對需求規格說明書功能細化至**邏輯，包括用例圖、時序圖和類圖，那麼詳細設計的用例圖和時序圖和需求文件的圖有什麼區別呢？用例圖，舉個例子：在需求文件中乙個功能點是「制定xx方案」，制定方案可以通過新增或編輯方案實現，在詳細設計文件中呢，就為「新增方案」和「編輯方案了」。時序圖，需求文件中，時序圖不需要考慮失敗情況，失敗情況在事件流裡面表現，詳細設計文件時序圖就是乙個考慮各種情況各種走向完整的圖。
最後總結，剛開始編寫相關文件比編碼實現功能還累，需要不停的切換角度，絞盡腦汁的組織語言和設計功能，但經過一段時間的編寫，感受到完成功能設計的成就感，想著這就是使用者期望的功能，也對整個軟體開發過程更加熟悉，應在今後開發功能前多思考，想清楚了再進行實現。
編寫專案需求文件
color darkred b 需求分析文件要點 b color color darkred 以下需求文件要點適合瀑布式開發過程。color 一般在最前面有編寫者及文件版本和變更記錄等。color darkred b 引言 b b 編寫目的 b color 術語及縮寫解釋 預期的讀者和閱讀建議 co...
專案評審文件的編寫
個人所得稅計算需求 tax srs 001 輸入 引數1 稅率列舉型別，取值範圍 5 10 15 引數2 個人收入，1600 100000000000 處理過程 全月應納稅所得額 稅率 1600 2500元的部分 5 2500 3500元的部分 10 3500 100000000000元的部分 15...
如何編寫專案發布文件
寫發布文件的原則就是要寫的盡可能詳細，需求是什麼，實現了哪些功能，發布時的步驟，注意事項，聯絡 發布日期等，最好是傻瓜式的，標準就是 只要按照發布文件寫的進行操作就算在大街上隨便抓個人過來部署都不會出問題。這才是好的部署文件，很多人在寫發布文件的時候很敷衍，基本用的都是模版，大綱都是有的，然後內容大...