軟件開發設計規範書的撰寫

整 個軟件開發過程是一個至關複雜的流程，並非簡單的靠幾個設計工程師本身在那邊寫軟件就完，而是要有從頭至尾，包括不少人，不一樣專家，不一樣的專業，不一樣的 知識放在一塊兒，最後才形成一個完善的軟件產品。從決定開始，到計劃、設計，最後到寫程序、執行，而後還有測試、糾錯、保證穩定、發行、部署、調試，整個過 程是一個至關長的過程，並非一個簡單的程序。要爲了保證軟件的質量，可以達到客戶知足和知足市場的要求，很要緊的工做，早期工做作的越是完善、仔細，避 免後面的工做，因爲前面不完善形成的返工，形成的浪費，起到關鍵性的做用。你們可能在網上讀到在美國軟件項目管理的權威，寫過不少關於軟件管理方面的書， 頗有名一個理論就是說他作過不少研究和調查，發現早期的工做要是沒有作好，而形成後面工做的返工，帶來的浪費是巨大的。有相似這樣的圖表，他作出的結論， 若是在設計階段出現了問題，在設計階段若是你沒有及時找到和糾正的話，到執行階段才發現，你會看到三條不一樣的曲線，越是早期的錯沒有發現，最後因爲要返工 而形成的代價費用愈來愈高，若是前面沒有問題，到最後只是發現半個糾錯，花費的代價至關低，由於你是糾錯，而後從新測試就完了。但是若是執行的時候，程序 編程編錯了，後來從新編，從新測試，這個費用相對來講就要高。若是是設計的時候出現錯誤，因爲對需求管理沒有管理好，客戶和市場的要求都錯了，開發出來的 東西徹底到後面從新執行、從新糾錯的話，會看到這個曲線，幾乎是幾何形上升的，成倍的費用的增長。可以保證控制產品開發過程當中間的費用增長，早期工做完 善，作設計的時候，越早作的越完善，對控制後面的消耗起的做用是很是大的。

從這個方面講，我早上舉的例子造房子同樣，造房子的藍圖，對蓋一個房子的重要性，對早期設計的完善做用也是同樣的。

什麼是設計規範書。你們聽過不少不一樣的名稱，叫法也不同，究竟是什麼東西。首先它是總結一個軟件功能和性能、使用方案的總結書，是描述一個產品， 到底該爲客戶提供什麼服務，起到什麼樣的做用，到底能夠完成什麼任務，從這個角度對軟件產品作一個總結,是提供軟件功能和性能以及使用方案的總結。也就是 說，他應該包括的內容是向開發人員很詳細的描寫清楚，這個軟件到底應該怎麼工做，他使用方案的總結，他的功能性的總結，而不該該包括產品具體的設計的構 架，到底怎麼執行，怎麼設計，這方面內容實際上是有不的文檔或者文件去總結的。早上也提到，做爲開發團隊人員，當設計經理、項目經理把軟件功能定完之後，真 正產品怎麼開發，是應該由設計團隊人員去作。在微軟有的比較大型的團隊，咱們有所謂的設計師，具體開發也開發團隊的領隊和開發人員，他們每一個人根據功能的 描寫總結出來具體設計的執行方案，這個實際上是不該該寫在設計規範書裏的，因此要理解清楚，設計規範書是描寫產品對客戶怎麼用，而不是描寫這個產品具體開發 邏輯怎麼執行，這個是和開發有關係的。做爲設計規範書是項目經理的工做，就是要把這個產品的功能描寫清楚。它該包含的內容和不應包含的內容不要搞混亂。

影響設計規範書的因素不少，首先最重要的是功能需求，客戶對使用軟件有它必定的要求，這個軟件應該提供什麼樣的服務，該完成什麼樣的任務，這方面就 叫作功能需求。實際上是有不一樣的好幾個因素來影響整個功能需求的，對市場競爭的分析，咱們競爭的對手他的產品有什麼樣的功能，從而得出咱們產品應該也有什麼 樣的功能，甚至功能比他更好，這是對功能需求的起影響因素的。還有客戶之間的回饋，他說我這個產品爲個人行業作工做，這個和明顯是客戶具體的要求。還有就 是用戶解決問題的要求，好比說他說我不在意你這個產品怎麼開發，無論你之前的產品，或者你開發的產品之前有什麼功能，因爲要解決新的問題，必須加進這樣的 功能。還有用戶所謂的使用方案，他真正解決問題，使用的方案流程是怎樣的，因爲他商業之間運行有直接關係，若是客戶商業流程決定是這樣的運做的順序，你軟 件設備也應該要配合客戶使用方案設計。全部這些是最關鍵的因素影響功能需求，功能需求也是第一個最要緊的影響到設計規範書該描述清楚的，解決的什麼樣的問 題。

除此以外是性能需求，光描寫說我這個軟件按一個鍵能夠寫一個數字還不夠，若是是客戶要求我按一個數字，在0.3秒以內寫出來，或者是我按鍵之後印出 五百萬字來，他顯示數據的速度怎麼樣，他的要求也是影響到設計規範書的。他包括整個系統的要求，若是大型的軟件，運行的系統，什麼樣的硬件，什麼樣的內存 存什麼樣的網絡，全部這些對性能的需求都起到影響。他的運行的環境，究竟是有沒有兼容不一樣的操做平臺，不一樣的操做平臺之間不一樣。對軟件的功能也是起到影響 的，還有安裝部署，特別是大型的系統，由於我在搞工業控制不少年也知道，安裝部署的要求，軟件在實驗室完成跑到真正大型的工廠裏，徹底是另一回事。環境 的安裝部署要求，在很髒的環境裏，邊上有各類干擾的因素，在這樣的運行這樣的軟件，性能是否是有保證，保證不會死機，數據不會出現什麼錯誤，或者出現錯誤 有什麼樣的反應，這些都會影響到開發軟件的要求。還有是質量要求，有一部分是能解決的，還有一部分是不能解決的，中間的質量要求是碰到什麼狀況可以對付， 碰到什麼狀況怎麼應付，這些不一樣的用戶都會有詳細的要求，這些都是規範設計書應該總結的內容。

除了這些之外，還有非功能的要求，可是在設計的時候非得考慮到，包括地區、行業，甚至國家在某一個行業裏的標準。象在歐美市場上，每一個行業都有本身 的標準。若是你是設計軟件，爲某一個行業設計，裏面軟件設計接口標準，可能使用數據規範，對於不少標準，若是你是對那些不熟悉，或者是不瞭解，甚至是用錯 的話，開發出來不符合那些客戶要求就要改。這些和真正產品的功能毫無關係，但是要爲了保證在之後產品開發出去避免這樣的錯誤，因爲這樣的錯誤從新返歸，就 要把這些要求瞭解清楚。技術還有技術開發的侷限，你想這樣開發，你想提供這樣的功能，可是首先得了解，目前客戶所用的設備的硬件，或者他的運做的操做系統 環境，有沒有某些侷限，你想開發性能的時候他沒有辦法達到，把這些事情弄很清楚的話，避免和客戶講不清楚的爭論。在描寫功能的時候，這個功能有什麼樣的能 力，沒有什麼樣的能力，描寫的很清楚。

還有對時間的依賴，對外在因素的依賴，這裏面是須要時間的。項目管理上所謂三角形的定理，有這麼多時間，你有這麼多資源只能開發出這麼多功能。若是 把你的時間砍掉一半，其餘因素不變的狀況下，絕對不能按時間、質量研發出來。這些都會影響到你設計規範書的撰寫，你要寫得很清楚，軟件開發哪些能力我是可 以完成的，哪些是不能夠完成的。還有可用性的需求，軟件爲了要贏得客戶的心，贏得市場的心，很要緊的一點，不光是把軟件開發出來你們能夠用，客戶用了不會 以爲很混亂，仍是很鬧心，仍是用起來很順手，這裏面的可用性，這些東西也是很重要。什麼因素決定可用性，用戶的特色，不一樣的用戶，不一樣的使用者，也會決定 軟件開發應該按照適合他們的要求。開發出來的軟件是給一些專門的設計人員用的，那些人受太高等教育，都是很熟悉的，和你開發出來給爺爺奶奶用，這裏邊不一樣 的客戶，都有專門的特性，因此在微軟把不一樣的使用者，分紅不一樣類型的組羣，這裏的要求怎麼回事。全部這些都是影響到可用性需求。整個設計規範書在描寫完善 的軟件過程，這些都要考慮到。你不考慮的，不在意的就去寫軟件，等你開發出來這些搞錯的話，必定影響軟件最後的質量。

軟件規範書的讀者，規範書是幹什麼的，爲誰而寫？做爲開發管理人員項目經理到底作什麼工做。第一個是給開發團隊用的，構架設計、開發執行的計劃。開 發團隊是第一位讀者，須要拿這個來蓋房子。除此之外，測試團隊，在定測試計劃的時候，也是根據你對功能的描述。因此若是一個軟件裏調出一千多個功能，就要 定一千多，甚至三千、五千相對應的測試方案。測試團隊也是設計規範書的讀者。文檔團隊，要讓客戶可以很方便的瞭解、熟悉你這個軟件的產品，很要緊一點你要 有所謂的專門使用手冊，若是軟件是推向市場的，給爺爺奶奶用，歷來沒有用過這個軟件的，看一個說明書怎麼樣能夠幫助這些沒有技術水平的人在很短的時間內用 這些軟件。文檔協做很重要，編輯的人也不懂計算機，只能描述這個產品，他們所須要的內容也是從這裏來的。可用性團隊，他們要用產品找一些客戶到內部進行調 查，他們怎麼設計測試，可用性的案例？他們也是要根據設計規範書的內容決定。最後就是市場營銷團隊，當你有一個完整的設計規範書，營銷產品的時候，當產品 完了之後向市場進行推銷的時候，營銷人員會比較清楚的瞭解，這個產品到底有什麼樣的功能，能夠完成什麼樣的任務，而後向廣大市場描寫這個產品有什麼好處。 因此你看到設計規範書通常是爲這麼多團隊，這麼多人服務的。還有給客戶領導，在你產品尚未開發以前，在你和客戶交流的時候，咱們在某一個產品，爲他們專 門設計的軟件，在開發以前，並非籤一個協議，告訴我寫一個東西，而後就開發了。開發以前若是有一個很完整的規範書，讓客戶從頭至尾把我整個開發的計劃了 解清楚，開發的內容，我要提供的功能，可以提供的，不能提供的寫的很清楚的話，他看了之後就會知道符不符合他的要求。幫助客戶瞭解整個開發的計劃，他給你 進行回饋，幫你作調整，領導能夠根據這個對整個項目進行跟蹤。若是你都寫清楚了，做爲企業的領導，能夠從高層次領導整個開發的計劃，跟你原來的計劃，定的 時間表能夠知道何時能夠完成。因此起一個很好的交流做用，幫助團隊和領導之間保持一致。

在寫規範書一般要通過什麼樣的步驟，作什麼事情能夠達到最後的結果？在你正在寫以前，首先須要肯定你要解決的問題，最要緊的是從市場需求來了解，我 這個軟件到底該作什麼，這個軟件是爲何樣人服務的，作什麼樣的事情。定出你所要的功能以前，首先先要了解使用方案，三步法，知道客戶的使用方案，從那個 得出你的需求究竟是怎樣的。而後根據體的需求總結，定出你要設計的功能究竟是哪些。由這些需求、總結定出這些功能，最後根據三步法設計功能。這樣你設計的 功能都是爲了解決客戶具體的使用方案，而不是設計的功能是毫無做用的。你不按照這樣的方法作，經常讓開發工程師本身隨意開發出一些功能，功能開發出來看起 來很不錯，咱們叫作很酷，但是不在客戶的使用方案裏起到具體的做用，能夠在某一個軟件的菜單上按一下能夠作一些什麼事情，但是客戶根本用不着這個，這種開 發出來是一個很大的浪費。讓功能的創建設計在瞭解使用方案的基礎上，由此得出的需求上就能避免浪費。這樣每一個開發出來的功能都是有目的的。

寫以前，在不少比較大型的、複雜的系統上，開發團隊但願可以有必定的時間作一些技術可行性的調查，先寫一個樣品。設計經理認爲我應該有這樣的功能， 但是這個開發團隊認爲說，你設計的功能可能不見得達到你這樣的要求，我要看在我現行的平臺上，用我現行的技術，可不能夠設計出你所要的技術。在以前先作一 個簡單的調查，看是否是可行。樣品作出來了，團隊花時間寫最後的規範書以前，在四面圍着玻璃窗的房間裏，把客戶請來，作調查。整個使用方案的流程，按這個 鍵能夠灌入這個數字，能夠起這個效果，你把這個不是真正的軟件，是一個虛假，甚至用圖象拼起來的，先把這個東西讓客戶用一下，看一下是否是符合你的要求。 他用了說很不錯，你就知道你的設計方案是對的，若是有50%認爲不符合本身的要求，你就知道你的設計方案出問題了。最後你才定下來寫規範書。規範書不是寫 完一次就完了，也是好幾個回覆，咱們先寫一個出版，把開發團隊人員叫來，開發團隊的領隊，測試師、工程師都叫來，你們一塊兒審覈，設計這個東西是否是合理 的。第一次出稿回來之後立刻推翻了，開發團隊說徹底是不合理的東西，沒有辦法開發，必定要從新設計。先有出版，作審覈，而後再寫正版。有一個回覆，能夠完 了之後這邊再倒回去，這是一個流程。我這邊寫出來重點，很是要緊一點，做爲咱們項目開發的領導，你會看到每個具體工做都是要時間的，都須要人去作。要定 一個項目開發計劃都沒有算時間，若是要來回走五遍，但是你只有一遍的時候，你的計劃必定要出錯。最後寫正版，而後審覈，所有經過你們簽字，說這是咱們能夠 開發的。在某些狀況下讓客戶簽字，客戶也贊成了說你這個設計徹底符合個人想法。若是前面的事情都作到家了，對你後面的事情是起到很大的做用。

提綱的內容，一般在微軟通常包括先寫一個前沿，或者梗概，用很是簡單的一小段解釋這是給領導看或者是給客戶看。你對產品開發高層次的理解是否是很清 楚，總結你所開發的產品軟件到底怎麼作，有什麼功能。你對一個產品的功能理解，是否是可以精簡到幾句話，不光你做爲一個項目經理能夠說出來，讓你開發團隊 全部成員都可以明確無誤的說出來，這是很是要緊的。特別是客戶要求，你這個文件給他讀的時候，能夠很清楚的知道，對客戶要求的理解是否是很清楚。等規範不 完的時候，最後回去作對照。看一下我原來定的總結是要完成這些任務，最後設計完之後，回去對照是否是跟原來的計劃同樣的。從高層次幫你指導整個開發方向應 該是怎樣的。

除了簡單開頭之後，要有一個比較詳細的總結，整個文檔的總結。不光是描述規範書的內容，其實還要幫助不少第一次讀規範書的讀者，可以有效的讀你的規 範書。有的規範書很長，很複雜，有各類各樣的符號標記，怎麼樣理解你用的這些符號。通常的總結包括做者、日期、版本，有時候好幾個版本放到內部網站中，你 能夠告訴他，應該看第三版，而不是第二版。這些內容都是幫助讀者瞭解，設計規範書中的版本改動的歷史是很是要緊的，由於在整個版本改動過程當中，雖然所有完 了，定稿你們簽字了，在真正實行的發現有些功能漏掉的，最後還要去加。你的產品開發完了之後，發現有問題，讓你的設計要改，做爲設計規範書要回去重寫。改 動的部分要很明確的標出來不一樣的，在前面的總結加一些版本該都歷史。這樣追蹤整個軟件在開發歷程過程當中，何時發生什麼問題，都會起一個很好的參照做 用。很大一個產品，並非一個設計規範書能夠解決的，有時候是好幾個、十幾個設計規範書，好幾個不一樣的項目經理一塊兒來作的，做爲一個客戶，光讀一本多是 不夠的，你要作一套，好幾本設計規範書，規範書之間他們相互的聯繫，你讀以前可能參照那本，或者讀這個之後，再讀那本，之間的參照的內容也要寫在規範書 裏。因此在文檔總結裏，把這些內容寫在裏面。

這個項目重要成員，項目總結，包括開發團隊的成員，開發團隊或者測試團隊聯繫方法。發現問題不知道該找誰，特別是團隊的領隊都要寫在前面，聯繫方 法。還有時間表的總結，你總的產品開發，大的里程碑，幾月幾號完成怎麼樣。還有對外部團隊的依賴因素，不少開發可能都要靠好幾個團隊向你提供一部分功能， 最後整合起來。在你產品作的時候，9月3號要完成的東西，可是8月30號我要讓別的團隊向我提供這些東西我9月3號就能完成，若是不能提供我9月3號就完 不成。全都寫清楚了，你才能知道。

在不少狀況下可能要寫一個開發的理由，爲何要開發這個軟件？特別是做爲一個公司開發不少不一樣的軟件下，做爲別的團隊或者領導，或者是市場營業經 理，可能先要了解你這個軟件是幹什麼的，在整個企業的戰略狀況下，整個戰略方向爲企業起什麼做用。不少產品在開發，技術多是相互交錯的，要講清楚爲何 這個團隊花這麼多錢、這麼多精力，開發這個技術，爲何不用別的團隊已經有的技術，或者相似的技術，他們要按照什麼樣的建議開發，全部的東西都要寫出來。 通常的內容，咱們作以下的解釋，開發的理由，若是我不開發這個，或者我用別人的，或者個人功能不開發，對公司長期企業的效果起什麼影響，對咱們市場競爭能 力帶來什麼影響。若是咱們不開發，咱們的競爭對手六個月以後開發出來，咱們的市場可能從第一位降到第5、第六，領導看了之後就會感受不同，你要用具體的 數字幫大家證實，爲何要開發這樣的功能。還有所須要的資源、消費，和不開發帶來費用比較也是很要緊的。我要開發什麼東西，我要花這麼多、精力、人和資源 的消費，但是我若是不開發，我市場損失是什麼，這就幫助領導或者客戶作決定，什麼狀況下多少錢、多少功能你該作的。對成功企業的影響，對整個市場的影響， 要開發不開發，或者如今開發幾個月後開發，這個時間是不一樣的。在描寫具體功能以前，先要講爲何要開發這些東西。要很清楚你開發的目標，咱們叫作遠景目 標。開發的目的是幹什麼，究竟是開發什麼樣的。爲何要開發，你要講清楚開發什麼樣的軟件。這是總結和列出來你要開發的遠景目標，歸根到底要完成什麼任 務，達成什麼目標。

撰寫內容，首先對公司企業戰略上的影響，市場上的影響，技術上、功能上，全部的東西從這些層次來描寫，咱們該完成什麼樣的任務。你在開發前把目標定 義清楚，後來幫助你作解決，什麼狀況下開發時用什麼技術，若是符合個人目標就作，若是不符合個人目標，到那時候作決定，有全面目標作了到那時候起到很大的 做用。

若是是爲單個客戶開發產品相對來講容易的多，通常狀況下你的產品是成千成萬人用。這時候就要考慮到，要照顧到不一樣的用戶，他們使用的產品能力不是一 樣的。對於不一樣層次的人使用者，對他們要達到的目標是什麼，都要寫清楚。你對這些作了總結，幫助你在後來作設計的時候，比較容易作出決定，你這個設計功能 該怎麼樣設計。每每這些功能寫和不寫沒有太大區別，最後軟件不起到什麼關鍵影響，但是因爲作了這些工做，你做爲設計人員，項目經理，逼迫你去思考這些問 題，若是事先這些問題都沒有想過，但願後來設計的軟件都能達到前面的功能是不可能的。若是你事先作了，作了思考，跟開發團隊商量了，作的這些都是有目的 的。

前面講的是比較高層次的總結，在你描寫真正開發的功能以前，就會講到很要緊的總結使用方案。客戶是如何用你的軟件解決他的問題的，誰來用，是什麼樣 的人，他們怎麼用法，他們使用軟件順序是怎麼樣的，描寫清楚。一般咱們是用講故事的方法，長三來上班，大概機器灌入一個數字，存了文檔，交給李四，李四存 了文檔，這樣用講故事的方式來描寫。還有很要緊的一點，你這樣的描寫，對測試團隊起到一個巨大的幫助。他測試的時候，內部測試團隊人員能夠把本身想象成一 個客戶，能夠按照你所描寫的使用方案，測試團隊來測試這個軟件。按照你所描寫的使用方案，按照順序進行測試。這個是對測試團隊設計他們的測試的方案起到很 大的做用。

從客戶使用軟件具體的使用方案總結出你的功能需求，他是這樣用的，由於張三打開機器要先按這個鍵，應該有一個輸出、輸入欄，灌數據，按了之後生成文 檔，正由於有這樣的使用流程，你的需求功能非得有這個鍵，有數個數據欄、有功能生成文檔。前面描寫的故事怎麼使用的，後來設計總結這些需求功能是符合你這 個故事的，保證你設計出來的功能是可以知足客戶按照這個步驟執行他的方案。咱們在微軟內部按照三步法開發軟件，實際上是有他的道理的，他要避免你開發出來的 功能是和前面使用方案毫無關係的，開發的時候形成浪費。知足具體的使用方案，從使用方案總結出來，由於長三按這個鍵關入數字是這樣的工做，作功能描述的時 候才描述細節，但首先要有這個鍵、數據欄。對無關緊要的功能要把它的優先順序寫持續。咱們全部的功能都有P一、P二、P3，定出來哪些東西是對客戶來講是 贏得市場最要緊的，非要開發，哪些是無關緊要，哪些是能夠放到下一代產品再開發。開發以前把這個事情都作好。

有了這些之後，你才描述具體的功能。這裏描寫如何使用，前面先講爲何要開發，如何開發，講了這個軟件爲何用，最後來說這個軟件是如何被客戶使用 的。這部分對全部的功能，全部的界面設計作一個詳細的敘述。對這部份內容能夠按照使用方案，從頭至尾把你使用的功能用圖象畫出來，能夠用文章總結。使用大 量的圖象很要緊，由於你圖象化之後，幫助測試人員怎麼樣測試，幫助開發人員開發出來的功能是要符合你設計的圖象。你畫出圖象，可讓可用性的工程師，根據 這個造樣品，而後找客戶作使用性的調查。這些東西幫助管理整個使用功能控制操做和質量。

除此之外，還有很要緊的一點，在設計過程當中間，經常有不少尚未解決的問題，在設計功能中間，並非說什麼東西解決了就能夠開發了，產品已經在開發 了，但是還有不少東西沒有解決。某些技術性的問題，我等別的團隊告訴我，或者有些技術性問題我等着調查，或者有些技術問題不知道，我買了硬件之後，作了平 臺之後作調試才知道，所謂這樣都不能遺漏，爲了防止這些問題都忘記，把這些問題也寫到規範書裏，有一個表格所有列到裏面，有這樣的方法就知道，整個開發過 程中，讓你能夠隨時回去看，這些沒有解決的問題是否是已經被解決了，幾月幾號該被解決，哪些還要被調查，哪些還要被進一步決定。把沒有解決的問題列出來， 作個總結，誰對這個問題負責，好比某個技術調查問題是開發團隊來作的，把這些該負責的人名字寫在裏面。目前他的狀態到底有沒有解決，有的已經解決或者是已 經正在調查，在一個表裏列出來，分紅三檔。有這樣一個總結很明顯的幫助你追蹤沒有解決的問題，在開發過程當中狀態是怎樣的。若是項目過大的話，甚至能夠把這 個內容拿出來，專門再寫一個額外的文件，一個專門的文檔專門來總結這樣的東西，給別的團隊的人看，不見得必定在設計規範裏，可是這些內容幫助你把該解決的 問題記下來，幫助過後追蹤管理這個過程。

怎麼寫？咱們有這個提綱內容，真正寫提綱通常是這樣的，首先是你組織內容材料，寫以前保證我該寫的內容寫在裏面，就象每一節對照提綱，把你的各類想 法寫出來。剛開始是用傾斜的方式，不見得寫的很是完善，可是保證該寫的內容在裏面，而後回去慢慢再改。很注意要明確你讀者的類型，剛剛提到規範書是由設計 工程師、測試工程師看的，文檔編輯要看，他們對設計規範書有他們的指望，他們瞭解的內容，你在寫的時候要保持在腦子裏，寫的時候必定要把這些不一樣讀者的內 容寫進去。最後寫你的內容，把內容儘可能寫的清晰、簡短，用大量的圖象描述你軟件開發的思路，比你用千萬的句子來寫更好，有一幅畫定千萬字的說法。

增進版本的設計規範書，有時候我寫一個規範書，並非一個新的版本，咱們公司已經有這個產品了，已經在市場上。咱們如今這個公司正在作一個增訂型 的，作下一個版本，這個時候在之前已有的產品基礎說我要作什麼樣的改變。要解決之前沒有解決的問題，爲何如今開發，要解決之前沒有解決的問題，我用什麼 樣的設計，改變上一代的設計沒有解決的問題。若是寫嶄新的產品就不會有這個問題，可是不少狀況下咱們的產品已經有了，咱們只是要不停的增進，這種狀況下要 寫這個內容。還有一點，設計界面的操做行爲，不光是有一個圖畫，有一個鍵、數據欄、圖象，還要很清楚的描述這個鍵我按了之後會發生什麼狀況，數字灌進去會 發生什麼狀況，有時候用鼠標控制的，鼠標究竟是左鍵按下去發生什麼狀況，右鍵按下去發生什麼狀況，這些都要列在裏面。你蓋一棟房子，描寫的很清楚，用什麼 樣的磚、瓦蓋這個房子，用什麼樣的門窗、玻璃描寫很清楚，蓋出的房子必定是你所須要的，若是你畫的是很大的很粗糙的草圖，你蓋的房子可能不是你所須要的。 還有不要忘記一些基本的文章的結構不要忘記，包括標題、日記、版本數，還有頁數，前面的目錄、章節，不一樣的章節用什麼標記代表的。別人讀兩三百頁厚的設計 版本會不會頭腦發昏，怎麼樣讓讀者理解你的東西，都要寫在裏面。還有公司項目內部名稱，若是公司項目不少的話，有時候項目有代號，代號太多可能讀者搞不清 楚，對項目內容作一個解釋。不少狀況下文檔是內部使用，做爲公司保密的，不能流傳出去。你做爲項目經理要寫的很清楚，告訴團隊成員，這個產品開發不能把這 個文檔公開給別人。在寫一個完整的設計文檔的時候，這些規範書裏都要寫在裏面。

軟件設計規範書的圖示，咱們如今正在開發的軟件，有一個圖象表示裏面各類軟件組成部分是什麼東西，除此之外會看到，用標記來標出來具體使用界面的元 素究竟是幹什麼的，按了這個鍵之後，每一個鍵起什麼做用。我如今作的設計，我以爲是把已有的軟件拿來，配上畫圖的軟件，把已有的軟件使用界面的元素拼湊起 來，設計出來的軟件看起來好象真的同樣。雖然如今沒有這樣的軟件，可是已經有這樣的圖象，拿這個給測試人員、測試團隊或者項目文檔編輯人員看，他們就一目 瞭然，知道這個軟件怎麼回事。可是這樣的作法不少人以爲很麻煩，我不會畫圖。還有一個方法，微軟裏有一個使用界面設計的模板，這不是一個真的軟件，可是畫 出來和真的差很少。描述每個具體的功能裏面到底作什麼。

需求總結，比較簡單的方法就是用一欄，用數字，分紅幾個大的檔次，比較通用的咱們叫作第1，有這個數字能夠比較容易，當設計有問題了，當和別人談話 的時候，讀個人需求規範總結去讀個人1A等等，能夠找到。有菜單，上面有什麼選擇全在上面，菜單下面都有一個橫槓，當時設計的時候沒有這個，當時測試團隊 找我抱怨，說沒有把這個標清楚，開發團隊也沒有測出來，我測試的時候也沒有辦法測試。因此我如今學會了，我都寫的很清楚。某個菜單按右鍵，都寫的很清楚。 在早期設計的時候到後來的時候肯定是錯誤的，須要去掉的。測試人員測試的時候看到原來設計是有的，後來決定沒有，所有寫在裏面，讓測試人員看得很清楚。然 後描寫全部使用界面，軟件啓動的時候看到怎麼回事，詳細的功能也會看到。儲標鍵怎麼用會有詳細的描述，若是沒有詳細描述的話，測試人員不知道，有了這樣功 能詳細的描述，對規範書進行審覈的時候，你們都會了解，你這個設計原來是這樣的，這個是合理或者是不合理的。每一個軟件使用界面的元素，都是用一個表格進行 總結的。首先是幹什麼用的，很重要的一點他的行爲是什麼，而後把他的行爲所有列出來，由於這些是幫助開發、測試團隊測試開發出來的功能，能不能達到，行爲 能不能適合符合標準。抓放的過程在什麼樣的狀況下發生什麼狀況，描述的很清楚。全部使用界面裏元件是怎麼樣的，改用什麼字標所有列出來。光標是什麼形狀， 該用什麼顏色，設計完之後，開發團隊經過開發人員按照這個開發，就不會爭論不清楚，不下來之後就避免理解的混亂。整個軟件功能規範描述用不少圖象標出來的 話，就免得你花不少時間進行字的描述，可是關鍵的行爲描述出來，關鍵的圖象開發人員就能夠輕鬆的按照你這個圖象去開發。