註：本人為ABAP技術顧問，故以SAP實施過程中的功能說明書（Function spec，以下簡稱FS）的編寫為例，說說我關於FS寫作的一些看法。

在SAP領域，寫FS的人很多，會編程的也不少，但真心懂寫作，懂功能說明書的人卻不多。很多人扮演著ERP實施顧問的角色，只是單純為了完成工作而寫文檔。只要能夠實現功能，哪怕裏面埋了很多雷挖了很多坑也無關緊要，甚至FS本身就是形式的存在，以至於難以依據它得知任何有關功能的真正情況。SAP系統最註重的是功能的完整性和嚴謹性，因為一旦程序有問題，影響的並不只是程序本身，更會影響到實際企業生產，甚至一定程度上影響到決策層的判斷。跟SAP的開發一樣，在功能說明書的編寫方面，沒個大幾年的累積經驗是無法成為大神級別的；除非之前就有相似的工作經驗，並認真訓練過自己。因此能發出功能說明書並沒有什麽了不起，跟其他諸如測試、開發工作一樣，培訓一段時間就能夠上手了，但真的要做到把控需求，精確的定義功能，寫出邏輯清楚、行文流暢、可維護的功能說明書，可就不容易了。也印證了一句話：會寫FS的不稀奇，懂寫FS才難求；會操作業務模塊的人不稀奇，即會業務又能寫作的才萬金難求！

以下列舉幾項，簡要說說會寫FS和懂寫FS的區別：

（本文的參考了一位園友的文章：會開發和懂開發的區別。本文以娛樂內容為主，如有雷同，純屬故意）

主體與客體

誰在寫？為誰而寫？這個問題的答案將決定文檔中會以怎樣的形式、寫入怎樣的信息。

在文檔的編寫過程中，這是一個十分基礎的問題。本文中的FS，指的是在SAP系統實現階段階段的一種文檔，它是由SAP業務顧問寫出的、面向開發人員的文檔。它不是業務藍圖、不是配置文檔，也不是培訓文檔。

一些業務顧問，對需求的認識是清楚的，但是卻搞不清自己寫作時的主體和面向的對象是誰。所以行文飄忽，內容冗雜，重點不突出。

長句與短句

在寫作過程中，句子有長有短，這是理所當然的事情。因為簡單的事情自然可以用簡單的語言描述，復雜的事情則會不可避免地將語言推向復雜...

復雜的長句，通常會有著較高的理解成本（想想英國大臣吉姆·哈克面臨過的窘境），寫作者應該盡量避免它的出現。這就要求寫作者有以下才能：

1. 精確地把功能本身抽象出來，而不是其他的東西。
2. 掌握一點點寫作技巧，學會把話題劃分為若幹個子話題。　　

其中，1保證了讀者不會收到無關信息的幹擾；2則通過一定的冗余提高了文檔的可讀性。舉個例子，我要告訴讀者，存在一個A，它的意義等於B+C+D+E+F+G+H。讀者在看到這句話的時候一定會思考，這七個字母到底代表什麽東西？就算他知道了答案，也往往需要把它們全部背誦下來，才能順利地進行閱讀。而聰明的寫作者也許會從X = B + C談起，增加幾個式子，卻讓它們的單個長度縮短，以適應人的思考能力。

書面語與口語

短句不能等於口語。盡管寫作者應當盡量使用短句，文檔自身的性質依然要求他不能忽視書面語的運用。相對於口語，書面語有著更加通用、更加持久、不易出現歧義等優點..對於FS來說，這些都是重要的特性，需要通過書面語來予以滿足。

也許讀者會覺得這種要求是不言自明的。遺憾的是，的確有部分業務顧問在尚未習得書面語的情況下，就開始了自己的職業生涯。

版本控制

和程序一樣，FS的版本控制是必不可少的存在。文檔的修改必須通過版本加以區分。這還有一個前提是功能本身的修改可以通過文檔來反映。一些業務顧問喜歡用口述的方式向開發人員交代自己的新想法。一段時間過去，經過若幹這樣的修改，新人們會發現自己能看到的FS和實際的功能完全是兩樣東西，得不到任何參考。過去的事情成為了空白的歷史，功能成為了模糊不清的盒子。這是很糟糕的局面。為長遠計，更新文檔的意識對業務顧問是必要的（題外話：對程序員而言，技術文檔也是一樣的道理）。

還有一些人不知道word有一個很好用的“審閱”功能，通過它，文檔可以很清楚地記錄文檔修改的內容、時間、修改人等歷史信息，並可以讓其他讀者通過打開相關標記的方式來方便地獲取它們。如果使用手工的方式維護這些信息，既繁瑣又容易出錯。

DRY

不要重復你自己（Don‘t Repeat Yourself）。一些業務顧問喜歡把自己寫的大段文字進行復制，粘貼到各處去，這樣做是不對的。

就和編程中要謹慎對待復制粘貼代碼一樣，寫作FS時也要盡量避免這種做法。實際上，如果一個業務顧問能做到對版本的合理控制，那他會自然地意識到復制粘貼的弊端之一：如果把同一段文字復制到多處，那要修改這段文字的內容的時候，可就有大麻煩了..好的文檔就和好的程序一樣，要經過反復的抽象提煉之後才能產生。

用代碼代替功能說明

首先，在FS中寫入SQL和偽代碼是常見的做法，這在多數情況下時合理的，因為程序語言在邏輯表達方面有著顯然的優勢。

但邏輯表達不是一份FS的全部，一些業務顧問，為了和開發人員表示親近，或者炫耀自身的編程知識，往往會在文檔中寫入過量的SQL和偽代碼。在某些情況下，甚至除了代碼之外，什麽都沒有。這種做法的問題在於，FS的基礎是功能的描述，並不是功能的實際實現。此外，用代碼來描述代碼，也會陷入表達的死循環。就算是技術文檔，使用這樣的寫法來寫作，也是不合格的。

以上幾節列舉了我在開發經歷中所遇到的FS存在的問題。還有很多很多實際存在的不良文檔，都是那些只知道寫文檔而不懂寫作的萌新寫的。比如基本的排版、比如錯別字漏字、從來不懂什麽叫word審閱。遇到這樣的事故，有時候會哭笑不得，要給IT增加不少的負擔。也只能感嘆一句，操作系統簡單，懂寫作難，懂業務又能寫作，簡直萬金難求！

本文鏈接：http://www.cnblogs.com/hhelibeb/p/7247909.html

會寫需求和懂寫需求的區別