先決條件（一）問題定義和需求分析
文章目錄
工欲善其事必先利其器
本章主要論述在軟體建立之前所要做的準備工作，對於建築業來說，專案的成敗往往在開
工前就已經決定了。如果基礎打得不好，或者專案計劃進行得不充分，你所能做的最多也就是
防止計劃失敗，根本談不上做好。如果你想做一件精美的首飾，那麼就得用鑽石作原料。如果
你用的是磚頭，那你所能得到的最好結果不過是塊漂亮的磚頭而已。
先決條件重要性
優秀程式設計師的一個突出特點是他們採用高質量的過程來建立軟體。這種過程在計劃的開始、中間和末尾都強調高質量。
如果你只在一個計劃即將結束時強調質量，那你注重的只是測試。當某些人一談起軟體質量時，他們首先想到的便是測試。然而，事實上測試只是全部質量控制策略的一部分。而且並不是最重要的部分。測試既不能消除在正確方向上的錯誤工作，也不能消除在錯誤方向上的正確工作的錯誤，這種錯誤必須在測試開始之前就清除掉，甚至在建立工作開始之前就要努力清除掉它們。
所有的計劃都是帶有明確的指向性的。
造成準備不足的原因
準備工作是非常重要的，所以在程式設計之前，請先剋制自己程式設計的慾望，需要考慮的兩點，這是非常重要的：
- 第一，閱讀一下下一部分工作的內容提示，或許你會從中發現一些你沒想到的問題。
- 第二，要注意自己的問題。只要建立過幾個大的程式，你就會明白強調準備工作的必要性。不要忘記曾經的經驗教訓
做準備工作的論據
求助於邏輯推理
進行有效程式設計的關鍵之一就是認識到準備工作是非常重要的。在進行一項大的專案之前，事先做好計劃是明智的。專案越大，需要的計劃工作量也越大，從管理人員的角度來看，計劃是指確定一個專案所需要的時間、人力、物力和財力。從技術人員的觀點來看，計劃是指弄清楚你想要幹什麼，以免做出錯誤的工作而徒耗精力與錢財。有時候你自己並不十分清楚自己想要的到底是什麼？起碼剛開始是這樣。這時，就會比清楚知道使用者需求的人要付出更多努力，但是，這總比做出一件錯誤的東西，然後把它扔掉，再從頭開始的成本要低得多。
建造一個系統之前，弄清楚怎樣開始和如何建造它也是非常重要的，你當然不希望在完全沒有必要的情況下，浪費時間與錢財去鑽死衚衕而白白增加成本。
求助於類比
在你把聖誕樹立起來後，你才會開始裝飾它，在沒有修好煙囪之前你也不會點燃爐火的，同樣，也沒有人會打算在油箱空空的情況下踏上旅程，在軟體開發中，你也必須按照正確的順序來進行。
程式設計師處於軟體開發食物鏈的最後一環。結構設計吃掉需求分析；詳細設計者以結構設計者為食，而他自己又成為編碼者的食物。
如果需求定義遭受了汙染，那麼這又會影響結構設計，而這將最終影響建立活動。這將導致程式設計師們脾氣暴躁而營養不良，同時生產出遭受嚴重汙染而充滿缺陷的軟體。
求助於資料
將錯誤斬斷至最開端，隨著開發的不斷進行，恢復錯誤的代價也會越高。
問題定義先決條件
在進行建立工作之前你要滿足的第一個先決條件，便是必須弄清楚你想要解決的問題是什麼。
問題定義應該從使用者的觀點出發，使用使用者的語言進行定義，用通俗易懂的語言表述清楚。
需求分析先決條件
為什麼要有正式的需求
IBM、GTE、TRW 的資料表明．修正在總體結構階段發現的需求錯誤，將比當時就發現並修正的成本要高出 5 倍，如果是在編碼階段，要高出 10 倍，在單元或系統測試階段，高 20 倍，在驗收測試階段，高 50 倍，而在維護階段，竟要比原來高出多達 100 倍！在較小規模的計劃中，在維護階段修正錯誤的放大因子可能是 20 而不是 100，因為這時管理費用較低。但無論如何沒有人願意從自己的收益中拿出這筆錢來。
穩定需求的神話
使用者一旦接受了寫好的需求檔案，便再也不會提出更改需求，這簡直是太好了。然而事實上，在實際專案中，使用者在程式碼寫出來之前，往往並不能確切可靠地描述出他想要的到底是什麼，這倒並不是說使用者是一種低階生物。正如隨著工作的進行，你對其理解越來越深刻一樣，使用者對自己想要的東西，也是隨著專案的進行而越來越清楚的，這也是要求變動的主要原因。一個從不變更要求的計劃，事實上是一個對使用者的要求不予理睬的計劃。
在建立階段如何對付需求變化
用本部分後面的檢查表來評估你的需求分析質量
如果覺得方向不對請立刻回到上一步，並重新執行，切莫南轅北轍。
讓每個人都知道由於變化需求所付出的代價
用時間進度和成本估計來評估變化的必要性。
建立一套更改控制過程
共贏的處理方式，按照制定規則下的方式去處理，統一標準。
用開發的方法來容納變動
增量效應，每次做一點點改動，使大家都能接受。
放棄專案
需求古怪，不符合上面的標準，可放棄
檢查表
需求內容
-
系統的所有輸入都定義了嗎？包括它們的來源、精度、取值範圍和頻率？
-
系統所有的輸出都定義了嗎？包括它們的目標、精度、取值範圍、頻率和格式？
-
所有的報告格式都定義了嗎？
-
所有的硬體與軟體介面都定義了嗎？
-
所有的通訊交介面都定義了嗎？包括握手、錯誤檢查以及通訊約定？
-
是否從使用者的觀點出發，定義了所有必要操作的反應時間？
-
是否定義了時間問題，如處理時間、資料傳輸率以及系統吞吐能力？
-
是否對使用者所要求完成的任務部作出了規定？
-
每項任務所需用到和產生的資料都規定了嗎？
-
規定保密級別了嗎？
-
規定可靠性了嗎？包括軟體出錯的後果、在出錯時要保護的至關重要的資訊、以及錯誤測試和恢復策略。
-
規定所需最大記憶體了嗎？
-
所需最大儲存容量規定了嗎？
-
對系統的維護性是否作出了規定？包括系統對執行環境、精度、效能以其與其它軟體的介面等方面變化的適應能力規定了嗎？
-
是否規定了相互衝突的設計之間的折衷原則，例如，在堅固性與準確性之間如何進行折衷？
-
是否制定了系統成敗的標準？
關於需求的完善性
- 在開發開始前暫時得不到的資訊是什麼？是否規定了不夠完善的區域？
- 需求定義是否已經完善到了可以成為軟體標準的地步？
- 需求中是否有哪一部分令你感到不安？有沒有根本不可能實現，而僅僅為了取悅老闆和使用者才加進來的內容？
關於需求的質量
- 需求是否是用使用者的語言制定的？使用者也這樣認為嗎？
- 需求中是否每一條之間都儘量避免衝突？
- 需求中是否注意了避免規定設計工作？
- 需求在詳細程度方面是否保持了一致性；有沒有應該更詳細些的要求？有沒有應該更
簡略些的？ - 需求是否明確得可以分為一些獨立的可執行部分，而每一部分又都很明瞭？
- 是否每一條都與問題和答案相關？是否每一條都可以追溯到產生它的環境中？
- 是否每一條需求都可以作為測試依據？是否可以針對每一條進行獨立測試以確定是否滿
足需求？ - 是否對可能的改動作出了規定？包括每一改動的可能性？
關於需求定義的進一步閱讀
以下是一些給出瞭如何進行需求定義的書：
DeMarco, Tom 《 Structured Analysis and Systems Specification：Tools and Techniques 》Englewood Cliffs，N.J：Prentice Hall，1979，這是關於需求定義的經典著作。
Yourdon，Edward 《Modern Structured Analysis》 New York：Yourdon Press，1989，這本新書論述了許多進行需求定義的文字和圖表工具。
Hatley，Derek J 和Imtiz A． Pirbhai 《Strategies for Real－Time system Specification》Newyork :Dorset house，1988。這是一本替代 DeMarco 或 Yourdon 書的最佳選擇。它重點論述了實時系統，並把 DeDarco 和 Yourdon 提出的圖表法擴充套件到了實時系統中。
Shlaer，sally 和 Stephen Mellor《Object Oritented System Analysis－Modeling the World in Data》Englen wood Cliffs，N.J： Prentice Hall，1988。本書討論了面向物件設計中的需求分析。
IEEE Std 830－1984（Guide for Software Requirements Specifications） in IEEE 1991。這份文獻是 IEEE 為編制軟體開發需求定義制訂的指導性論述。它描述了需求定義中應該包括的內容並給出了幾個例子。
Gibson，Elizabeth《objects－Born and Bred》Byte，1990 10:245－54。這篇文章是關於面向物件需求分析的入門書。