如何編寫高品質的需求

 

文章來源：http://www.writly.cn/index.php?title=%E5%A6%82%E4%BD%95%E7%BC%96%E5%86%99%E9%AB%98%E8%B4%A8%E9%87%8F%E7%9A%84%E9%9C%80%E6%B1%82

專案管理的保證
專案管理的主要目標是保證項目在規定時間內高品質的完成項目。專案管理包括了項目組開發各階段的人員結構的配置，品質控制的實施方略，內部文檔和產品文檔的組織編寫等各項工作。

開發項目按照正常化軟體的生產方式進行生產，在生產流程上採用iso9000的標準進行。項目開發參與的角色有專案經理，項目負責人，領域專家，系統分析員，程式員，測試組，支援人員部，品質監督組，文檔組。下面就各個角色一一說明其主要職責。

[編輯]專案經理
主要負責該項目開發商在開發和維護的過程中同客戶的商務接洽和開發配合方面的事物，包括：項目合約的簽定；提交開發計劃給客戶； 組織客戶與分析人員進行需求確定； 組織客戶階段性驗收； 協調客戶提

[編輯]領域專家
主要責任是協同系統分析員認清領域邊界，確定領域內容。領域專家可以由客戶抽調技術骨幹擔任，也可以由開發商聘請擔任。領域專家在開發過程中主要參與的階段是系統需求分析，在明確了系統將來要完成的主要任務之後，領域專家的職責轉向系統使用者介面的確定上。開發出的系統能被客戶接受的兩個重要指標一個是系統正確性，即系統是否正確的完成了使用者希望它完成的任務；第二就是系統操作的便捷性。便捷主要受到使用系統的客戶的操作習慣的制約。領域專家往往是多年從事該項工作的人員，他們的使用習慣會對系統的易用性非常有協助。領域專家參與的開發階段受到開發方式的影響。

[編輯]系統分析員
系統分析員是系統開發方法的貫徹者和系統實現的指導者。分析人員主要參與開發階段的需求分析和系統設計兩個階段（這兩個階段並不是截然分開的，由開發方式的不同，可能會貫穿整個開發工期）。

首先系統分析員和領域專家一起對領域進行分析，確定領域邊界和領域內容。在完成這項任務後，系統分析員應當提交《系統需求報告》。《系統需求報告》由領域專家確認之後交給品質監督組進行複審，複審完畢由文檔組進行文檔正常化，進行存檔和版本編號，與此同時，正常化的《系統需求報告》由專案經理轉交給客戶進行複審（專案經理對《系統需求報告》的內容格式等有審查的義務）。

客戶複審完畢之後通過項目負責人轉交給系統分析員進行更新修正，並對版本進行升級。之後再經品質監督組和文檔組等環節進行流轉，直到該報告無須進行再流轉為止。 接下來系統分析員的一項主要任務是對領域進行分析和映射，構造系統構架，即進行體繫結構的設計。

參與的系統分析員在不止一個時，首先由分析員委員會進行體繫結構設計，當體繫結構基本確定之後，定義分組和分組之間的介面，特別對將來需要密切介面的部分要進行詳細定義，包括彼此間的"通訊協議"，時間及方式等等。完成該項工作後必須產生《體繫結構設計說明》。《體繫結構設計說明》產生後由項目負責人提交給品質監督組進行複審，複審通過之後，由文檔組進行格式化和版本編號並存檔。《體繫結構設計說明》的完整流轉過程在開發商內部，客戶並不介入。

[編輯]程式員
為了有效利用領域專家的資源，在體繫結構設計的同時，可以由系統分析員的指導之下，由程式員進行介面原形的開發。介面原形由領域專家進行評審。評審通過後由客戶進行複審。介面原形跳過品質監督由文檔組進行格式化和存檔。品質監督有瞭解和監督介面原形變化的責任。 程式員參與系統詳細設計，主要負責系統的實現工作，並對測試組提供相應的測試資源。由於詳細設計的詳細程度不易把握，有程式員參與的情況下，系統分析人員與程式員的交流會有助於系統開發進度。在項目代碼生產的後期，程式員要進行相應的白盒測試。之後，可執行體提交到測試組進行測試。《系統詳細設計說明》由分析員和程式員共同完成。通過項目負責人轉交品質監督組進行複審，複審通過後，由文檔組進行格式化和版本編號，並存檔。

[編輯]測試組
主要進行軟體的測試工作。上面提到程式員在交給測試人員之前是進行過一定的白盒測試的。測試人員根據詳細設計的文檔對軟體要實現的功能進行一一測試，保證軟體的執行體正確的實現設計要求，在此也只證明了軟體正確的反映了設計思想，但是否真正反映了使用者的需求仍需要進一步的測試。在正確性測試完成之後，需要測試的是軟體的效能，軟體的效能在本項目中佔有重要的地位，效能要求有可能改變軟體的設計，為避免造成軟體的後期返工，測試在效能上需要較大的側重。

同樣，測試在不同的階段需要不同的"輸入"與"輸出"。在正確性測試階段，不需要太詳細的測試計劃和測試策略的設計。而在效能測試時，需要分析人員提出測試策略和測試案例，品質監督組同樣會提出他們認為必要的測試策略和測試案例，後者提出的測試策略和測試案例被認為是對前者的抽樣調查。無論是前者還是後者提出的測試策略和測試案例，都由測試組組織實施。

[編輯]品質監督組
保證軟體透明開發的主要環節。在項目開發的過程中幾乎所有的部門都與品質監督組有關。品質監督組對專案經理提供項目進度與項目真正開發時的差異報告，提出差異原因和改進方法。在項目進度被延滯或品質監督組認為某階段開發品質有問題時，提請專案經理、項目負責人等必要的相關人員舉行品質會議。解決當前存在的和潛在的問題。品質監督是建立在文檔的複審基礎之上，因而文檔版本的控制，特別是軟體組態管理，直接影響軟體品質監督的影響力和力度。文檔組則是保證軟體品質監督的得以實施的重要保證。

品質監督組的監督範圍包括： 系統分析人員是否正確的反映了使用者的需求； 軟體執行體是否正確的實現了分析人員的設計思想； 測試人員是否進行了較為徹底的和全面的測試； 文檔組是否對文檔的正常化進行的比較徹底，版本控制是否有效；

[編輯]文檔組
是保證項目開發完畢的同時，內部文檔和外部文檔都同時完成。內部文檔的及時產生和規範，是保證項目開發各小組能夠更好的介面和溝通的重要前提，從另一個方面講，也是保證工程不被某個關鍵路徑所阻塞而延滯的前提。如上所述，文檔組還是保證品質監督組得以發揮作用的基礎。

文檔組的主要職責包括： 完善各個部門發送需要存檔和進資料列版本設定的文檔； 對文檔進行單向出入的控制； 對所有存檔的文檔進資料列版本設定； 書寫文檔規範，並傳達到開發組中； 書寫部分外部文檔。

==支援人員部==

支援人員部的存在是保證軟體在使用者使用的過程中，為使用者提供最及時的技術服務，也為項目開發人員抽身進行新版本軟體開發保證。支援人員部的人員能夠作到對軟體的使用人員進行軟體的安裝、配置、正確使用進行培訓。能夠解決由於軟體的不當使用產生的各種問題。支援人員部的人員也有對軟體系統分析監督的作用。技術支援人員是軟體開發過程中的虛擬使用者，也就是說在軟體未正式提交使用者之前，技術支援人員充當使用者的角色。

[編輯]夥伴提供的保證
軟體的開發我們選用微軟公司的windows平台和visual studio為主要開發工具。 我公司是微軟（microsoft）在中國最大的技術方案供應商，在軟體開發方面能夠直接從微軟公司獲得最快最全面的支援人員。另一方面，公司能最快速的獲得微軟最新的企業解決方案的培訓和諮詢。同時我公司還是微軟出版社中國唯一總代理，公司擁有微軟最全面的書面資訊。

[編輯]項目進度的保證
項目進度是項目進行是否順利的最直觀表現。顯然在項目開始之前，項目開發計劃是必須的。如果項目開發計劃的制定的是完全合理的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開發計劃幾乎不太可能。可見要保證項目進度，首先要保證項目開發計劃儘可能合理。

專案計劃的合理程度與專案計劃制定者從事類似規模和類似業務的項目的經驗有直接關係，通過經驗往往能夠預見潛在的阻礙，從而制定較為合理的項目開發計劃。本公司已經開發過鐵道部的結算系統，開發中的子項目多達六個，曆時十五個月，目前多數項目已經開發完畢，有些系統已經投入運營五個月，項目金額數千萬元。在這樣的項目中，從管理者到開發人員到測試人員都積累了較為豐富的經驗，特別是項目開發計劃的制定，和項目進度的控制。

專案計劃以裡程碑為界限，將整個開發週期劃分為若干階段。根據裡程碑的完成情況，適當的調整每一個較小的階段的任務量和完成的任務時間，這種方式非常有利於整個專案計劃的動態調整。也利於項目品質的監督。

裡程碑就是對項目在開發過程中完成的較大成果的定義，比如需求分析完畢、代碼生產完畢、正確性測試完畢，都被定義為一個裡程碑，每一個裡程碑都需要對完成的界定方式進行定義。比如需求分析完畢為一裡程碑，這一裡程碑完工定義是：《系統需求說明》必須經過客戶的確認，並在文檔組進行了相應的歸檔工作。當然把完成需求分析作為裡程碑不一定恰當，因為系統開發往往伴隨著需求的不斷變化和新需求的不斷產生。 如此又引出新的問題，即如何定義恰當的裡程碑，如何界定裡程碑的完成。 裡程碑將項目分成若干個較小的段，通過保證每一個段的順利完成，來保證整個項目順利完成，同時通過每個段的完成品質，可以測度整個項目品質。同時裡程碑保證各個階段的產品的依賴關係儘可能的小，並以完備的文檔作為裡程碑完成的重要標誌之一。在裡程碑和完備文檔的控制之下，項目已完成的階段是受到保護的，在任何時間，人員變動，甚至是開發商的變動，都不至於造成特別重大的損失，通過完備的文檔，原有的成果能夠被延續進行開發。

[編輯]項目開發方法對項目品質的保證
項目的開發方法對項目的品質和按時完成也有較大的影響。

物件導向的開發方法有利於對問題領域的深入理解，也有利於將問題空間向解空間映射從而得到更加理想和完整的系統模型。同時物件導向的開發方法和實現方法也有利於系統錯誤被局限在較小的範圍內，不會出現骨牌效應。物件導向的開發方法也有不利的方面。開發人員對它的熟悉程度不如傳統的結構化的開發方法。對物件導向中新出現的名詞需要重新在開發隊伍中進行定義，以便在開發的過程中彼此交流時表達的更加準確，從而減少開發隊伍之間的通訊量。通訊量的降低意味著效率的提高，減少了佔用開發時間討論一個彼此立場根本一致的"問題"的時間。軟體構架定義了該領域中特定對象必然發生關係的發生方式，這種發生方式以構架中抽象類別之間定義的關係被固化在構件中，開發人員在開發應用系統時不必再為定義這種相互作用方式而書寫代碼，這為將來系統的維護奠定了堅實的基礎，也為將來新版本軟體的透明升級並保持相容性和正確性提供了有利保證。通過物件導向的繼承特性，可以在不傷害原有系統的情況下，任意替換功能模組，從而以效率更高的模組代替原有模組，從另一角度講，也實現了軟體模組的配置功能。要實現真正的軟體模組的隨插即用，還需要利用物件導向的另一優勢--組件。

物件導向使得物件導向的類或對象可以以與語言無關的二進位方式被儲存和調用。這就是com技術。顯然軟體構架實現的基礎是com組件。由於com是二進位的方式被儲存，因而它可以被任何語言編寫的軟體所調用。組件與系統分離，只是在發生系統調用時才被調入記憶體執行，這就保證了系統更高層次的隨插即用。

鑒於如此多的好處，採用物件導向的技術進行該項目的開發是值得的。

對於上面提到的物件導向的不利因素採用如下方法進行克服：第一，在系統開發之前，首先定義技術術語，然後定義領域術語，這樣保證了開發過程中開發人員用同種"語言"進行交流，避免了文不對題的討論或爭論。第二，指定技術規範。在殊途同歸的情況下，我們只允許那些在技術規範之內的技術來實現。技術規範定義了若干種對象技術，這些技術規範在整個開發小組中進行統一認識方面的學習。

開發策略是針對不同開發技術和問題領域而作出的策略性的考慮。顯然開發策略與所用的開發方法、實現技術以及問題領域的特徵密切相關。一般來講，鑒於物件導向的"無縫"特性，採用原形法比較恰當，而開發過程則採用螺旋式開發方法。螺旋式開發方法提高了人員的利用率，使得軟體開發的局部階段相互重疊，在整體上形成多道流水線重疊並行。顯然這又縮短了開發的總周期。

項目開發各階段的品質保證

[編輯]需求分析
需求分析是開發人員對系統需要做什麼和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了使用者的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的後期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的品質。同時，想在某個時間點上宣布需求分析已經完畢，不再需要進行進一步的需求分析，這也是不現實的。經驗告訴我們，往往在測試過程中會發現，使用者真正想要的並非您腦海中的設想，另一方面使用者往往知道自己肯定不需要什麼，而無法明確告知他們需要的是什麼。面對這些事實，我們無法期望改變使用者；比如提高使用者同分析人員的"溝通"能力，讓他們說出的話更能被分析人員理解。唯一的做法是採用一定的方式方法，誘導使用者儘可能早地將需求表達出來，表達得完整。

在某個項目中我們的做法有兩個方面：一是請領域專家參與到系統開發的早期階段；二是開發系統原形，原形包括功能性的原形和使用者介面性的原形，也可以是二者混合的原形，用這些原形確認使用者的需求。讓領域專家參與開發的早期階段，是保證分析人員有充足的時間和領域專家進行充分的交流和確認。在這個階段，原形可能在提交到使用者之前，首先被領域專家確認，這樣保證了原形被認可的程度和認可過程耗費的時間儘可能的短，從而在提高效率的同時保證了品質。

在開發方內部還有三項保證措施： 系統分析委員會保證系統分析集思廣益； 品質監督組對分析工作的監督； 技術支援人員參與需求調研。

分析委員會的意義在於任何分析人員在提交其所分析部分的分析說明書前，必須通過委員會的共同審議，委員會的成員根據各自的分析經驗和自身所分析的部分對他人的分析報告提出質疑。如此審議過後保證了各部分間相互關聯的部分被明確定義，避免了由於"疏忽"造成系統在後期進行整合時出現較嚴重的系統鴻溝或系統重疊。

品質監督組在項目的任何階段都要提出監督計劃。按照監督計劃分配相應的資源來保證某階段的開發品質。分析階段的監督計劃會在分析任務之前被專案經理，項目負責人、系統分析員以及支援人員所瞭解。為保證分析工作高品質進行，同時分析工作又不被過分打擾，品質監督組則主要針對《系統分析報告》進行複審，只在認為確實有必要的情況下才召開品質複審會議。品質複審會議的主要參與者是專案經理、項目負責人、分析人員和品質監督組組長。會議的主要議題是提出品質質疑，給出改進建議即可。具體是否存在品質問題，是否需要改進，不在會議中進行討論。以此保證了會議參與的人數較少，會議的時間儘可能的短。

通過支援人員的職責可以發現，支援人員參與分析調研有利於對分析工作的監督，在獲得使用者需求的口頭表達之後，能協助支援人員更好地扮演開發階段"使用者"的角色。支援人員具有相當的電腦技術背景，在接下來的開發過程中就能較好的起到監督的作用，也為將來維護和為使用者提供更好的服務奠定基礎。

[編輯]系統設計
優良的體繫結構應當具備可擴充性和可配置性，這兩方面因素的實現是通過windows dna的應用完成的，正如建議書中所述，在此不再贅述。

[編輯]實現
實現也就是代碼的生產過程。從設計的結構圖中可以看出，生產的類別有類的生產，組件的生產，構件的生產，應用系統的整合，以及各種測試案例的生產。為了能夠提高生產的品質，我們將生產的程式人員按職能分成兩組，測試案例的生產和測試案例生產，也就是說如果某個程式員生產了某個組件，則其測試案例不能再由該程式員來生產，但他可以生產其他組件的測試案例。這樣交叉生產更容易發現組件的存在的問題。測試人員按照測試案例來測試組件的各項指標提出測試報告。

隨生產的不斷深入，組件的生產日趨減少，構件的生產的量開始逐步增加，生產構件的過程又是對組件的考驗過程。因此描述組件實現的文檔是非常重要的，它將有可能成為阻礙進一步生產的瓶頸。文檔組在生產過程中的重要工作是對各類組件的文檔進行豐富和規範，同時進行版本的控制。文檔的完備與否，在開發的後期，對項目進度有至關重要的影響。文檔是共用前期開發成果的唯一手段。根據上一節描述的應用系統體繫結構來看，整個開發環節絲絲相扣，每一步都受到上一步的制約。

為了控制系統開發過程中的往複，不至於產生重大過失和往複的泛濫。文檔組和品質監督組協同完成軟體開發的組態管理。

軟體組態管理的目的在於控制軟體開發過程中的"變化"，這種變化可能是外部引起的，如需求的變化。也可能是來自於內部的變化，如早期設計的某個組件不夠完備，需要修改等。為了控制這些變化，把變化引起的波動儘可能的控制在有限的範圍內，組態管理的管理模型如：

配置項是指需要進行控制的任何文檔單元，它可能是需求說明報告，也可能是需求說明報告的某個點。在本項目中需要控制的內部配置項包括需求報告，設計報告，組件代碼，組件介面文檔，構件及構件相關文檔；外部配置項包括專案計劃書，使用手冊，系統安裝說明和系統配置說明等。

完整描述了軟體組態管理的流程。

可以看出在文檔沒有被提交出開發組以前，文檔可以在開發組內部"任意"地被修改，但一旦文檔被提交，則相關的部門就會被調動，來維護文檔的品質。因此為了保證工作效率，開發組提交文檔之前必須謹慎，以免引起不必要的工作量的增加。從另一角度來看，開發部受到嚴密的監督，從而保證了開發的各個環節對於開發的全過程保持透明，避免了因為個人的原因造成整個開發的癱瘓或受阻。專案經理通過質監報告可以了項目開發的進度和品質情況，為調整開發計劃提供有利的依據。

顯然開發部的內部流程在組態管理的過程中受到的監管是非常有限的。組態管理所能起的作用完全是建立在文檔之上。當項目進度非常緊張時，開發部可能書寫文檔的時間會非常少，在此情況之下品質監督組和文檔組就肩負將開發部提供的文檔進行豐富和完善的工作，從而減少開發部書寫文檔的時間，當然這是增加品質監督組與開發部的口頭交流為代價的。

[編輯]測試
測試組的工作被分成若干階段，不同階段的劃分是以保證軟體品質的不同指標為目標的。

測試的軟體指標分別包括： 軟體的正確性：正確性測試主要是測試軟體的功能是否被正確的實現。 測試的方式主要是按照功能的要求按照給定的輸入，看是否有給定的輸出。在非標稱輸入時，輸出是否異常等。一方面測試軟體的功能是否實現，同時是否實現的完整。

效能指標：該項目對效能的要求非同一般的軟體項目。效能測試往往包含了壓力測試、攻擊性測試等測試，軟體所能承受的極限是多少，一般來將軟體的極限應當高出使用者要求的效能，各種指標也應當為使用者所瞭解。

易用性：軟體的使用介面在設計實現的時候應當設法使之與功能的實現相脫離。脫離的原因在於易用性是通過友好的介面實現的。然而讓開發人員以使用者的角度來確定軟體是否易用是件非常困難的事情，在確定使用介面時往往需要多次的反覆修改，甚至只能在軟體的最後交付之前或使用者使用一段時間之後才被提出來。鑒於這種特點，軟體在開發的不同階段都作了相應的保證措施，比如在軟體需求界定的時候請領域專家參與，在軟體設計階段，讓功能的實現儘可能地包含在軟體的組件之中，也就是沒有介面要求的底層實現。介面的實現僅僅依賴於一個資料介面，介面僅僅負責將使用者輸入的資料送到指定的資料區塊中，用於顯示的資料也在指定的資料區塊中提取，只要保證資料區塊被互斥的訪問就可以了。有了這樣的設計結構，軟體的易用性也就相當容易保證了。當測試中發現易用性的問題時，軟體不會傷到筋骨，皮毛的修改總是非常容易的。

測試人員的角色也是逐步的由開發向使用者方向轉移。

測試存在兩個非常重要的問題，一是保證測試的結果真正是反映了軟體的品質。一般來講，如果測試測出的錯誤數是收斂的情況，基本認為測試本身應當是比較全面的和足夠深入的。二是測試結果的反饋。測試報告是測試結果的正式書面反饋形式。測試報需要經過品質監督組的複審，並進行統計，再形成品質監督報告的一部分，提交到專案經理和項目開發組組長處。同時，測試組產生的測試報告和測試統計報告也要進行歸檔，以便跟蹤軟體的品質進展。這也是軟體進行版本編號的一個重要依據。

[編輯]文檔維護
文檔維護主要是文檔組的工作。文檔從用途上分主要分為內部文檔和外部文檔。

內部文檔包括： 項目開發計劃； 需求分析； 體繫結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件介面及調用說明； 組件索引； 組件介面及調用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統計報告； 品質監督報告； 原始碼； 文檔分類版本索引； 軟體安裝打包檔案。

外部文檔主要包括： 軟體安裝手冊； 軟體操作手冊； 線上協助； 系統效能指標報告； 系統操作索引。

文檔的重要性在前面的章節中已經多次提到。如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發中，文檔組的一個非常重要的任務還是書寫文檔規範和文件範本。當有文件範本後需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細緻的部分可以由他人協助完成，則該文檔即交由他人完成，但此時文檔並不算被正式提交，當他人書寫完畢之後，必須由文檔的初寫者進行複審，複審通過後方可以正式提交，進入軟體組態管理的迴圈中。

文檔組真正核心的工作是對文檔的組織管理。根據文檔的不同，文檔的來源也不同，有些是通過品質監督組經過複審之後轉交給文檔組，有些則會直接從文檔的出處到達文檔組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到後百分之十的時候起到拉動項目的作用。從以往做大項目的經驗來看，寫作文檔在項目開發的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發人員越來越需要知道其他人員的開發思路和開發過程，才能使自己的開發向前推進。一個明顯的例子就是系統整合，或者某些環節是建立在其他環節完成的基礎之上時，就更顯現出文檔交流的準確性和高效性。

[編輯]系統維護保證
對於該項目，軟體維護主要由公司的支援人員部來完成。支援人員在本公司的角色在第一章中已經有所描述。在這裡需要重申的是，在本公司，支援人員的任務一方面是保證對項目客戶的Tracing Service，另一方面是把該項目的開發人員從項目中儘快的解脫出來以便投入到下一個項目的開發中，因此要求技術支援人員在項目開始的時候就介入其中，並在開發的過程中不斷跟蹤項目，特別是開發中同客戶的交流，他們必須參加。不僅如此，軟體的代碼編寫，他們也需要有所瞭解，並對非核心代碼能夠進行一定的修改，最起碼能夠準確定位錯誤，以便提請公司以最快的速度修正錯誤。對於一般性的錯誤，如操作不當等引起的問題，全部由支援人員部來解決。

支援人員部的人員基本上是按項目跟進的。當一個項目剛剛交付使用者時，在支援人員部會有較多的人員進行跟進，隨軟體的穩定，跟進的人逐步減少，並轉移到其它項目中去。