用這個檢查表，你可以檢驗一下在建立工作時，你
的工作基礎是否牢固可靠。
並不是表中所列出的每乙個問題都適用於你的專案。如果你正在從事乙個非正式專案，你
會發現根本不需要考慮這個問題，你也會在其中發現一些需要考慮但並不需要回答的問題。但
如果你正在從事乙個大型的正式專案，我們建議你最好還是仔細考慮每乙個問題。
需求內容
· 系統的所有輸入都定義了嗎？包括它們的**、精度、取值範圍和頻率？
· 系統所有的輸出都定義了嗎？包括它們的目標、精度、取值範圍、頻率和格式？
· 所有的報告格式都定義了嗎？
· 所有的硬體與軟體介面都定義了嗎？
· 所有的通訊介面都定義了嗎？包括握手、錯誤檢查以及通訊約定？
· 是否從使用者的觀點出發，定義了所有必要操作的反應時間？
· 是否定義了時間問題，如處理時間、資料傳輸率以及系統吞吐能力？
· 是否對使用者所要求完成的任務都作出了規定？
· 每項任務所需用到和產生的資料都規定了嗎？
· 規定保密級別了嗎？
· 規定可靠性了嗎？包括軟體出錯的後果、在出錯時要保護的至關重要的資訊、以及錯誤
測試和恢復策略。
· 規定所需最大記憶體了嗎？
· 所需最大儲存容量規定了嗎？
· 對系統的維護性是否作出了規定？包括系統對執行環境、精度、效能以其與其它軟體的
介面等方面變化的適應能力規定了嗎？
· 是否規定了相互衝突的設計之間的折衷原則，例如，在堅固性與準確性之間如何進行折
衷？· 是否制定了系統成敗的標準？
關於需求的完善性
· 在開發開始前暫時得不到的資訊是什麼？是否規定了不夠完善的區域？
· 需求定義是否已經完善到了可以成為軟體標準的地步？
· 需求中是否有哪一部分令你感到不安？有沒有根本不可能實現，而僅僅為了取悅老闆和
使用者才加進來的內容？
關於需求的質量
· 需求是否是用使用者的語言制定的？使用者也這樣認為嗎？
· 需求中是否每一條之間都盡量避免衝突？
· 需求中是否注意了避免規定設計工作？
· 需求在詳細程度方面是否保持了一致性；有沒有應該更詳細些的需求？有沒有應該更
簡略些的？
· 需求是否明確得可以分為一些獨立的可執行部分，而每一部分又都很明了？
· 是否每一條都與問題和答案相關？是否每一條都可以追溯到產生它的環境中？
· 是否每一條需求都可以作為測試依據？是否可以針對每一條進行獨立測試以確定是否滿
足需求？
· 是否對可能的改動作出了規定？包括每一改動的可能性？
Jira 流程檢查單
專案流程執行檢查單 檢查項issue數量 檢查內容 結果結果說明 改進措施 指派人解決時間 需求br 1.是否是業務的原始需求 不全是2.是否有關聯的prd 不全是3.狀態是否正確的，包括子任務done後，該需求關閉 是prd 1.是否是bt分析後的產品需求 是2.是否在confluence上有新功...
概要設計檢查單
是否描述並驗證了記憶體使用估算和記憶體管理？是否對每一模組給出了儲存空間和速度限制？是否說明了字串處理策略？是否提供了對字串占用空間的估計？所提供的錯誤處理策略是不是一致的？是否對錯誤資訊進行了成套化管理以提供乙個整潔的使用者介面？是否指定了堅固性級別？有沒有哪一部分結構設計被過分定義或缺少定義了？...
《測試停止檢查單》
1.所有功能需求都有1條或多條功能測試用例與之對應 2.建立了需求與用例追溯表，需求覆蓋率已達到100 3.所有設計需求都已實現並測試通過 4.所有用例都測試通過，測試記錄已保留 5.所有要解決的bug都已解決，並回歸完成 6.延期的bug已通過評審專家的影響評估，並在可接受區 7.缺陷庫上的所有b...