[計算機]軟件需求復習提綱(參考版)
2025-01-12 15:25本頁面
【正文】 。 二十、 需求跟蹤機制將單個需求和其他系統(tǒng)元素之間的依賴關系和邏輯聯(lián)系編寫成 文檔 ，這些元素包括各種類型的其他需求、業(yè)務規(guī)則、系統(tǒng)體系結構和其他設計組件、源代碼模塊、測試用例以及幫助文件等。 f) 包含的每一個需求變更必須都能追溯到一個已獲得批準的變更請求。 d) 絕不能修改或刪除變更請求的原始文本。 b) 對于未獲批準的變更，除可行性研究之外，不應再做其他設計和實現(xiàn)工作。 變更控制策略是很有用的 ： a) 所有需求變更都應遵循 統(tǒng)一的 控制過程。 c) 將已批準的變更傳達給受此影響的所有人員。 十九、 對待軟件項目 變更 管理必須確保做到以下幾點： a) 在提交提議的需求變更之前要對其進行仔細的評估。 ? 需求實現(xiàn)的優(yōu)先級。 ? 需求涉及的產品版本號。 ? 創(chuàng)建需求的理由。 ? 需求狀態(tài)。 ? 負責確保該需求得到滿足的人員。 ? 需求的當前版本號。 e) 保持產品交付日期不變，但在質量 上打些折扣。 c) 短時間的突擊加班，最好是有償加班。 對提出的新需求或對已變更的需求，項目的響應方式有多種： a) 推遲實現(xiàn)優(yōu)先級低的需求。 d) 跟蹤基線中需求的狀態(tài)。 b) 保持項目規(guī)劃與需求之間的一致。 敏捷開發(fā)的基本原理在于認為軟件變更既是不可避免的也是合乎需要的。 突發(fā)型項目的需求 ： 由于突發(fā)型和快速變動的項目變得流行，所以產生了各種敏捷開發(fā)方法，這些方法強調將可用的功能快速地交付給用戶使用。 技能水平對項目的成功或失敗有著至關重要的影響，那么實踐經驗就可以減少在一個零起點項目中第一次應用用例的風險。 需求評審包括非正式評審和正式評審 ? 非正式評審方法包括： ? 同級桌面檢查 (peer deskcheck) ? 輪查 (passaround) 7 ? 走查 (walkthrough) ? 正式評審會生成一份報告，報告中指明具體材料、評審人員以及評審團隊認為產品是否可以接受，主要提交對發(fā)現(xiàn)的錯誤和提出的問題的總結。 ? 需求的表示在所有地方都是一致的。 ? 從系統(tǒng)需求、業(yè)務規(guī)則或其他來源中正確地推導出軟件需求。這個模型表明，驗收測試以用戶需求為基礎；系統(tǒng)測試以功能過性需求為基礎；系統(tǒng)測試以系統(tǒng)的體系結構為基礎?？蛻艨偸琴x予那些能給他們帶來最大的業(yè)務利益或易用性利益的需求最高的優(yōu)先級。 ? 如果正在從事時間盒式 (timeboxed)開發(fā)或增量開發(fā)，那么設定優(yōu)先級就特別重要，因為在這 些開發(fā)中，交付進度安排得很緊迫并且不可改變。這些特性被稱為軟件質量屬性，是系統(tǒng) 非功能 (也叫非行為 )性需求的一部分 十三、 （略） 十四、 為什么要設定需求優(yōu)先級 ? 設定 優(yōu)先級 是一種行之有效的方法，可以處理在 資源有限 的情況下，應該優(yōu)先滿足哪些需求 。分析人員需要向其他涉眾解釋所用的模型和符號的用途。 十一、 與 文本 相比，要交流某些類型的信息，使用 示意圖 的效率可能更好。 ? 圖形化模型 這些模型可以描繪轉換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關系、邏輯流或者對象類及其關系。 十、 需求開發(fā)的最終成果是，在客戶和開發(fā)人員對所要開發(fā)的產品達成共識后，編寫的具體的 需求 文檔。 ? 如果接到訂單 5 天后，賣方還不能發(fā)送客戶訂購的商品，則表明該商 品延遲交貨。 比如表 購買商品數(shù)量不同折扣也不同的例子 推論 (inference
試題試卷相關推薦
鄂ICP備17016276號-1