QM-PROC-QMP-10-軟件項目需求開發(fā)模板軟件需求開發(fā)說明書模板-V0

需求開發(fā)文件狀態(tài)：文件標(biāo)識：QM-PROC-QMP-10-需求開發(fā)-V4.0[]草稿當(dāng)前版本：4.0[V]正式發(fā)布作者：[]正在修改

需求開發(fā)版本歷史版本狀態(tài)作者日期審批人審批日期備注V1.0正式發(fā)布V2.0正式發(fā)布V2.01正在修改加入“UML需求分析”規(guī)程，將“產(chǎn)品”字樣去掉，按實際文檔內(nèi)容改為了“系統(tǒng)”或“工作成果”V3.0正式發(fā)布加入“需求調(diào)研記錄表”，并按文件編寫指南調(diào)整格式刪除首頁的完成日期V4.0正式發(fā)布Page2of14Page2of14需求開發(fā)目錄TOC\o"1-5"\h\z\o"CurrentDocument"需求開發(fā) 5\o"CurrentDocument"介紹 5\o"CurrentDocument"用戶需求調(diào)查 6目的 6\o"CurrentDocument"角色與職責(zé) 6\o"CurrentDocument"啟動準(zhǔn)則 6輸入 6\o"CurrentDocument"主要步驟 7\o"CurrentDocument"［Step1］準(zhǔn)備 7\o"CurrentDocument"［Step2］調(diào)查與記錄 7\o"CurrentDocument"［Step3］分析需求信息 7\o"CurrentDocument"［Step4］撰寫需求調(diào)研報告 7\o"CurrentDocument"［后續(xù)活動：需求確認］ 7輸出 8\o"CurrentDocument"結(jié)束準(zhǔn)則 8度量 8\o"CurrentDocument"需求定義 8目的 8\o"CurrentDocument"角色與職責(zé) 8\o"CurrentDocument"啟動準(zhǔn)則 8輸入 8\o"CurrentDocument"主要步驟 8\o"CurrentDocument"［Step1］細化并分析用戶需求 8\o"CurrentDocument"［Step2］撰寫需求規(guī)格說明書 9\o"CurrentDocument"［后續(xù)活動：需求確認］ 9輸出 9\o"CurrentDocument"結(jié)束準(zhǔn)則 9度量 9\o"CurrentDocument"需求分析方法概述 10問答分析法 10\o"CurrentDocument"建模分析法 10\o"CurrentDocument"一、結(jié)構(gòu)化分析法 10\o"CurrentDocument"二、面向?qū)ο蠓治龇?11\o"CurrentDocument"三、恰當(dāng)?shù)厥褂脠D形符號 12Page3of14Page3of14需求開發(fā)TOC\o"1-5"\h\z\o"CurrentDocument"UML需求分析 12目的 12\o"CurrentDocument"角色與職責(zé) 12\o"CurrentDocument"啟動準(zhǔn)則 12輸入 12\o"CurrentDocument"主要步驟 12\o"CurrentDocument"［Step1］細化并分析用戶需求 12\o"CurrentDocument"［Step2］撰寫需求規(guī)格說明書 13\o"CurrentDocument"［后續(xù)活動：需求確認］ 13輸出 13\o"CurrentDocument"結(jié)束準(zhǔn)則 13度量 13\o"CurrentDocument"實施建議 14Page4of14XXPage4of14需求開發(fā)需求開發(fā)需求開發(fā)(RequirementDevelopment,RD)的目的是通過調(diào)查與分析，獲取用戶需求并定義系統(tǒng)需求。需求開發(fā)過程域是QMP的重要組成部分。本規(guī)范闡述了需求開發(fā)過程域的兩個主要規(guī)程：冬需求調(diào)查弋需求定義上述每個規(guī)程的“目標(biāo)”、“角色與職責(zé)”、“啟動準(zhǔn)則”、“輸入”、“主要步驟”、“輸出”、“完成準(zhǔn)則”和“度量”均已定義。需求分析是需求開發(fā)過程域的重要活動之一，但是不宜用“規(guī)范”這種形式來論述。本章對需求分析方法作了概括性介紹，請讀者閱讀更加專業(yè)性的需求分析論著。介紹需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構(gòu)成完整的需求工程。需求工程結(jié)構(gòu)圖見需求管理過程域，需求開發(fā)和需求管理的流程如圖 1所示。求分析”則貫穿于上述兩個階段。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進行的。我們把從事需求開發(fā)工作的人員稱為需求分析員(也叫系統(tǒng)分析員)，避免與其它開發(fā)人員混淆。一、需求調(diào)查Page5of14Page5of14需求開發(fā)需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《需求調(diào)研報告》。二、需求分析需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。三、需求定義需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準(zhǔn)確無誤的系統(tǒng)需求，產(chǎn)生《需求規(guī)格說明書》。系統(tǒng)設(shè)計人員將依據(jù)《需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。需求開發(fā)過程域產(chǎn)生的主要文檔有：個《需求調(diào)研記錄》，模板見［QM-TEMP-RD-10-需求調(diào)研記錄］。7《需求調(diào)研報告》，模板見［QM-TEMP-RD-20-需求調(diào)研報告］。個《需求規(guī)格說明書》，模板見［QM-TEMP-RD-30-需求規(guī)格說明書］。個UUC-XXX用例規(guī)約》，模板見［QM-TEMP-RD-40-UC-XXX用例規(guī)約］。用戶需求調(diào)查目的?獲取用戶（客戶與最終用戶）的需求信息，經(jīng)過分析后產(chǎn)生《需求調(diào)研報告》 。角色與職責(zé)需求分析員調(diào)查、分析用戶的需求?？蛻襞c最終用戶提供必要的需求信息。啟動準(zhǔn)則?需求分析員已經(jīng)確定。輸入?任何與用戶需求相關(guān)的材料Page6of14XXPage6of14需求開發(fā)需求開發(fā)主要步驟［Stepl］準(zhǔn)備需求分析員確定需求調(diào)查的方式，例如：e與用戶交談，向用戶提問題。e參觀用戶的工作流程，觀察用戶的操作。e向用戶群體發(fā)調(diào)查問卷。e與同行、專家交談，聽取他們的意見。e分析已經(jīng)存在的同類軟件產(chǎn)品及系統(tǒng)，提取需求。e從行業(yè)標(biāo)準(zhǔn)、規(guī)則中提取需求。e從Internet上搜查相關(guān)資料。需求分析員準(zhǔn)備調(diào)查問卷（問題表）。需求分析員與被調(diào)查者建立聯(lián)系，確定調(diào)查的時間、地點、人員等。［Step2］調(diào)查與記錄需求分析員調(diào)查用戶需求，隨時記錄調(diào)查過程中所獲取的需求信息。將記錄的需求信息記錄在《需求調(diào)研記錄》中。［Step3］分析需求信息需求分析員分析已經(jīng)獲取的需求信息，消除錯誤，歸納與總結(jié)共性的用戶需求。［Step4］撰寫需求調(diào)研報告需求分析員按照指定的文檔模板撰寫《需求調(diào)研報告》，主要內(nèi)容包括：e系統(tǒng)介紹；e描述用戶群體的特征；e系統(tǒng)應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范；e描述系統(tǒng)的功能性需求；e描述系統(tǒng)的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需求。補充說明：調(diào)查過程中獲取的需求信息可以作為《需求調(diào)研報告》的附件。［后續(xù)活動：需求確認］項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《需求調(diào)研報告》 ，盡最大努力使《需求調(diào)研報告》能夠正確無誤地反映用戶的真實意愿。需求評審之后，開發(fā)方和客戶方的責(zé)任人對《需求調(diào)研報告》作書面承諾。補充說明：“需求確認”活動屬于需求管理范疇，詳見［QM-PROC-QMP-08-需求管理.需求確認］。Page7of14XXPage7of14需求開發(fā)需求開發(fā)輸出《需求調(diào)研記錄》《需求調(diào)研報告》結(jié)束準(zhǔn)則?需求分析員已經(jīng)撰寫完成《需求調(diào)研報告》，并做了內(nèi)部審查（消除拼寫、排版等錯誤）。度量?需求分析員統(tǒng)計工作量和上述文檔的規(guī)模，匯報給項目經(jīng)理。需求定義目的?定義準(zhǔn)確無誤的系統(tǒng)需求，產(chǎn)生《需求規(guī)格說明書》。角色與職責(zé)需求分析員定義系統(tǒng)需求?？蛻襞c最終用戶提供必要的需求信息，并確認系統(tǒng)需求。啟動準(zhǔn)則? 《需求調(diào)研報告》已經(jīng)撰寫完成。輸入? 《需求調(diào)研報告》主要步驟[Step1]細化并分析用戶需求需求分析員對《需求調(diào)研報告》進行細化，以便產(chǎn)生詳細的系統(tǒng)需求。需求分析員對比較復(fù)雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解Page8of14Page8of14需求開發(fā)需求。建議采用Rational的Rose工具進行需求的建模分析，建模分析產(chǎn)生的文檔可以作為《需求規(guī)格說明書》的附件。補充說明：建模分析的技術(shù)難度比較高，需求分析員應(yīng)當(dāng)根據(jù)自身水平進行取舍。［Step2］撰寫需求規(guī)格說明書需求分析員按照指定的文檔模板撰寫《需求規(guī)格說明書》。如果待開發(fā)的系統(tǒng)分為軟件和硬件兩部分的話，則應(yīng)當(dāng)分別撰寫《軟件需求規(guī)格說明書》和《硬件需求規(guī)格說明書》?！缎枨笠?guī)格說明書》的主要內(nèi)容包括：個系統(tǒng)介紹；e描述用戶群體的特征；弋定義系統(tǒng)的范圍；e闡述系統(tǒng)應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范；e定義系統(tǒng)中的角色；e定義系統(tǒng)的功能性需求；e定義系統(tǒng)的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需求；［后續(xù)活動：需求確認］項目經(jīng)理邀請同行專家和用戶（包括客戶和最終用戶）一起評審《需求規(guī)格說明書》，盡最大努力使《需求規(guī)格說明書》能夠正確無誤地反映用戶的真實意愿。需求評審之后，開發(fā)方和客戶方的責(zé)任人對《需求規(guī)格說明書》作書面承諾。補充說明：“需求確認”活動屬于需求管理范疇，詳見［QM-PROC-QMP-08-需求管理-需求確認］。輸出? 《需求規(guī)格說明書》結(jié)束準(zhǔn)則《需求規(guī)格說明書》已經(jīng)撰寫完成。已經(jīng)對系統(tǒng)需求進行了評審，并且獲得了開發(fā)方和客戶方對需求的承諾。度量?項目經(jīng)理統(tǒng)計工作量和上述文檔的規(guī)模。Page9of14Page9of14需求開發(fā)需求分析方法概述很多時候用戶說不清楚需求、會說錯需求或者提出一些無法實現(xiàn)的需求。需求分析是指在需求開發(fā)過程中，對所獲取的需求信息進行分析，及時排除錯誤、彌補不足，確保需求文檔正確地反映用戶的真實意圖。需求分析是需求開發(fā)過程中“最費腦子”的工作。分析方法大體有兩類： ”問答分析法”和“建模分析法”。后者技術(shù)性比較強，大多數(shù)軟件工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用，很有實用價值。.問答分析法問答分析方法很簡單：刨根究底地問，如果解答了這些問題，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討” 。問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。其它常見的問題有：e需求存在二義性嗎？e需求文檔的上下文有矛盾嗎？e需求完備嗎？e需求是必要的嗎？e需求可實現(xiàn)嗎？e需求可驗證嗎？e需求的優(yōu)先級確定了嗎？.2.建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個道理。在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：”結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。一、結(jié)構(gòu)化分析法軟件的建模分析興起于20世紀60年代末期和70年代初期。結(jié)構(gòu)化分析方法并不是由里程碑式的明確地涉及這個主題的一篇文章或者一本著作引入的，它也不是被所有使Page10of14Page10of14需求開發(fā)用者一致采用的單一方法。相反地，它是幾乎發(fā)展了20多年的一個混合物。結(jié)構(gòu)化分析方法在70年代和80年代非常流行，相關(guān)論著很多。對結(jié)構(gòu)化分析方法有較大貢獻的學(xué)者有DeMarco,Gane,Sarsen,Yourdon,Constantine,Ward,Mellor,Hatly,Pirbhai 等人。文獻［Pressmen99,p206-p214］對結(jié)構(gòu)化分析方法作了高度概括（如圖2所示），我們不妨稱之為“一個中心三種圖”：e “數(shù)據(jù)字典”是中心，它包含了軟件中所有數(shù)據(jù)對象的描述。e “實體一關(guān)系圖”是用圖形符號來標(biāo)識數(shù)據(jù)對象以及它們之間的關(guān)系。e “數(shù)據(jù)流圖”指明了數(shù)據(jù)在系統(tǒng)中移動時如何被變換。e ”狀態(tài)一變遷圖”表示了系統(tǒng)存在的各種狀態(tài)以及它們之間的變遷方式。狀態(tài)一變遷圖圖2結(jié)構(gòu)化分析方法示意圖二、面向?qū)ο蠓治龇嫦驅(qū)ο蠓治鲈O(shè)計（OOAD）方法興起于20世紀80年代，從90年代起至今它已經(jīng)在分析設(shè)計領(lǐng)域占據(jù)了無可爭議的主流地位。面向?qū)ο蠓治鲈O(shè)計領(lǐng)域有一些比較著名的學(xué)派，如：eCoad和Yourdon學(xué)派，其代表作為［Coad91］。eBooch學(xué)派，其代表作為［Booch94］。eJocobson學(xué)派，其代表作為［Jacobson92］。eRumbaugh學(xué)派，其代表作為［Rumbaugh91］。有趣的是，這些學(xué)派的掌門人就像上帝、真主、如來佛，他們用各自的方式定義了這個世界，并留下一堆經(jīng)書來解釋這個世界。這種混亂的局面被學(xué)術(shù)界稱為百家爭鳴，每年誕生了許多論著和教授。叫苦的是軟件企業(yè)和開發(fā)人員：沒有統(tǒng)一的方法，不好干活??！終于等到了那一天，Rational公司招納了Booch,Jocobson,Rumbaugh,這三位“面向?qū)ο蟆睒I(yè)界的權(quán)威強強聯(lián)手，制定了“統(tǒng)一建模語言"（UML）。1997年11月，UML被國際對象管理組織（OMG）采納，此后UML成為OOAD建模語言的國際標(biāo)準(zhǔn)。UML吸取了各種OOAD方法的精髓，對于OOAD中的語義、圖形表示法和使用規(guī)則作了完整而詳細的定義。UML的建模能力超過了以往任何一種OOAD方法，當(dāng)然其復(fù)雜性也隨之膨脹。大多數(shù)軟件開發(fā)人員沒有興趣閱讀枯燥乏味的UML文檔（如［Rumbaugh99］）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose易學(xué)易用，它能交互式地構(gòu)建類圖、用例圖、構(gòu)件圖、部署圖、狀態(tài)圖、活動圖、順序XX科技，2017 Page11of14需求開發(fā)圖、協(xié)作圖等等，深得開發(fā)人員的喜愛。介紹UML和Rose的書籍非常多，讀者自己選擇、學(xué)習(xí)，這里不再論述。三、恰當(dāng)?shù)厥褂脠D形符號現(xiàn)代建模工具如Rose有非常豐富的圖形符號和文字標(biāo)注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖一一它能完整地描述需求。需求建模不可能取代文字描述。在需求規(guī)格說明書中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求規(guī)格說明書的附錄中，便于正文引用。UML需求分析目的?運用UML分析方法定義準(zhǔn)確無誤的系統(tǒng)需求，產(chǎn)生《需求規(guī)格說明書》、業(yè)務(wù)流程圖、用例圖及用例規(guī)約。角色與職責(zé)需求分析員運用UML分析方法進行需求分析、定義系統(tǒng)需求?？蛻襞c最終用戶提供必要的需求信息，并確認系統(tǒng)需求。啟動準(zhǔn)則《需求調(diào)研報告》已經(jīng)撰寫完成。需求分析人員具備UML需求分析技能。輸入? 《需求調(diào)研報告》主要步驟[Step1]細化并分析用戶需求需求分析員對《需求調(diào)研報告》進行細化，以便產(chǎn)生詳細的系統(tǒng)需求。需求分析員對比較復(fù)雜的用戶需求進行建模分析，以幫助軟件開發(fā)人員更好地理解Page12of14Page12of14需求開發(fā)需求。建議采用Ratio