第二講需求的基礎(chǔ)理論

第二講需求的基礎(chǔ)理論第1頁，共63頁，2023年，2月20日，星期一主要內(nèi)容需求的涵義需求的類型需求工程的路線優(yōu)秀需求的特性常見的需求錯誤第2頁，共63頁，2023年，2月20日，星期一研究對象：軟件加強型系統(tǒng)中的軟件泛指由計算機技術(shù)支持的互相聯(lián)系著的一組人類活動組成的系統(tǒng)與物理設(shè)備相關(guān)與人類社會的活動相關(guān)軟件加強型系統(tǒng)比如：游戲軟件與物理設(shè)備、用戶ERP系統(tǒng)與組織運作過程1.需求的涵義

—對象第3頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——需求的定義（1）用戶為了解決問題或達到某些目標所需要的條件或能力；（2）系統(tǒng)或系統(tǒng)部件為了滿足合同、標準、規(guī)范或其它正式文檔所規(guī)定的要求而需要具備的條件或能力；（3）對（1）或（2）中的一個條件或一種能力的一種文檔化表述。第4頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——問題域與解系統(tǒng)（1）軟件系統(tǒng)與外部環(huán)境第5頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——問題域與解系統(tǒng)當(dāng)現(xiàn)實的狀況與人們期望的狀況產(chǎn)生差距時，就產(chǎn)生了問題。要解決問題，就需要改變現(xiàn)實當(dāng)中某些實體的狀態(tài)或改變實體狀態(tài)變化的演進順序，使其達到期望的狀態(tài)或演進順序。這些實體和狀態(tài)構(gòu)成了問題解決的基本范圍，稱為該問題的問題域（ProblemDomain）軟件系統(tǒng)通過影響問題域，能夠幫助人們解決問題，稱為解系統(tǒng)

第6頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——共享現(xiàn)象軟件系統(tǒng)能夠與問題域進行交互和相互影響的原因在于，軟件系統(tǒng)中的某些部分對問題域中的某些部分的具有模擬特性。換句話說，軟件系統(tǒng)當(dāng)中含有問題域某些部分的模型（或模擬），常見的模型包括數(shù)據(jù)模型、對象模型、處理模型等。問題域中的某些信息能夠和模型中的信息建立映射關(guān)系這些通過映射建立的共同知識，就是問題域和解系統(tǒng)之間的共享現(xiàn)象第7頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——需求需求是用戶對問題域當(dāng)中的實體狀態(tài)或事件的期望描述R2.2.3-1：一旦書籍被借出，則在歸還之前，它不能被再次借閱。R2.2.3-2：在歸還的書超過30天的歸還期限時，歸還后應(yīng)該進行超期處罰。直接需求間接需求第8頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——規(guī)格說明規(guī)格說明是解系統(tǒng)為滿足用戶需求而提供的解決方案，規(guī)定了解系統(tǒng)的行為特征主要包括兩個部分（如圖2－3(b)）：（1）對共享現(xiàn)象（模型）的描述；（2）系統(tǒng)對共享現(xiàn)象所施加的操作的描述。也可以看作是一種需求完全針對系統(tǒng)行為發(fā)出的期望一種理想的、完全不需要進行任何額外努力即可以轉(zhuǎn)換為系統(tǒng)行為的需求。第9頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——問題域特性問題域自治的規(guī)律性稱為問題域特性包括結(jié)構(gòu)特性和行為特性等問題域特性的重要性要想解決問題，它就需要了解問題域特性，將解決方案和問題域特性結(jié)合起來要防止解系統(tǒng)的引入在問題域當(dāng)中引發(fā)未預(yù)見的連鎖反應(yīng)需要關(guān)注的問題域特性間接特性約束和假設(shè)第10頁，共63頁，2023年，2月20日，星期一1.需求的涵義

——從問題域、需求和規(guī)格說明的關(guān)系看需求工程

描述明確的問題域特性E;定義良好的系統(tǒng)行為S;預(yù)期的需求R需求工程的目的就是根據(jù)E，構(gòu)建S，使得需求工程的困難之處：（1）不存在描述明確的E；（2）不存在確定的針對S的評估標準R；（3）是一個創(chuàng)造性的過程。需求工程的主要工作需求開發(fā),確定R研究問題背景，描述問題域特性E構(gòu)建解系統(tǒng)，描述解系統(tǒng)行為S，使得第11頁，共63頁，2023年，2月20日，星期一主要內(nèi)容需求的涵義需求的類型分類方式功能需求性能需求質(zhì)量屬性對外接口約束需求工程的路線優(yōu)秀需求的特性常見的需求錯誤第12頁，共63頁，2023年，2月20日，星期一2.1需求的分類方式(1)功能需求（FunctionalRequirement）：和系統(tǒng)主要工作相關(guān)的需求，即在不考慮物理約束的情況下，用戶希望系統(tǒng)所能夠執(zhí)行的活動，這些活動可以幫助用戶完成任務(wù)。功能需求主要表現(xiàn)為系統(tǒng)和環(huán)境之間的行為交互。性能需求（PerformanceRequirement）：系統(tǒng)整體或系統(tǒng)組成部分應(yīng)該擁有的性能特征，例如CPU使用率、內(nèi)存使用率等。質(zhì)量屬性（QualityAttribute）：系統(tǒng)完成工作的質(zhì)量，即系統(tǒng)需要在一個“好的程度”上實現(xiàn)功能需求，例如可靠性程度、可維護性程度等。對外接口（ExternalInterface）：系統(tǒng)和環(huán)境中其他系統(tǒng)之間需要建立的接口，包括硬件接口、軟件接口、數(shù)據(jù)庫接口等等。約束進行系統(tǒng)構(gòu)造時需要遵守的約束，例如編程語言、硬件設(shè)施等第13頁，共63頁，2023年，2月20日，星期一2.1需求的分類方式(2)系統(tǒng)需求（SystemRequirement）硬件需求（HardwareRequirement）軟件需求（SoftwareRequirement）其他需求第14頁，共63頁，2023年，2月20日，星期一2.1三類問題和三種需求變化方式S類型程序（可說明的）問題能夠被形式地和完全地陳述出來接受：按照這個規(guī)格說明，這個程序是正確的嗎？這種軟件不會進化對規(guī)格說明的改變定義一個新的問題，因而是新的程序P類型程序（問題求解）現(xiàn)實世界問題的不精確陳述接受：對這個問題來說，這個程序是一個可接受的解決方案嗎？這種軟件很可能要連續(xù)地進化因為這個方案是決不會完美的，并且是能夠被改進的因為現(xiàn)實世界要變化，所以這個程序也要變化E類型程序（被嵌入的）一個變成它建模的世界的一部分的系統(tǒng)接受：完全依賴于觀點和判斷這個軟件是固有的進化的軟件和世界的變化相互影響第15頁，共63頁，2023年，2月20日，星期一2.1三類問題和三種需求變化方式第16頁，共63頁，2023年，2月20日，星期一2.2功能需求

——層次性第17頁，共63頁，2023年，2月20日，星期一2.2功能需求

——業(yè)務(wù)需求系統(tǒng)建立的戰(zhàn)略出發(fā)點，表現(xiàn)為高層次的目標（Objective），它描述了組織為什么要開發(fā)系統(tǒng)為了滿足用戶的業(yè)務(wù)需求，需求工程師需要描述系統(tǒng)高層次的解決方案，定義系統(tǒng)應(yīng)該具備的特性（Feature）參與各方必須要對高層次的解決方案達成一致，以建立一個共同的前景（Vision）特性說明了系統(tǒng)為用戶提供的各項功能，它限定了系統(tǒng)的范圍（Scope）第18頁，共63頁，2023年，2月20日，星期一2.2功能需求

——用戶需求執(zhí)行實際工作的用戶對系統(tǒng)所能完成的具體任務(wù)的期望，描述了系統(tǒng)能夠幫助用戶做些什么直接用戶間接用戶對所有的用戶需求，都應(yīng)該有充分的問題域知識作為背景支持特性模糊、不清晰多特性混雜多邏輯混雜第19頁，共63頁，2023年，2月20日，星期一2.2功能需求

——系統(tǒng)需求用戶對系統(tǒng)行為的期望，一系列的系統(tǒng)行為聯(lián)系在一起可以幫助用戶完成任務(wù)，滿足業(yè)務(wù)需求系統(tǒng)需求可以直接映射為系統(tǒng)行為，定義了系統(tǒng)中需要實現(xiàn)的功能，描述了開發(fā)人員需要實現(xiàn)什么將用戶需求轉(zhuǎn)化為系統(tǒng)需求的過程是一個復(fù)雜的過程首先需要分析問題領(lǐng)域及其特性，從中發(fā)現(xiàn)問題域和計算機系統(tǒng)的共享知識，建立系統(tǒng)的知識模型；然后將用戶需求部署到系統(tǒng)模型當(dāng)中，即定義系列的系統(tǒng)行為，讓它們聯(lián)合起來實現(xiàn)用戶需求，每一個系統(tǒng)行為即為一個系統(tǒng)需求。該過程就是需求工程當(dāng)中最為重要的需求分析活動，又稱建模與分析活動。第20頁，共63頁，2023年，2月20日，星期一2.2功能需求

——從功能需求的層次性看需求開發(fā)第21頁，共63頁，2023年，2月20日，星期一2.3性能需求速度（Speed），系統(tǒng)的響應(yīng)時間，例如PR2.3.3-1。PR2.3.3-1：所有的用戶查詢都必須在10秒內(nèi)完成。容量（Capacity），系統(tǒng)所能存儲的數(shù)據(jù)量，例如PR2.3.3-2。PR2.3.3-2：系統(tǒng)應(yīng)該能夠存儲至少10萬條銷售記錄。吞吐量（Throughput），系統(tǒng)在連續(xù)的時間內(nèi)完成的事務(wù)數(shù)量，例如PR2.3.3-3。PR2.3.3-3：解釋器每分鐘應(yīng)該至少解析5000條沒有錯誤的語句。負載（Load），系統(tǒng)可以承載的并發(fā)工作量，例如PR2.3.3-4。PR2.3.3-4：系統(tǒng)應(yīng)該允許200個用戶同時進行正常的工作。實時性（Time-Critical），嚴格的實時要求，例如PR2.3.3-5。PR2.3.3-5：監(jiān)測到病人異常后，監(jiān)控器必須在0.5秒內(nèi)發(fā)出警報。第22頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性系統(tǒng)為了滿足規(guī)定的及隱含的所有要求而需要具備的要素稱為質(zhì)量質(zhì)量屬性是為了度量質(zhì)量要素而選用的特征質(zhì)量模型就是能夠為質(zhì)量需求的描述和評價提供工作基礎(chǔ)的特征集及特征之間的聯(lián)系質(zhì)量屬性的重要性對設(shè)計的影響很大對越復(fù)雜的系統(tǒng)越為重要[Robert19901]：真實的現(xiàn)實系統(tǒng)中，在決定系統(tǒng)的成功或失敗的因素中，滿足非功能屬性往往被滿足功能性需求更為重要。第23頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126第24頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126特征子特征簡要描述功能性精確性軟件準確依照規(guī)定條款程度，規(guī)定確定了權(quán)利、協(xié)議的結(jié)果或者協(xié)議的效果依從性軟件符合法定的相關(guān)標準、協(xié)定、規(guī)則或其他類似規(guī)定的程度互操作性軟件和指定系統(tǒng)進行交互的能力安全性軟件阻止對其程序和數(shù)據(jù)進行未授權(quán)訪問的能力，未授權(quán)的訪問可能是有意，也可能是無意的適合性指定任務(wù)的相應(yīng)功能是否存以及功能的適合程度第25頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126可靠性成熟性因軟件缺陷而導(dǎo)致的故障頻率程度容錯性軟件在故障或者外界違反其指定接口的情況下維持其指定性能水平的能力可恢復(fù)性軟件在故障后重建其性能水平、恢復(fù)其受影響數(shù)據(jù)的能力、時間和精力依從性同上第26頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126易用性可理解性用戶認可軟件的邏輯概念和其適用性需要花費的精力可學(xué)習(xí)性用戶為了學(xué)會使用軟件需要花費的精力可操作性用戶執(zhí)行軟件操作和控制軟件操作需要花費的精力吸引性軟件吸引用戶的能力依從性同上第27頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126效率時間行為執(zhí)行功能時的響應(yīng)時間、處理時間和吞吐速度資源行為執(zhí)行功能時使用資源的數(shù)量和時間依從性同上第28頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126可維護性可分析性診斷軟件中的缺陷、故障的原因或者識別待修改部分需要花費的精力可改變性進行功能修改、缺陷剔除或者應(yīng)付環(huán)境改變需要花費的精力穩(wěn)定性因修改導(dǎo)致未預(yù)料結(jié)果的風(fēng)險程度可測試性確認已修改軟件需要花費的精力依從性同上第29頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——ISO/IEC9126可移植性適應(yīng)性不需采用額外的活動或手段就能適應(yīng)不同指定環(huán)境的能力可安裝性在指定的環(huán)境中安裝軟件需要花費的精力共存性在公共環(huán)境中同分享公共資源的其他獨立軟件共存的能力可替換性在另一個指定軟件的環(huán)境下，替換該指定軟件的能力和需要花費的精力依從性同上第30頁，共63頁，2023年，2月20日，星期一2.4質(zhì)量屬性

——質(zhì)量屬性的開發(fā)用戶并不能明確地提出他們對產(chǎn)品質(zhì)量的期望并不了解軟件系統(tǒng)的開發(fā)過程，也就無從判斷哪些質(zhì)量屬性會在怎樣的程度上給設(shè)計帶來多大的影響，也無法將他們對軟件系統(tǒng)的質(zhì)量要求細化成一組組的可量化的質(zhì)量屬性需求工程師質(zhì)量屬性大都是和功能需求聯(lián)系在一起的，因此需要對照軟件的質(zhì)量屬性檢查每一項功能需求，盡力去判斷質(zhì)量屬性存在的可能性形容詞和副詞通常意味著質(zhì)量屬性的存在對于一些不和任何功能需求相聯(lián)系的全局性質(zhì)量屬性，需求工程師要在碰到特定的實例時意識到它們的存在第31頁，共63頁，2023年，2月20日，星期一2.5對外接口解系統(tǒng)和其他系統(tǒng)之間的軟硬件接口接口的用途接口的輸入輸出數(shù)據(jù)格式命令格式異常處理要求用戶界面利用專門的人機交互設(shè)計文檔記錄第32頁，共63頁，2023年，2月20日，星期一2.6約束總體上限制了開發(fā)人員設(shè)計和構(gòu)建系統(tǒng)時的選擇范圍系統(tǒng)開發(fā)及運行的環(huán)境。包括目標機器、操作系統(tǒng)、網(wǎng)絡(luò)環(huán)境、編程語言、數(shù)據(jù)庫管理系統(tǒng)等。問題域內(nèi)的相關(guān)標準。包括法律法規(guī)、行業(yè)協(xié)定、企業(yè)規(guī)章等。商業(yè)規(guī)則。用戶在任務(wù)執(zhí)行中的一些潛在規(guī)則也會限制開發(fā)人員設(shè)計和構(gòu)建系統(tǒng)的選擇范圍第33頁，共63頁，2023年，2月20日，星期一主要內(nèi)容需求的涵義需求的類型需求工程的路線優(yōu)秀需求的特性常見的需求錯誤第34頁，共63頁，2023年，2月20日，星期一3.需求工程的路線問題分析和背景分析發(fā)現(xiàn)問題比發(fā)現(xiàn)需求要簡單的多進行背景分析，以更好的理解用戶的問題問題分析明確問題。定義業(yè)務(wù)需求。制定解決方案。確定系統(tǒng)特性。第35頁，共63頁，2023年，2月20日，星期一3.需求工程的路線需求獲取根據(jù)項目范圍，確定問題域的范圍確定需求獲取的源頭確定獲取的主題和內(nèi)容選擇需求獲取的方法圍繞獲取的內(nèi)容，運用需求獲取的方法，從源頭獲取需求

對獲取過程中出現(xiàn)的分歧和問題，在項目前景的指導(dǎo)下進行解決經(jīng)過需求獲取過程，可以得到獲取的文檔資料，其中以獲取筆錄為主第36頁，共63頁，2023年，2月20日，星期一3.需求工程的路線需求分析建立一個綜合考慮了問題域特性和需求的系統(tǒng)模型根據(jù)系統(tǒng)模型將用戶需求轉(zhuǎn)化為系統(tǒng)需求文檔化和驗證產(chǎn)生規(guī)格說明進行驗證第37頁，共63頁，2023年，2月20日，星期一主要內(nèi)容需求的涵義需求的類型需求工程的路線優(yōu)秀需求的特性常見的需求錯誤第38頁，共63頁，2023年，2月20日，星期一4.優(yōu)秀需求的特性完整性

不需要做更多的擴展就可以充分的說明用戶所需要的系統(tǒng)功能。每一個需求的描述都應(yīng)該包含開發(fā)人員設(shè)計和實現(xiàn)這項功能需要的所有信息R2.5-1：系統(tǒng)應(yīng)該允許被擴展。（更好）R2.5-2：系統(tǒng)的調(diào)度算法應(yīng)該允許被擴展。

第39頁，共63頁，2023年，2月20日，星期一4.優(yōu)秀需求的特性正確性

真實的反映用戶的意圖必須請需求的提出者予以確認精確性

描述僅包含必要的信息簡潔、清晰（不好）R2.5-3：在實現(xiàn)之后，系統(tǒng)的調(diào)度算法應(yīng)該允許被擴展。

第40頁，共63頁，2023年，2月20日，星期一4.優(yōu)秀需求的特性可行性

由開發(fā)人員進行檢查需要進行一定的分析和研究，而不是單純的憑借經(jīng)驗和直覺必要的時候要通過開發(fā)原型來加以驗證必要性

滿足用戶的業(yè)務(wù)需求所必需的第41頁，共63頁，2023年，2月20日，星期一4.優(yōu)秀需求的特性無歧義

每一項需求都應(yīng)該有而且只能有一種解釋定義一個可以共同理解的詞匯表（Glossary）可驗證

通過分析、檢查、模擬或者測試等方法能夠判斷需求是否被滿足不可驗證的需求往往是因為描述模糊或者過于抽象，所以在進行需求的描述時要讓需求具體化小心形容詞和副詞的使用避免程度詞的使用第42頁，共63頁，2023年，2月20日，星期一主要內(nèi)容需求的涵義需求的類型需求工程的路線優(yōu)秀需求的特性常見的需求錯誤第43頁，共63頁，2023年，2月20日，星期一5.常見的需求定義錯誤需求并沒有反映用戶的真實需要用戶在表達自己的需要時，可能會在潛意識下進行一定的加工發(fā)現(xiàn)問題背后的問題在人際交流當(dāng)中，信息會發(fā)生自然的衰減，甚至扭曲檢查和確認第44頁，共63頁，2023年，2月20日，星期一5.常見的需求定義錯誤模糊和歧義的需求無意中寫出模糊和歧義的需求定義往往是因為選詞造句不當(dāng)為項目中重要的詞匯建立一個公共的可共同理解的詞匯表有意產(chǎn)生的模糊和歧義的需求定義往往是為了應(yīng)付對需求持有不同立場的用戶在項目前景的指導(dǎo)下，促進用戶之間的協(xié)商解決第45頁，共63頁，2023年，2月20日，星期一5.常見的需求定義錯誤明顯的信息遺漏明顯的信息遺漏，其主要原因在于項目的范圍定義不當(dāng)加強對業(yè)務(wù)需求的處理不明顯的信息遺漏，往往是因為相關(guān)信息難以發(fā)現(xiàn)該類問題是最難以解決的問題，只能靠需求工程師的經(jīng)驗來加以避免第46頁，共63頁，2023年，2月20日，星期一5.常見的需求定義錯誤不必要的需求其一是用戶將之作為和開發(fā)人員談判的籌碼談判技巧其二是用戶在交流當(dāng)中，用戶總是傾向于表達各種各樣的需要根據(jù)業(yè)務(wù)需求進行用戶需求的過濾和選擇其三是需求開發(fā)人員“畫蛇添足”保持以用戶為中心不切實際的期望用戶并不掌握關(guān)于軟件系統(tǒng)構(gòu)建的相關(guān)技術(shù)知識，所以用戶可能會提出一些已有軟件技術(shù)無法實現(xiàn)的期望軟件開發(fā)者提供可行性、成本等足夠的技術(shù)參考信息，幫助用戶對其進行取舍和調(diào)整第47頁，共63頁，2023年，2月20日，星期一5.常見的需求定義錯誤第48頁，共63頁，2023年，2月20日，星期一需求工程的示例技術(shù)標書研究型描述第49頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？1、實現(xiàn)各部門的公文流轉(zhuǎn)無紙化、文檔一體化、業(yè)務(wù)管理的規(guī)范化、自動化和網(wǎng)絡(luò)化；2、實現(xiàn)工作流程合理化、高效化，決策支持科學(xué)化、準確化；3、統(tǒng)一辦公流程、規(guī)范公文格式，加強信息交流和共享，提高工作效率。第50頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？先進性：軟件系統(tǒng)采用三層B/S系統(tǒng)結(jié)構(gòu)，以“界面表示層－邏輯處理層－數(shù)據(jù)訪問層”分層設(shè)計實現(xiàn)。采用國際上先進成熟的、廠商廣泛支持的計算機技術(shù)、網(wǎng)絡(luò)技術(shù)與軟件技術(shù)對系統(tǒng)進行規(guī)劃，保證系統(tǒng)整體架構(gòu)在未來幾年內(nèi)都處于國際領(lǐng)先的地位。安全性：軟件系統(tǒng)具有較高的安全要求，系統(tǒng)必須具備充分的安全措施，包括具備嚴格的權(quán)限控制機制和完備的日志記錄，以確保信息安全?？煽啃裕罕ＷC系統(tǒng)核心功能可以7×24小時連續(xù)運行；規(guī)范性：系統(tǒng)必須遵循國家有關(guān)法律法規(guī)要求，符合國家有關(guān)標準要求以及關(guān)于信息系統(tǒng)建設(shè)的各項標準和規(guī)范。第51頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？收文管理應(yīng)包括:來文登記、擬辦、領(lǐng)導(dǎo)審批、辦理、歸檔、查詢統(tǒng)計等功能。附件支持WORD、PDF、EXCEL、HTML等文檔類型格式；需提供方便、靈活、直觀的文件批示處理；對收文的處理全過程進行自動化管理、跟蹤和記錄；在收文處理的過程中，支持電子印章、電子簽名或手寫批注等功能。來文登記：完成來文登記功能。登記來文基本信息（來文編號、來文標題、主題詞、來文單位、來文時間），還要對原文進行掃描處理，引入到公文庫中。并可完成收文辦文單打印功能。完成后啟動收文流轉(zhuǎn)流程。擬辦：查看公文的基本信息，原文內(nèi)容。簽錄擬辦意見，發(fā)送給領(lǐng)導(dǎo)審批。領(lǐng)導(dǎo)審批：查看公文的基本信息，原文內(nèi)容。簽錄批示意見，確定主辦部門、協(xié)辦部門。辦理：辦理人根據(jù)領(lǐng)導(dǎo)批示辦理，記錄辦理情況。歸檔：對辦理完結(jié)的來文歸檔，將來文信息、擬辦意見、領(lǐng)導(dǎo)批示、辦理情況等信息及來文掃描件發(fā)送到檔案管理系統(tǒng)，檔案科確認接收的文件，才屬于己歸檔文件。查詢統(tǒng)計：提供按來文編號、來文標題、主題詞、來文單位、來文時間等查詢統(tǒng)計功能，要求查詢統(tǒng)計結(jié)果可以打印。第52頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？編程應(yīng)遵循如下原則：唯一性：每個實體及其屬性必須有唯一的代碼來確切地定義?？蓴U充性：考慮到系統(tǒng)以后的發(fā)展，編號要留有余地。當(dāng)增加新的實體時，可以直接在原代碼的基礎(chǔ)上加以擴充，擴充后不會引起代碼體系的混亂，這樣就避免了重新設(shè)計代碼系統(tǒng)的麻煩。通用性：凡國家、行業(yè)、地方對編碼有統(tǒng)一標準和規(guī)定的，應(yīng)盡量使用標準代碼，代碼適用范圍越廣越好。沒有標準代碼的，投標方設(shè)計的代碼也應(yīng)該統(tǒng)一，如代碼長度與格式的統(tǒng)一。便于記憶和識別：代碼不但要具有一定的邏輯定義，也要盡量考慮用戶的使用習(xí)慣，使代碼便于記憶和識別，做到簡單明了簡短性：在滿足需要的前提下，代碼要盡可能短。編程人員必須對所有代碼進行嚴格自測。第53頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？驗收投標方需提供以下文檔：軟件需求分析報告軟件總體設(shè)計報告軟件操作手冊軟件配置手冊軟件試運行報告應(yīng)用軟件介質(zhì)第54頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)A—招標書）請說出下列需求的類型，是否存在問題？培訓(xùn)要求投標人必須提供相應(yīng)的應(yīng)用軟件技術(shù)和系統(tǒng)操作等方面的培訓(xùn)。投標人須在文件中提出全面、詳細的培訓(xùn)課程以及時間表交給業(yè)主，并在合同簽定后征得業(yè)主同意后實施。投標人應(yīng)提供面向系統(tǒng)管理員的應(yīng)用軟件系統(tǒng)結(jié)構(gòu)、日常維護等方面的培訓(xùn)。對于所有培訓(xùn)，投標人必須派出具有相應(yīng)專業(yè)資格和實際工作經(jīng)驗的人員進行培訓(xùn)。投標人須提供詳細的培訓(xùn)計劃。

以上培訓(xùn)內(nèi)容的培訓(xùn)費用均包含在投標報價內(nèi)，項目采購人不再另行支付第55頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)B—需求規(guī)格說明）請說出下列需求的類型，是否存在問題？2.1.開發(fā)意圖1.減少人力成本2.提高辦公效率3.成本統(tǒng)計、查詢4.歷史信息查詢5.支持WEB操作第56頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)B—需求規(guī)格說明）請說出下列需求的類型，是否存在問題？2.3.產(chǎn)品功能2.3.1.人員管理對本公司的人力資源進行管理。提供功能：新員工信息錄入、信息修改（晉升、部門調(diào)動、休假、婚姻狀況變更）、離職人員歸檔。注）該操作需要具有人員管理權(quán)限的人才可以進行。2.3.2.業(yè)務(wù)管理對本公司的業(yè)務(wù)進行管理。提供功能：新業(yè)務(wù)錄入、現(xiàn)有業(yè)務(wù)變更（計劃提前或延后、合同金額或付款方式變更、業(yè)務(wù)內(nèi)容變更）、已完成的業(yè)務(wù)歸檔。注）該操作需要具有業(yè)務(wù)管理權(quán)限的人才可以進行。第57頁，共63頁，2023年，2月20日，星期一實例分析（系統(tǒng)B—需求規(guī)格說明）請說出下列需求的類型，是否存在問題？2.4.1.擴展性要求結(jié)構(gòu)設(shè)計良好，二次開發(fā)成本要求低于本次開發(fā)成本30%能夠簡單的進行多語言版本改造。2.4.2.靈活性支持主流瀏覽器：IE7,8,FireFox2.0,Google瀏覽器。2.4.3.精度金額相關(guān)：小數(shù)點后保留2位有效數(shù)字；時間相關(guān)：精確到秒；傳輸過程中的精度：小數(shù)點后保留5位有效數(shù)字。2.4.4.響應(yīng)要求用戶登陸：<=0.5秒頁面跳轉(zhuǎn)：<=2秒2.4.5.