## 第1章 歡迎進入軟件構建的世界 　 > checklist for Requirements ### –核對表：需求 這張需求核對表包含了一系列的問題–問問自己項目的需求工作做得如何。本書并不會告訴你如何做出好的需求分析，所以列表里面也不會有這樣的問題。在開始構建之前，用這份列表做一次“心智健全”檢查，看看你的地基到底有多堅固–用“需求里氏地震”來衡量。 并不是核對表中所有的問題都適用于你的項目。如果你做的是一個非正式的項目，那么你會發現有些東西根本就不需要考慮。你還會發現一些問題你需要考慮，但并不需要做出正式的回答，如果你是在做一個大型的、正式的項目，你也許就要逐條考慮了。 ### 針對功能需求 - 是否詳細定義了系統的全部輸入，包括其來源、精度、取值范圍、出現的頻率等？ - 是否詳細定義了系統的全部輸出，包括目的地、精度、取值范圍、出現頻率、格式等？ - 是否詳細定義了所有輸出格式（WEB頁面、報表等）？ - 是否詳細定義了全部外部通信接口，包括握手協議、糾錯協議、通信協議等？ - 是否列出了用戶想要做的全部事情？ - 是否詳細定義了每個任務所用的數據，以及每個任務得到的數據？ ### 針對非功能需求（質量需求） - 是否為全部必要的操作，從用戶的視角，詳細描述了期望響應時間？ - 是否詳細描述了其他與計時有關的考慮，例如處理時間、數據傳輸率、系統吞吐量？ - 是否詳細定義了安全級別？ - 否詳細定義了可靠性，包括軟件失靈的后果、發生故障時需要保護的至關重要的信息、錯誤檢測與恢復的策略等? - 是否詳細定義了機器內存和剩余磁盤空間的最小值？ - 是否詳細定義了系統的可維護性，包括適應特定功能的變更、操作系統的變更、與其他軟件的接口的變更能力？ - 是否包含對“成功”的定義？“失敗”的定義呢？ ### 需求的質量 - 需求是用用戶的語言書寫的嗎？用戶也這么認為嗎？ - 每條需求都不與其他需求沖突嗎？ - 是否詳細定義了相互競爭的特性之間的權衡—例如，健壯性與正確性之間的權衡？ - 是否避免在需求中規定設計（方案）？ - 需求是否在詳細程度上保持相當一致的水平？有些需求應該更詳細地描述嗎？有些需求應該更粗略地描述嗎? - 需求是否足夠清晰，即使轉交給一個獨立的小組去構建，他們也能理解嗎？開發者也這么想嗎？ - 每個條款都與待解決的問題及其解決方案相關嗎？能從每個條款上溯到它在問題域中對應的根源嗎？ - 是否每條需求都市可測試的？是否可能進行獨立的測試，以檢測滿不滿足各項需求？ - 是否詳細描述了所有可能的對需求的改動，包括各項改動的可能性嗎？ ### 需求的完備性 - 對于在開始開發之前無法獲知的信息，是否詳細描述了信息不完全的區域？ - 需求的完備度能否達到這種程度：如果產品滿足所有的需求，那么它就是可接受的？ - 你對全部需求都感到舒服嗎？你是否已經去掉了那些不可能實現的需求—那些只是為了安撫客戶和老板的東西？ ### 中文要點： - 軟件構建是軟件開發的核心活動;構建活動是每個項目中唯一一項必不可少的工作. - 軟件構建的主要活動包括:詳細設計,編碼,調試,集成,開發者測試(包括單元測試和集成測試). - 構建也常被稱作”編碼”和”編程”. - 構建活動的質量對軟件的質量有著實質性的影響. - 最后,你對”如何進行構建”的理解程度,決定了你這名程序員的優秀程度. ### English Key Points： - Software construction the central activity in software development;construction is the only activity that’s guaranteed to happen on every project. - The main activities in construction are detailed design, coding, debugging, and developer testing. - Other common terms for construction are “coding and debugging” and “programming.” - The quality of the construction substantially affects the quality of the software. - In the final analysis, your understanding of how to do construction determines how good a programmer you are, and that’s the subject of the rest of the book.