如何寫好軟件說明書(編輯修改稿)
2025-08-30 11:24 本頁面
【文章內容簡介】 求如果說產品將要支持什么也是不可證實的。高質量需求說明的特征 一個完整的SRS不僅是包括長長的功能性需求列表，還包括外部接口描述和一些諸如質量屬性，期望性能的非功能性需求。下面描述了高質量的SRS的一些特性?！ ⊥暾翰粦撨z漏要求和必需的信息。完整性也是一個需求應具備的。發(fā)現缺少的信息很難，因為根本不存在。在SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西?！ ≡谛枨蟪橄髸r，相對于系統功能，你過多的注意用戶的業(yè)務，將導致在需求的全局觀和引進不是真正必需的需求上顯得不足。在需求抽象上，應用用例方法會發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性?！ ∪绻阒酪讶鄙僖恍┬畔?，使用TBD（to be determined）標準標志可以突出這些缺陷，當你在構建產品的相關部分時，就可以從一個給定的需求集中解決所有的缺陷。 一致性：一致性需求就是不要于其他的軟件需求或高級別的系統（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開發(fā)開始前得到解決。只有經過調研才能確定哪些是正確的。修改需求時一定要謹慎，如果只審定修改的部分，沒有審定于修改相關的部分，就可能導致不一致性。 可修改性：當每個需求的要求修改了或維護其歷史更改時，你必須能夠審定SRS。也就是說每個需求必須相對于其他需求有其單獨的標示和分開的說明，便于清晰的查閱。通過良好的組織可以使需求易于修改，如：將相關的需求分組，建立目錄表，索引，以及前后參考（照）。可追蹤：你應能將一個軟件與其原始材料相對應，如高級系統需求，用例，用戶的提議等。也能夠將軟件需求與設計元素，源代碼，用于構造實現和驗證需求的測試相對應。可追蹤的需求應該具有獨立標示，細密和結構化的編寫，不應過大，不應是敘述性的文字和公告式的列表?！ ⌒枨筚|量的評審 這些有關需求質量的特性的描述在理論上都是非常好的，但一個好的需求到底是個什么樣子的呢？為了體現得更切合實際，我們做個小練習。下面有幾個從實際的工程選出的需求，依據上面的質量標準，評估每個需求，看看有什么問題，然后用更好的方式重寫。我將對每個例子都提出自己的分析和改進的建議。也歡迎你提出不同的見解。我所占優(yōu)的只是我知道每個需求的出處。因為你我都不是真正的客戶，我們只能猜測每個需求的意圖?！ ±?．“產品應在不少于每60秒的正常周期內提供狀態(tài)信息” 這個需求是不完整的：狀態(tài)
環(huán)評公示相關推薦
鄂ICP備17016276號-1