首先講定義，作為我們開發管理人員，程序經理，開發管理企業的領導等等，到底是應該寫什么樣的內容，怎么樣用它作為指導，幫助我們寫軟件。寫作計劃，到底是在撰寫開發計劃書開發過程中間，到底要做什么樣的工作。撰寫的提綱，大家也知道，做任何事情提綱就好象一份參照表似的，有這樣的參照表寫作的時候相對來說容易的多，讓所有的員工寫的時候都按照規范來寫。然后講一下自己寫的實例，最后做一些問答，做一個雙向的討論。
整個軟件開發過程是一個相當復雜的流程，并不是簡單的靠幾個設計工程師自己在那邊寫軟件就完，而是要有從頭到尾，包括很多人，不同專家，不同的專業，不同的知識放在一起，最后才造成一個完善的軟件產品。從決定開始，到計劃、設計，最后到寫程序、執行，然后還有測試、糾錯、保證穩定、發行、部署、調試，整個過程是一個相當長的過程，并不是一個簡單的程序。要為了保證軟件的質量，能夠達到客戶滿足和滿足市場的要求，很要緊的工作，早期工作做的越是完善、仔細，避免后面的工作，由于前面不完善造成的返工，造成的浪費，起到關鍵性的作用。大家可能在網上讀到在美國軟件項目管理的權威，寫過很多關于軟件管理方面的書，很有名一個理論就是說他做過很多研究和調查，發現早期的工作要是沒有做好，而造成后面工作的返工，帶來的浪費是巨大的。有類似這樣的圖表，他做出的結論，如果在設計階段出現了問題，在設計階段如果你沒有及時找到和糾正的話，到執行階段才發現，你會看到三條不同的曲線，越是早期的錯沒有發現，最后由于要返工而造成的代價費用越來越高，如果前面沒有問題，到最后只是發現半個糾錯，花費的代價相當低，因為你是糾錯，然后重新測試就完了�？墒侨绻麍绦械臅r候，程序編程編錯了，后來重新編，重新測試，這個費用相對來說就要高。如果是設計的時候出現錯誤，由于對需求管理沒有管理好，客戶和市場的要求都錯了，開發出來的東西完全到后面重新執行、重新糾錯的話，會看到這個曲線，幾乎是幾何形上升的，成倍的費用的增加。能夠保證控制產品開發過程中間的費用增加，早期工作完善，做設計的時候，越早做的越完善，對控制后面的消耗起的作用是非常大的。
從這個方面講，我早上舉的例子造房子一樣，造房子的藍圖，對蓋一個房子的重要性，對早期設計的完善作用也是一樣的。
什么是設計規范書。大家聽過很多不同的名稱，叫法也不一樣，到底是什么東西。首先它是總結一個軟件功能和性能、使用方案的總結書，是描述一個產品，到底該為客戶提供什么服務，起到什么樣的作用，到底可以完成什么任務，從這個角度對軟件產品做一個總結,是提供軟件功能和性能以及使用方案的總結。也就是說，他應該包括的內容是向開發人員很詳細的描寫清楚，這個軟件到底應該怎么工作，他使用方案的總結，他的功能性的總結，而不應該包括產品具體的設計的構架，到底怎么執行，怎么設計，這方面內容其實是有不的文檔或者文件去總結的。早上也提到，作為開發團隊人員，當設計經理、項目經理把軟件功能定完以后，真正產品怎么開發，是應該由設計團隊人員去做。在微軟有的比較大型的團隊，我們有所謂的設計師，具體開發也開發團隊的領隊和開發人員，他們每個人根據功能的描寫總結出來具體設計的執行方案，這個其實是不應該寫在設計規范書里的，所以要理解清楚，設計規范書是描寫產品對客戶怎么用，而不是描寫這個產品具體開發邏輯怎么執行，這個是和開發有關系的。作為設計規范書是項目經理的工作，就是要把這個產品的功能描寫清楚。它該包含的內容和不該包含的內容不要搞混亂。
影響設計規范書的因素很多，首先最重要的是功能需求，客戶對使用軟件有它一定的要求，這個軟件應該提供什么樣的服務，該完成什么樣的任務，這方面就叫做功能需求。其實是有不同的好幾個因素來影響整個功能需求的，對市場競爭的分析，我們競爭的對手他的產品有什么樣的功能，從而得出我們產品應該也有什么樣的功能，甚至功能比他更好，這是對功能需求的起影響因素的。還有客戶之間的回饋，他說我這個產品為我的行業做工作，這個和明顯是客戶具體的要求。還有就是用戶解決問題的要求，比如說他說我不在乎你這個產品怎么開發，不管你以前的產品，或者你開發的產品以前有什么功能，由于要解決新的問題，必須加進這樣的功能。還有用戶所謂的使用方案，他真正解決問題，使用的方案流程是怎樣的，由于他商業之間運行有直接關系，如果客戶商業流程決定是這樣的運作的順序，你軟件設備也應該要配合客戶使用方案設計。所有這些是最關鍵的因素影響功能需求，功能需求也是第一個最要緊的影響到設計規范書該描述清楚的，解決的什么樣的問題。
除此之外是性能需求，光描寫說我這個軟件按一個鍵可以寫一個數字還不夠，如果是客戶要求我按一個數字，在0.3秒之內寫出來，或者是我按鍵以后印出五百萬字來，他顯示數據的速度怎么樣，他的要求也是影響到設計規范書的。他包括整個系統的要求，如果大型的軟件，運行的系統，什么樣的硬件，什么樣的內存存什么樣的網絡，所有這些對性能的需求都起到影響。他的運行的環境，到底是有沒有兼容不同的操作平臺，不同的操作平臺之間不同。對軟件的功能也是起到影響的，還有安裝部署，特別是大型的系統，因為我在搞工業控制很多年也知道，安裝部署的要求，軟件在實驗室完成跑到真正大型的工廠里，完全是另外一回事。環境的安裝部署要求，在很臟的環境里，邊上有各種干擾的因素，在這樣的運行這樣的軟件，性能是不是有保證，保證不會死機，數據不會出現什么錯誤，或者出現錯誤有什么樣的反應，這些都會影響到開發軟件的要求。還有是質量要求，有一部分是能解決的，還有一部分是不能解決的，中間的質量要求是碰到什么情況能夠對付，碰到什么情況怎么應付，這些不同的用戶都會有詳細的要求，這些都是規范設計書應該總結的內容。
除了這些以外，還有非功能的要求，但是在設計的時候非得考慮到，包括地區、行業，甚至國家在某一個行業里的標準。象在歐美市場上，每個行業都有自己的標準。如果你是設計軟件，為某一個行業設計，里面軟件設計接口標準，可能使用數據規范，對于很多標準，如果你是對那些不熟悉，或者是不了解，甚至是用錯的話，開發出來不符合那些客戶要求就要改。這些和真正產品的功能毫無關系，可是要為了保證在以后產品開發出去避免這樣的錯誤，由于這樣的錯誤重新返歸，就要把這些要求了解清楚。技術還有技術開發的局限，你想這樣開發，你想提供這樣的功能，但是首先得了解，目前客戶所用的設備的硬件，或者他的運作的操作系統環境，有沒有某些局限，你想開發性能的時候他沒有辦法達到，把這些事情弄很清楚的話，避免和客戶講不清楚的爭論。在描寫功能的時候，這個功能有什么樣的能力，沒有什么樣的能力，描寫的很清楚。
還有對時間的依賴，對外在因素的依賴，這里面是需要時間的。項目管理上所謂三角形的定理，有這么多時間，你有這么多資源只能開發出這么多功能。如果把你的時間砍掉一半，其他因素不變的情況下，絕對不能按時間、質量研發出來。這些都會影響到你設計規范書的撰寫，你要寫得很清楚，軟件開發哪些能力我是可以完成的，哪些是不可以完成的。還有可用性的需求，軟件為了要贏得客戶的心，贏得市場的心，很要緊的一點，不光是把軟件開發出來大家可以用，客戶用了不會覺得很混亂，還是很鬧心，還是用起來很順手，這里面的可用性，這些東西也是很重要。什么因素決定可用性，用戶的特點，不同的用戶，不同的使用者，也會決定軟件開發應該按照適合他們的要求。開發出來的軟件是給一些專門的設計人員用的，那些人受過高等教育，都是很熟悉的，和你開發出來給爺爺奶奶用，這里邊不同的客戶，都有專門的特性，所以在微軟把不同的使用者，分成不同類型的組群，這里的要求怎么回事。所有這些都是影響到可用性需求。整個設計規范書在描寫完善的軟件過程，這些都要考慮到。你不考慮的，不在乎的就去寫軟件，等你開發出來這些搞錯的話，一定影響軟件最后的質量。
軟件規范書的讀者，規范書是干什么的，為誰而寫?作為開發管理人員項目經理到底做什么工作。第一個是給開發團隊用的，構架設計、開發執行的計劃。開發團隊是第一位讀者，需要拿這個來蓋房子。除此以外，測試團隊，在定測試計劃的時候，也是根據你對功能的描述。所以如果一個軟件里調出一千多個功能，就要定一千多，甚至三千、五千相對應的測試方案。測試團隊也是設計規范書的讀者。文檔團隊，要讓客戶能夠很方便的了解、熟悉你這個軟件的產品，很要緊一點你要有所謂的專門使用手冊，如果軟件是推向市場的，給爺爺奶奶用，從來沒有用過這個軟件的，看一個說明書怎么樣可以幫助這些沒有技術水平的人在很短的時間內用這些軟件。文檔協作很重要，編輯的人也不懂計算機，只能描述這個產品，他們所需要的內容也是從這里來的�？捎眯詧F隊，他們要用產品找一些客戶到內部進行調查，他們怎么設計測試，可用性的案例?他們也是要根據設計規范書的內容決定。最后就是市場營銷團隊，當你有一個完整的設計規范書，營銷產品的時候，當產品完了以后向市場進行推銷的時候，營銷人員會比較清楚的了解，這個產品到底有什么樣的功能，可以完成什么樣的任務，然后向廣大市場描寫這個產品有什么好處。所以你看到設計規范書一般是為這么多團隊，這么多人服務的。還有給客戶領導，在你產品還沒有開發之前，在你和客戶交流的時候，我們在某一個產品，為他們專門設計的軟件，在開發之前，并不是簽一個協議，告訴我寫一個東西，然后就開發了。開發之前如果有一個很完整的規范書，讓客戶從頭到尾把我整個開發的計劃了解清楚，開發的內容，我要提供的功能，能夠提供的，不能提供的寫的很清楚的話，他看了以后就會知道符不符合他的要求。幫助客戶了解整個開發的計劃，他給你進行回饋，幫你做調整，領導可以根據這個對整個項目進行跟蹤。如果你都寫清楚了，作為企業的領導，可以從高層次領導整個開發的計劃，跟你原來的計劃，定的時間表可以知道什么時候可以完成。所以起一個很好的交流作用，幫助團隊和領導之間保持一致。
在寫規范書通常要經過什么樣的步驟，做什么事情可以達到最后的結果?在你正在寫之前，首先需要確定你要解決的問題，最要緊的是從市場需求來了解，我這個軟件到底該做什么，這個軟件是為什么樣人服務的，做什么樣的事情。定出你所要的功能之前，首先先要了解使用方案，三步法，知道客戶的使用方案，從那個得出你的需求到底是怎樣的。然后根據體的需求總結，定出你要設計的功能到底是哪些。由這些需求、總結定出這些功能，最后根據三步法設計功能。這樣你設計的功能都是為了解決客戶具體的使用方案，而不是設計的功能是毫無作用的。你不按照這樣的方法做，常常讓開發工程師自己隨意開發出一些功能，功能開發出來看起來很不錯，我們叫做很酷，可是不在客戶的使用方案里起到具體的作用，可以在某一個軟件的菜單上按一下可以做一些什么事情，可是客戶根本用不著這個，這種開發出來是一個很大的浪費。讓功能的建立設計在了解使用方案的基礎上，由此得出的需求上就能避免浪費。這樣每個開發出來的功能都是有目的的。
寫之前，在很多比較大型的、復雜的系統上，開發團隊希望能夠有一定的時間做一些技術可行性的調查，先寫一個樣品。設計經理認為我應該有這樣的功能，可是這個開發團隊認為說，你設計的功能可能不見得達到你這樣的要求，我要看在我現行的平臺上，用我現行的技術，可不可以設計出你所要的技術。在之前先做一個簡單的調查，看是不是可行。樣品做出來了，團隊花時間寫最后的規范書之前，在四面圍著玻璃窗的房間里，把客戶請來，做調查。整個使用方案的流程，按這個鍵可以灌入這個數字，可以起這個效果，你把這個不是真正的軟件，是一個虛假，甚至用圖象拼起來的，先把這個東西讓客戶用一下，看一下是不是符合你的要求。他用了說很不錯，你就知道你的設計方案是對的，如果有50%認為不符合自己的要求，你就知道你的設計方案出問題了。最后你才定下來寫規范書。規范書不是寫完一次就完了，也是好幾個回復，我們先寫一個出版，把開發團隊人員叫來，開發團隊的領隊，測試師、工程師都叫來，大家一起審核，設計這個東西是不是合理的。第一次出稿回來以后馬上推翻了，開發團隊說完全是不合理的東西，沒有辦法開發，一定要重新設計。先有出版，做審核，然后再寫正版。有一個回復，可以完了以后這邊再倒回去，這是一個流程。我這邊寫出來重點，非常要緊一點，作為我們項目開發的領導，你會看到每一個具體工作都是要時間的，都需要人去做。要定一個項目開發計劃都沒有算時間，如果要來回走五遍，可是你只有一遍的時候，你的計劃一定要出錯。最后寫正版，然后審核，全部通過大家簽字，說這是我們可以開發的。在某些情況下讓客戶簽字，客戶也同意了說你這個設計完全符合我的想法。如果前面的事情都做到家了，對你后面的事情是起到很大的作用。
提綱的內容，通常在微軟一般包括先寫一個前沿，或者梗概，用非常簡單的一小段解釋這是給領導看或者是給客戶看。你對產品開發高層次的理解是不是很清楚，總結你所開發的產品軟件到底怎么做，有什么功能。你對一個產品的功能理解，是不是能夠精簡到幾句話，不光你作為一個項目經理可以說出來，讓你開發團隊所有成員都能夠明確無誤的說出來，這是非常要緊的。特別是客戶要求，你這個文件給他讀的時候，可以很清楚的知道，對客戶要求的理解是不是很清楚。等規范不完的時候，最后回去做對照�？匆幌挛以瓉矶ǖ目偨Y是要完成這些任務，最后設計完以后，回去對照是不是跟原來的計劃一樣的。從高層次幫你指導整個開發方向應該是怎樣的。
除了簡單開頭以后，要有一個比較詳細的總結，整個文檔的總結。不光是描述規范書的內容，其實還要幫助很多第一次讀規范書的讀者，能夠有效的讀你的規范書。有的規范書很長，很復雜，有各種各樣的符號標記，怎么樣理解你用的這些符號。一般的總結包括作者、日期、版本，有時候好幾個版本放到內部網站中，你可以告訴他，應該看第三版，而不是第二版。這些內容都是幫助讀者了解，設計規范書中的版本改動的歷史是非常要緊的，因為在整個版本改動過程中，雖然全部完了，定稿大家簽字了，在真正實行的發現有些功能漏掉的，最后還要去加。你的產品開發完了以后，發現有問題，讓你的設計要改，作為設計規范書要回去重寫。改動的部分要很明確的標出來不同的，在前面的總結加一些版本該都歷史。這樣追蹤整個軟件在開發歷程過程中，什么時候發生什么問題，都會起一個很好的參照作用。很大一個產品，并不是一個設計規范書可以解決的，有時候是好幾個、十幾個設計規范書，好幾個不同的項目經理一起來做的，作為一個客戶，光讀一本可能是不夠的，你要做一套，好幾本設計規范書，規范書之間他們相互的聯系，你讀之前可能參照那本，或者讀這個以后，再讀那本，之間的參照的內容也要寫在規范書里。所以在文檔總結里，把這些內容寫在里面。
這個項目重要成員，項目總結，包括開發團隊的成員，開發團隊或者測試團隊聯系方法。發現問題不知道該找誰，特別是團隊的領隊都要寫在前面，聯系方法。還有時間表的總結，你總的產品開發，大的里程碑，幾月幾號完成怎么樣。還有對外部團隊的依賴因素，很多開發可能都要靠好幾個團隊向你提供一部分功能，最后整合起來。在你產品做的時候，9月3號要完成的東西，但是8月30號我要讓別的團隊向我提供這些東西我9月3號就能完成，如果不能提供我9月3號就完不成。全都寫清楚了，你才能知道。
在很多情況下可能要寫一個開發的理由，為什么要開發這個軟件?特別是作為一個公司開發很多不同的軟件下，作為別的團隊或者領導，或者是市場營業經理，可能先要了解你這個軟件是干什么的，在整個企業的戰略情況下，整個戰略方向為企業起什么作用。很多產品在開發，技術可能是相互交錯的，要講清楚為什么這個團隊花這么多錢、這么多精力，開發這個技術，為什么不用別的團隊已經有的技術，或者類似的技術，他們要按照什么樣的建議開發，所有的東西都要寫出來。一般的內容，我們做如下的解釋，開發的理由，如果我不開發這個，或者我用別人的，或者我的功能不開發，對公司長期企業的效果起什么影響，對我們市場競爭能力帶來什么影響。如果我們不開發，我們的競爭對手六個月之后開發出來，我們的市場可能從第一位降到第五、第六，領導看了以后就會感覺不一樣，你要用具體的數字幫你們證明，為什么要開發這樣的功能。還有所需要的資源、消費，和不開發帶來費用比較也是很要緊的。我要開發什么東西，我要花這么多、精力、人和資源的消費，可是我如果不開發，我市場損失是什么，這就幫助領導或者客戶做決定，什么情況下多少錢、多少功能你該做的。對成功企業的影響，對整個市場的影響，要開發不開發，或者現在開發幾個月后開發，這個時間是不同的。在描寫具體功能之前，先要講為什么要開發這些東西。要很清楚你開發的目標，我們叫做遠景目標。開發的目的是干什么，到底是開發什么樣的。為什么要開發，你要講清楚開發什么樣的軟件。這是總結和列出來你要開發的遠景目標，歸根到底要完成什么任務，達成什么目標。
撰寫內容，首先對公司企業戰略上的影響，市場上的影響，技術上、功能上，所有的東西從這些層次來描寫，我們該完成什么樣的任務。你在開發前把目標定義清楚，后來幫助你做解決，什么情況下開發時用什么技術，如果符合我的目標就做，如果不符合我的目標，到那時候做決定，有全面目標做了到那時候起到很大的作用。
如果是為單個客戶開發產品相對來說容易的多，一般情況下你的產品是成千成萬人用。這時候就要考慮到，要照顧到不同的用戶，他們使用的產品能力不是一樣的。對于不同層次的人使用者，對他們要達到的目標是什么，都要寫清楚。你對這些做了總結，幫助你在后來做設計的時候，比較容易做出決定，你這個設計功能該怎么樣設計。往往這些功能寫和不寫沒有太大區別，最后軟件不起到什么關鍵影響，可是由于做了這些工作，你作為設計人員，項目經理，逼迫你去思考這些問題，如果事先這些問題都沒有想過，希望后來設計的軟件都能達到前面的功能是不可能的。如果你事先做了，做了思考，跟開發團隊商量了，做的這些都是有目的的。
前面講的是比較高層次的總結，在你描寫真正開發的功能之前，就會講到很要緊的總結使用方案�？蛻羰侨绾斡媚愕能浖鉀Q他的問題的，誰來用，是什么樣的人，他們怎么用法，他們使用軟件順序是怎么樣的，描寫清楚。通常我們是用講故事的方法，長三來上班，大概機器灌入一個數字，存了文檔，交給李四，李四存了文檔，這樣用講故事的方式來描寫。還有很要緊的一點，你這樣的描寫，對測試團隊起到一個巨大的幫助。他測試的時候，內部測試團隊人員可以把自己想象成一個客戶，可以按照你所描寫的使用方案，測試團隊來測試這個軟件。按照你所描寫的使用方案，按照順序進行測試。這個是對測試團隊設計他們的測試的方案起到很大的作用。
從客戶使用軟件具體的使用方案總結出你的功能需求，他是這樣用的，因為張三打開機器要先按這個鍵，應該有一個輸出、輸入欄，灌數據，按了以后生成文檔，正因為有這樣的使用流程，你的需求功能非得有這個鍵，有數個數據欄、有功能生成文檔。前面描寫的故事怎么使用的，后來設計總結這些需求功能是符合你這個故事的，保證你設計出來的功能是能夠滿足客戶按照這個步驟執行他的方案。我們在微軟內部按照三步法開發軟件，其實是有他的道理的，他要避免你開發出來的功能是和前面使用方案毫無關系的，開發的時候造成浪費。滿足具體的使用方案，從使用方案總結出來，因為長三按這個鍵關入數字是這樣的工作，做功能描述的時候才描述細節，但首先要有這個鍵、數據欄。對可有可無的功能要把它的優先順序寫持續。我們所有的功能都有P1、P2、P3，定出來哪些東西是對客戶來說是贏得市場最要緊的，非要開發，哪些是可有可無，哪些是可以放到下一代產品再開發。開發之前把這個事情都做好。
有了這些以后，你才描述具體的功能。這里描寫如何使用，前面先講為什么要開發，如何開發，講了這個軟件為什么用，最后來講這個軟件是如何被客戶使用的。這部分對所有的功能，所有的界面設計做一個詳細的敘述。對這部分內容可以按照使用方案，從頭到尾把你使用的功能用圖象畫出來，可以用文章總結。使用大量的圖象很要緊，因為你圖象化以后，幫助測試人員怎么樣測試，幫助開發人員開發出來的功能是要符合你設計的圖象。你畫出圖象，可以讓可用性的工程師，根據這個造樣品，然后找客戶做使用性的調查。這些東西幫助管理整個使用功能控制操作和質量。
除此以外，還有很要緊的一點，在設計過程中間，常常有很多還沒有解決的問題，在設計功能中間，并不是說什么東西解決了就可以開發了，產品已經在開發了，可是還有很多東西沒有解決。某些技術性的問題，我等別的團隊告訴我，或者有些技術性問題我等著調查，或者有些技術問題不知道，我買了硬件以后，做了平臺以后做調試才知道，所謂這樣都不能遺漏，為了防止這些問題都忘記，把這些問題也寫到規范書里，有一個表格全部列到里面，有這樣的方法就知道，整個開發過程中，讓你可以隨時回去看，這些沒有解決的問題是不是已經被解決了，幾月幾號該被解決，哪些還要被調查，哪些還要被進一步決定。把沒有解決的問題列出來，做個總結，誰對這個問題負責，比如某個技術調查問題是開發團隊來做的，把這些該負責的人名字寫在里面。目前他的狀態到底有沒有解決，有的已經解決或者是已經正在調查，在一個表里列出來，分成三檔。有這樣一個總結很明顯的幫助你追蹤沒有解決的問題，在開發過程中狀態是怎樣的。如果項目過大的話，甚至可以把這個內容拿出來，專門再寫一個額外的文件，一個專門的文檔專門來總結這樣的東西，給別的團隊的人看，不見得一定在設計規范里，但是這些內容幫助你把該解決的問題記下來，幫助事后追蹤管理這個過程。
怎么寫?我們有這個提綱內容，真正寫提綱一般是這樣的，首先是你組織內容材料，寫之前保證我該寫的內容寫在里面，就象每一節對照提綱，把你的各種想法寫出來。剛開始是用傾斜的方式，不見得寫的非常完善，但是保證該寫的內容在里面，然后回去慢慢再改。很注意要明確你讀者的類型，剛剛提到規范書是由設計工程師、測試工程師看的，文檔編輯要看，他們對設計規范書有他們的期望，他們了解的內容，你在寫的時候要保持在腦子里，寫的時候一定要把這些不同讀者的內容寫進去。最后寫你的內容，把內容盡量寫的清晰、簡短，用大量的圖象描述你軟件開發的思路，比你用千萬的句子來寫更好，有一幅畫定千萬字的說法。
增進版本的設計規范書，有時候我寫一個規范書，并不是一個新的版本，我們公司已經有這個產品了，已經在市場上。我們現在這個公司正在做一個增訂型的，做下一個版本，這個時候在以前已有的產品基礎說我要做什么樣的改變。要解決以前沒有解決的問題，為什么現在開發，要解決以前沒有解決的問題，我用什么樣的設計，改變上一代的設計沒有解決的問題。如果寫嶄新的產品就不會有這個問題，但是很多情況下我們的產品已經有了，我們只是要不停的增進，這種情況下要寫這個內容。還有一點，設計界面的操作行為，不光是有一個圖畫，有一個鍵、數據欄、圖象，還要很清楚的描述這個鍵我按了以后會發生什么情況，數字灌進去會發生什么情況，有時候用鼠標控制的，鼠標到底是左鍵按下去發生什么情況，右鍵按下去發生什么情況，這些都要列在里面。你蓋一棟房子，描寫的很清楚，用什么樣的磚、瓦蓋這個房子，用什么樣的門窗、玻璃描寫很清楚，蓋出的房子一定是你所需要的，如果你畫的是很大的很粗糙的草圖，你蓋的房子可能不是你所需要的。還有不要忘記一些基本的文章的結構不要忘記，包括標題、日記、版本數，還有頁數，前面的目錄、章節，不同的章節用什么標記表明的。別人讀兩三百頁厚的設計版本會不會頭腦發昏，怎么樣讓讀者理解你的東西，都要寫在里面。還有公司項目內部名稱，如果公司項目很多的話，有時候項目有代號，代號太多可能讀者搞不清楚，對項目內容做一個解釋。很多情況下文檔是內部使用，作為公司保密的，不能流傳出去。你作為項目經理要寫的很清楚，告訴團隊成員，這個產品開發不能把這個文檔公開給別人。在寫一個完整的設計文檔的時候，這些規范書里都要寫在里面。
軟件設計規范書的圖示，我們現在正在開發的軟件，有一個圖象表示里面各種軟件組成部分是什么東西，除此以外會看到，用標記來標出來具體使用界面的元素到底是干什么的，按了這個鍵以后，每個鍵起什么作用。我現在做的設計，我覺得是把已有的軟件拿來，配上畫圖的軟件，把已有的軟件使用界面的元素拼湊起來，設計出來的軟件看起來好象真的一樣。雖然現在沒有這樣的軟件，但是已經有這樣的圖象，拿這個給測試人員、測試團隊或者項目文檔編輯人員看，他們就一目了然，知道這個軟件怎么回事。但是這樣的做法很多人覺得很麻煩，我不會畫圖。還有一個方法，微軟里有一個使用界面設計的模板，這不是一個真的軟件，但是畫出來和真的差不多。描述每一個具體的功能里面到底做什么。
需求總結，比較簡單的方法就是用一欄，用數字，分成幾個大的檔次，比較通用的我們叫做第1，有這個數字可以比較容易，當設計有問題了，當和別人談話的時候，讀我的需求規范總結去讀我的1A等等，可以找到。有菜單，上面有什么選擇全在上面，菜單下面都有一個橫杠，當時設計的時候沒有這個，當時測試團隊找我抱怨，說沒有把這個標清楚，開發團隊也沒有測出來，我測試的時候也沒有辦法測試。所以我現在學會了，我都寫的很清楚。某個菜單按右鍵，都寫的很清楚。在早期設計的時候到后來的時候確定是錯誤的，需要去掉的。測試人員測試的時候看到原來設計是有的，后來決定沒有，全部寫在里面，讓測試人員看得很清楚。然后描寫所有使用界面，軟件啟動的時候看到怎么回事，詳細的功能也會看到。儲標鍵怎么用會有詳細的描述，如果沒有詳細描述的話，測試人員不知道，有了這樣功能詳細的描述，對規范書進行審核的時候，大家都會了解，你這個設計原來是這樣的，這個是合理或者是不合理的。每個軟件使用界面的元素，都是用一個表格進行總結的。首先是干什么用的，很重要的一點他的行為是什么，然后把他的行為全部列出來，因為這些是幫助開發、測試團隊測試開發出來的功能，能不能達到，行為能不能適合符合標準。抓放的過程在什么樣的情況下發生什么情況，描述的很清楚。所有使用界面里元件是怎么樣的，改用什么字標全部列出來。光標是什么形狀，該用什么顏色，設計完以后，開發團隊通過開發人員按照這個開發，就不會爭論不清楚，不下來以后就避免理解的混亂。整個軟件功能規范描述用很多圖象標出來的話，就省得你花很多時間進行字的描述，但是關鍵的行為描述出來，關鍵的圖象開發人員就可以輕松的按照你這個圖象去開發。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
