2.2 任務二：“小學生數學選題系統”的需求分析

2.2.1 子任務一：編寫項目計劃書

任務描述

以小組為單位，編寫小學生數學選題系統項目計劃書。

任務分析與設計

項目計劃書是為了說明該項目計劃的目的并指出預期的讀者；其作用是為了說明本文檔的意圖和希望達到的效果；其意義是使項目相關人員了解項目開發計劃書的作用、希望達到的效果。開發計劃書的作用一般都是實現項目成員以及相關人員之間的共識與約定，是項目生命周期所有活動的行動基礎，項目團隊根據本計劃書展開工作。

任務實現

1.編寫目的

為了及時、保質完成小學生數學選題系統的開發，便于項目團隊成員更好地了解項目情況，使項目工作開展的各個過程合理有序，以文件化的形式，對工作任務進行分解，對相關內容以書面形式進行安排，作為項目開發過程中的共同和行動基礎。

2.項目概述

1）工作內容

簡要地說明在本項目的開發過程中必須進行的各項工作。

（1）組織開發小組對小學生數學選題系統的背景進行分析，了解原有工作流程。

（2）系統開發小組設計實施方案和開發流程。

（3）系統開發小組對系統進行集中開發。

（4）系統審核小組對系統進行評估、測試和審核。

（5）系統維護小組對系統進行定期維護。

2）參加人員

扼要說明參加本項目開發工作的人員的情況，包括他們的技術水平、主要經歷等。

（1）項目組組長：有一定的責任心和很強的團隊意識，有一定的表達能力、善于調動和管理小組成員。

（2）項目開發小組成員：具備一定的軟件項目開發知識和使用相關軟件的經驗，了解軟件的使用和操作流程，掌握VC++6.0開發環境。

3）產品

逐項說明本項目的預期開發成果，包括提交給用戶的程序、文件和服務，以及應向本單位提交但不需向用戶提交的程序和文件。

（1）小學生數學選題系統的安裝包。

（2）登錄系統的密碼。

（3）用戶使用說明書。

（4）C源程序。

（5）相關開發文檔。

4）服務

列出需向用戶提供的各項服務，如培訓、安裝、維護和運行支持等，應逐項規定開始日期、所提供支持的級別和服務的期限。

由各項目組負責人根據自己的實際情況填寫表2.2。

5）完成期限

本項目的最遲完成期限為20天。

6）本計劃的批準者和批準日期

（1）項目的批準者：軟件技術專業負責人。

（2）批準日期：2008年9月10日。

3.項目實施計劃

1）工作任務的分解與人員分工

對于項目開發中需完成的各項工作，從需求分析、設計、實現、測試到維護，包括文件的編制、審批、打印、分發工作，用戶培訓工作，軟件安裝工作等，按層次進行分解，指明每項任務的負責人和參加人員。為清晰起見，盡量采用表格的方式。

2）進度

對需求分析、設計、編碼實現、測試、移交、培訓和安裝等工作，給出每項工作的預定開始日期、完成日期，規定各項工作任務完成的先后順序，以及表明每項工作完成的標志性事件（即所謂的“里程碑”）。

開發過程的主要里程碑有：

（1）項目立項。

（2）需求調研結束。

（3）需求分析結束。

（4）概要設計結束。

（5）詳細設計結束。

（6）編碼結束。

（7）系統聯調結束。

（8）系統測試結束。

（9）系統試運行結束。

（10）系統維護結束。

項目實施計劃如表2.3（各組負責人負責填寫）所示。

4.配置管理

項目開發各階段的交付項，包括各種文檔和代碼，組成軟件的配置。配置管理規定如何管理這些交付項。開發組會產生大量的交付項，而且由于不斷地修改，每個交付項又有多個版本。如何從這些交付項建立最終系統，并保證用來生成最終系統的各交付項的一致，是配置管理的主要任務。

每個項目組，由專門人員負責項目開發交付項的管理工作，確保系統準時交付。

5.預算

逐項列出本項目所需要的勞務和經費的預算及來源。

本項目由學生自籌經費完成。

6.關鍵問題

逐項列出能夠影響整個項目成敗的關鍵問題、技術難點和風險，指出這些問題對項目的影響。

（1）處理登錄與主操作界面的關系。

（2）處理評分模塊與判卷模塊的關系。

（3）處理出題模塊與題材量的變化的關系。

（4）軟、硬件條件如下。

① 軟件條件：VC++6.0開發環境。

② 機器最低配置：Pentium III 450MHz以上的CPU處理器，64MB以上的內存，200MB的自由硬盤空間，能支持24位真彩色的顯示卡、彩色顯示器。

引導文獻

1.需求分析

1）需求分析的目標和任務

需求分析就是分析軟件用戶的需求是什么。如果投入大量的人力、物力、財力、時間，開發出的軟件卻沒人要，則所有的投入都是徒勞。如果費了很大的精力，開發一個軟件，最后卻不滿足用戶的要求，而要重新開發，則這種返工是讓人痛心疾首的。

需求分析之所以重要，是因為它具有決策性、方向性、策略性的作用，它在軟件開發的過程中具有舉足輕重的地位。必須對需求分析具有足夠的重視。在一個大型軟件系統的開發中，它的作用遠遠大于程序設計。

需求分析的目標是深入描述軟件的功能和性能，確定軟件設計的約束和軟件與其他系統元素的接口細節，定義軟件的其他有效性需求。

需求分析究的對象是開發項目的用戶及其要求。要全面理解用戶的各項要求，但不可能實現所有的用戶需求，最后要清晰、準確地表達需實現的用戶要求，這是軟件設計的基礎。

軟件開發項目的目標是實現系統的物理模型，解決目標系統的“做什么”的問題。系統目標模型的實現步驟如圖2.1所示。

2）需求分析的工作流程

（1）識別“問題”。系統分析人員綜合確定對開發軟件的需求，提出這些需求的實現條件和標準，如功能、性能、環境、可靠性、安全性、用戶界面、資源及相應的開發進度等需求，可預先估算系統能達到的目標。同時，要確定質量控制標準、里程碑、評審驗收標準及可維護性方面的需求。

（2）綜合分析。分析人員應該從信息的處理入手，理清信息的結構脈絡，逐漸細化軟件功能，準備好封裝的接口，找出設計所受的限制。對用戶提交的需求進行篩選，與用戶交流后消除需求誤區（即不合理部分），增加真正的需要，最終形成系統的解決方案，給出目標系統的詳細邏輯模型。

（3）編制需求分析階段的文檔。

（4）對需求進行分析評審。對功能的正確性、文檔的一致性、完備性、準確性和清晰性，以及其他需求給予評價。以評審負責人的結論意見及簽字為結束點。

3）獲取需求的方法

（1）了解系統的需求。

（2）市場調查。

（3）拜訪用戶和用戶領域的專家。對原始資料進行理解分析，結合專家信息進一步捕獲用戶需求。

（4）現場考察用戶實際的操作環境、操作過程和操作要求。

具體操作有：下發用戶調查表、召開調查會、跟蹤業務流程、咨詢關鍵崗位人員、查閱開發軟件的相關資料。組長可以根據成員的特點進行分工，從多角度同步完成需求的獲取。

2.項目目標的設定

設定項目目標就是把項目要完成的工作用清晰的語言描述出來，讓項目團隊的每一個成員都有明確的概念。注意，不要簡單地說成在什么時間完成、開發什么系統或完成什么安裝。“要完成一個系統”只是一個模糊的目標，還不夠具體和明確。明確的項目目標應該指出服務對象，所開發系統的最主要功能和系統本身的比較深層次的社會目的或系統使用后所產生的社會效益。

3.項目計劃與質量管理

項目計劃是在可行性分析之后制訂的，項目計劃將作為依據貫穿需求分析、系統設計、程序設計、測試、維護等軟件開發的環節。

項目計劃要提供合理的進程表，明確參與軟件開發人員的任務，保持開發步調一致，共同、及時地完成項目。項目計劃是要付諸實施的，不要過于夸張，其重點在“準確”、“翔實”，而非“快速”、“完美”。

事實上，提高質量是軟件開發的主要目標。軟件開發是一種智力創作活動，僅僅通過執行嚴格的操作規范并不足以保證軟件產品的質量。程序開發人員必須了解軟件各個方面的元素，如正確性、性能、易用性、靈活性、可復用性、可理解性等，才能在進行系統設計、程序設計時提高軟件質量。因此，軟件的高質量實際上是“設計”出來的。

1）項目計劃

做項目計劃，就要“知己知彼”。確實了解設計項目的規模、難度與時間限制。這樣，才可以確定在這個項目中要投入的人力、物力。在這方面，一個有經驗的軟件開發人員會為項目計劃的設計帶來很好的參考建議。

項目的時間限制：一種是類似于商業合同的限制，將完成日期寫在合同中，延期時，開發方要做出相應的賠償；另一種是自行開發的軟件產品，只確定大致的發行日期并允許有延誤，但是如果因此而拖延太久，也會失去商機而造成損失。

項目的資源分為“人”、“可復用的軟構件”和“軟、硬件環境”，如圖2.2所示。

人是最有價值的資源。制訂項目計劃時，一定要確定開發人員，并根據成員的特點和技術進行分工。

可復用的軟構件能提高軟件的質量與生產效率。還可以使用“拿來”的組件，甚至可以有償購買專業性較強的軟件。

軟、硬件環境常常被忽略，但卻是必不可少的資源。一般來講，只要符合項目的開發要求即可。當所開發的項目需要使用特殊的設備時，要事先做好準備。

2）進度安排

我們常常會發現項目的開發進度落后了，究其原因不外如下幾點：

（1）制定了不現實的期限。項目開發人員按照不合理的進度表開展工作。

（2）客戶的需求發生了變化，進度表卻沒有做出相應的修改。

（3）低估了項目的規模和難度，投入的人力和物力不能滿足開發需求。

（4）出現了沒有預見到的難以克服的技術難題。

（5）開發人員安排沒有冗余，沒有考慮開發人員在現實中的意外事件。

（6）開發人員之間的交流出現了障礙，人員之間不能“兼容”和理解，從而導致各階段任務不能按時完成。

基于以上的事實提出以下建議。

（1）由項目負責人制定進度表，因為他是最了解項目和開發人員的人。最終的進度表要經過開發小組的討論和大多成員的認定。

（2）應盡可能將技術難度高的事件提前完成，進度安排并非一定要符合邏輯，應發揚中國人的美德——先苦后甜。

（3）開發軟件項目，應設立為若干個里程碑。而且，一個里程碑的多個任務可同時進行。里程碑就像心靈的燈塔，指引程序員的設計進度。

（4）進度表中應該保留緩沖時間，可以借鑒Microsoft公司的開發小組制定的“50% 緩沖規則”。對許多項目經理而言，能夠容忍進度表中存在緩沖時間，是相當不容易的。

（5）如果發現項目應交付的期限不合理時，要據理力爭，放寬期限、調整進度。當客戶需求發生變化時，要及時變動進度表。

3）項目實現“零缺陷”

高目標：人在做一件事情時，由于存在很多不確定的因素，一般不可能100% 地達到目標。但是，不設定較高的目標，沒有“零缺陷”的質量目標，也許會成堆出現開發陷阱。

4）可執行的規范

好規范的前提是有能力實現并執行。無論多么好的規范，一味地照搬可能會出現硬傷。在書籍中可以很容易找到軟件工程的眾多規范，但真正適用于當前項目的規范、可以成功執行的規范才是真正的好規范。要把握軟件的靈活與嚴密的尺度。程序員必須深入了解軟件多方面的質量因素，把那些能提高軟件質量因素的各種規范植入腦中，才能在各個實踐環節自然而然地把高質量設計到軟件中。

5）選題檢查

質量檢查并不是要等到項目結束時執行的。對應進度表，在設定的每個里程碑中進行質量檢查并做出評審。

4.項目計劃書的編寫提綱（完整版）

項目計劃書的編寫沒有定式，只有通用的約定。在編制時，還要注意具體“項目”具體分析。

（1）項目提出的背景和必要性：包括國內外現狀、知識產權狀況和發展趨勢，技術突破對產業技術進步的重要意義和作用，項目可能形成的產業規模和市場前景。

（2）國內外市場分析：包括國際市場狀況及該產品未來增長趨勢、國際市場的競爭能力、產品替代進口或出口的可能性，國內市場需求規模和產品的發展前景、在國內市場的競爭優勢和市場占有率。

（3）項目主要開發和建設內容：包括項目的主要科技攻關內容、項目目標及開發任務。

（4）項目實施的技術方案：包括項目的技術路線、工藝的合理性和成熟性，關鍵技術的先進性和創新點；產品技術性能水平與國內外同類產品的比較；項目承擔單位在實施本項目的優勢。

（5）項目實施的現有基礎：包括項目承擔單位注冊地點、股權結構、資產和負債情況、員工構成、主要業務和主要產品、生產規模、主要裝備和技術水平、近年來的經營狀況，對引進技術的消化、吸收、創新的后續開發能力，企業資質、信用和融資能力等。

（6）項目組織機構和人員安排：包括項目的組織形式、產學研聯盟運作機制及分工安排，項目的實施地點，項目承擔單位負責人、項目領軍人物的主要情況，項目開發的人員安排。

（7）項目實施進度計劃：包括項目階段考核指標（含主要技術經濟指標，可能取得的專利，尤其是發明專利和國外專利情況）及時間節點安排，項目的驗收指標。

（8）項目資金需求及來源：包括項目新增總投資估算、資金籌措方案（含自有資金、銀行貸款、科教興市專項資金、推進部門配套資金等）、投資使用計劃。

（9）項目經濟和社會效益分析：包括項目未來三年或五年的生產成本、銷售收入和利稅估算，財務內部收益率、投資回收期、投資利潤率、財務凈現值等指標的動態財務分析，社會效益分析。

（10）項目風險分析及應對措施：包括項目技術、市場、資金等風險分析及應對措施。

2.2.2 子任務二：編寫需求規格說明書

任務描述

在完成了針對“小學生數學選題系統”軟件市場的前期調查，以及與客戶進行了全面、深入的探討和分析的基礎上，制定需求規格說明書。

任務分析與設計

開發人員針對“小學生數學選題系統”用戶的需求進行細致的調研分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換為相應的需求文檔。

任務實現

1.編寫目的

“小學生數學選題系統”需求規格說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。

2.系統概述

1）功能簡介

簡要描述系統的主要功能，并說明本系統與其他相關系統之間的關系。建議用框圖的方式說明系統的組成。

“小學生數學選題系統”主要是對使用者的身份進行驗證和對數學試卷的出題、判題、評分進行管理，根據其功能分為登錄模塊和主控模塊。“小學生數學選題系統”流程如圖2.3所示。

2）用戶特點

描述本系統的最終用戶的特點，說明操作人員、維護人員的技能，以及本系統的使用頻度。

本系統的最終用戶為學校，操作人員只要掌握最基本的軟件操作技能即可。系統維護人員要熟練掌握系統的功能與使用方法。系統的使用頻度較高。

3）系統運行環境

說明運行該系統所需要的硬件設備。

硬件條件（最低配置）：Pentium III 450MHz以上的CPU處理器，64MB以上的內存，200MB的自由硬盤空間，能支持24位真彩色的顯示卡、彩色顯示器。

3.功能模塊說明

“小學生數學選題系統”功能模塊如圖2.4所示。

1）登錄模塊

（1）概述。本模塊體現為用戶使用軟件的驗證功能。

（2）登錄模塊如表2.4所示。

2）主控模塊

（1）概述。主控模塊主要由使用說明、題量設置、四則題庫、評分系統模塊組成，能夠完成自動出題、閱卷功能。

（2）使用說明模塊如表2.5所示。

（3）題量設置模塊如表2.6所示。

（4）四則題庫模塊如表2.7所示。

（5）評分系統模塊如表2.8所示。

引導文獻

1.需求分析應該注意的事項

（1）最好為每個需求注釋“為什么”，以便讓程序員了解需求的本質，從而選用最合適的技術來實現此需求。

（2）需求說明不可有二義性，更不能前后相矛盾。如果有二義性或前后相矛盾，則要重新分析此需求。

（3）跳出程序員的邏輯。需求分析和程序設計不盡相同，合理、可行是才是重要的。要跳出程序設計的圈子，站在系統的角度上來看問題。

2.通過什么方式了解需求

（1）直接與客戶交談，“侃”出需求。

（2）用戶講不清楚，分析人員猜不透，就要請教行家。“聽君一席話，勝讀十年書。”

（3）應避免幼稚需求，分析優秀和蹩腳的同類軟件，對優點盡量吸取，對缺點引以為戒。

3.軟件需求規格說明及評審

軟件需求規格說明是分析任務的最終產物，通過建立完整的信息描述、詳細的功能和行為描述、性能需求和設計約束的說明、合適的驗收標準，給出對目標軟件的各種需求。

作為需求分析階段工作的復查手段，在需求分析的最后一步，應該對功能的正確性、完整性和清晰性，以及其他需求給予評價。評審的主要內容是：

（1）系統定義的目標是否與用戶的要求一致。

（2）系統需求分析階段提供的文檔資料是否齊全。

（3）文檔中的所有描述是否完整、清晰、準確反映用戶要求。

（4）與所有其他系統成分的重要接口是否都已經描述。

（5）被開發項目的數據流與數據結構是否足夠、確定。

（6）所有圖表是否清楚，在不補充說明時能否理解。

（7）主要功能是否已包括在規定的軟件范圍之內，是否都已充分說明。

（8）軟件的行為和它必須處理的信息、必須完成的功能是否一致。

（9）設計的約束條件或限制條件是否符合實際。

（10）是否考慮了開發的技術風險。

（11）是否考慮過軟件需求的其他方案。

（12）是否考慮過將來可能會提出的軟件需求。

（13）是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認。

（14）是否有遺漏，重復或不一致的地方。

（15）用戶是否審查了初步的用戶手冊或原型。

（16）軟件開發計劃中的估算是否受到了影響。

為保證軟件需求定義的質量，評審應由專門指定的人員負責，并按規程嚴格進行。評審結束應有評審負責人的結論意見及簽字。除分析員之外，用戶/需求者，開發部門的管理者，軟件設計、實現、測試的人員都應當參加評審工作。評審的結果一般包括修改意見，待修改完成后再經評審通過，才可進入設計階段。

即時訓練

以小組為單位，編寫自行設計的小學生選題系統的需求說明書。

拓展業務

設計彩票系統的需求說明書。