軟體設計中，如何將需求變成概要設計再到詳細設計，如何把業務領域相關的需求變成實際計算機能處理的任務？

1樓：子正

使用者需求到計算機世界的轉換實際上有兩大步。第一步是在需求規格說明書中完成的。使用者需求的凝固化對應著使用者需求說明書，而它在計算機世界裡的對映形式（僅從使用者介面ＵＩ的角度看去）就是軟體需求規格說明書。

這份軟體需求規格說明書，用計算機的可實現模式描述了整個需求的實現，也就是怎樣用計算機能夠表達的方式（一般而言指各種窗體，窗體上的控制項，窗體的切換規則）來對需求建模。這是第乙個模型。

這個模型的各種描述，各種規則方面的定義，會進一步催生出一組由UI直接規定的軟體邏輯系統的外部呼叫介面描述。這個呼叫介面，構成了概要設計的頂層。概要設計要在邏輯空間對整個系統進行建模，用一組彼此間通過協議或者呼叫關係的實體物件來支撐上面的呼叫介面。

這些實體物件中的每乙個都不得不定義一組外部介面，或者物件間連線協議。這些東西就構成了概要設計的全部。

簡單的說，概要設計就是用一組結構化的物件來支撐軟體需求規格說明書所必須實現的介面。兩組介面，就構成了概要設計。這是轉換的第二大步。

大多公司，大部分軟體的設計工作，進行到上一步已經可以轉入編碼了。詳細設計，我的工作經歷中還幾乎從未接觸過，但從我的專案經驗看，需要補充完善如下部分：第一，資料字典（SJ20778有關SDD的部分的描述也提到了這個概念）。

需要對專案中的關鍵資料項進行定義，為後續設計提供一組權威的參考源。第二，是關鍵流程或複雜流程的行為圖繪製。你需要描述一些重要流程的動態細節，UML的序列圖或者互動圖就是這個用途的。

一般領導看到軟體人員在畫序列圖，就知道編碼工作已經將要著手進行了；或者研發人員遇到了乙個難題，正在借助這種設計工具進行拆解。

這方面的知識，一般在進入乙個較規範的軟體公司（通過某種標準化體系），走完兩三個專案就可以大致掌握。在工作經歷以外，UML是乙個很好的範例。