簡介需求分析模板聚焦軟件工程與系統(tǒng)工程中的需求分析環(huán)節(jié)面向系統(tǒng)分析員、軟件工程師及高校相關(guān)課程學(xué)習(xí)者幫助明確新系統(tǒng)的目的、范圍、定義與功能梳理從用戶需求收集到功能定義、系統(tǒng)目標(biāo)、測(cè)試環(huán)境與結(jié)果的全過程。資源共1個(gè)doc文檔壓縮包僅26KB雖體量不大但內(nèi)容完整以《高校工資管理系統(tǒng)需求分析報(bào)告》為案例覆蓋編寫目的、背景、功能定義、系統(tǒng)目標(biāo)、測(cè)試環(huán)境與結(jié)果等核心章節(jié)并給出用戶管理、員工信息管理、工資標(biāo)準(zhǔn)設(shè)定、工資信息管理四大模塊的功能劃分。讀者可直接參考該模板結(jié)構(gòu)快速套用到自身項(xiàng)目的需求分析文檔編寫中尤其適用于教學(xué)演示或入門實(shí)踐。已有282人瀏覽學(xué)習(xí)。1. 需求分析模板不是擺設(shè)這份高校工資管理系統(tǒng)文檔的干貨在哪高校工資管理系統(tǒng)這份需求分析報(bào)告拆下來最值錢的不是那串功能列表而是兩處容易被新手忽略的設(shè)計(jì)一是把“職務(wù)工資、職稱工資、其他工資”當(dāng)成獨(dú)立的標(biāo)準(zhǔn)表來維護(hù)二是把系統(tǒng)用戶硬性切成管理員和教職工兩級(jí)權(quán)限。后面所有開發(fā)、測(cè)試、驗(yàn)收的動(dòng)作都是從這兩條線上長出來的。這份文檔適合正在寫管理信息系統(tǒng)需求的人——軟件工程課設(shè)、畢業(yè)設(shè)計(jì)、公司里剛立項(xiàng)的HR或財(cái)務(wù)系統(tǒng)都能從它的模塊劃分、權(quán)限邊界和測(cè)試口徑里抄到作業(yè)。需求分析最怕寫成功能清單這份報(bào)告提供了一個(gè)能指導(dǎo)開發(fā)、也能用于驗(yàn)收的范本。2. 先拆功能模塊用戶管理、員工信息、工資標(biāo)準(zhǔn)的邊界往哪劃原文檔給了一張功能模塊結(jié)構(gòu)圖頂層是高校工資管理系統(tǒng)下面掛四個(gè)子模塊系統(tǒng)用戶管理、員工信息管理、工資標(biāo)準(zhǔn)設(shè)立、工資信息管理。需求分析階段最應(yīng)該做的就是把這四塊的邊界劃清楚——哪些數(shù)據(jù)歸誰管、哪些操作誰有權(quán)限碰。很多項(xiàng)目翻車不是因?yàn)榇a寫得爛而是需求階段就沒分好工。2.1 用戶管理兩級(jí)權(quán)限是安全設(shè)計(jì)不是登錄邏輯文檔里對(duì)用戶管理的定位很明確制定管理級(jí)別分為管理員和教職員工兩類。管理員對(duì)應(yīng)財(cái)務(wù)部門人員可以對(duì)系統(tǒng)做一切操作教職員工只能運(yùn)行個(gè)人工資查詢功能。這個(gè)劃分直接決定后面的權(quán)限體系怎么建。實(shí)際開發(fā)里這條需求落到數(shù)據(jù)庫就是一張sys_user表外加一個(gè)用戶類型字段。管理員和教職工操作的不是同一張表而是同一張表的不同接口。口令修改的需求也埋了一個(gè)隱形約束密碼不能在數(shù)據(jù)庫里明文存存的話至少要有個(gè)不可逆的摘要算法。文檔里沒有明說加密但“口令修改”功能一旦上驗(yàn)收明文存儲(chǔ)就過不了關(guān)。用戶管理模塊還包含添加用戶、修改用戶信息。注意這里的“用戶”是系統(tǒng)登錄賬號(hào)不是教職工檔案。很多初學(xué)者把用戶管理和員工信息管理混成一張表結(jié)果就是教職工離職后登錄賬號(hào)也刪了歷史工資單上的人員信息跟著沒了。需求階段先把這個(gè)區(qū)分寫清楚后面能少改一次表結(jié)構(gòu)。2.2 員工信息管理按學(xué)院組織數(shù)據(jù)是天然的歸屬維度員工信息管理模塊的功能是輸入、修改、刪除、查詢教職工基本信息。文檔里專門提了一句“在高校管理中按照學(xué)院對(duì)信息進(jìn)行管理”這一句很關(guān)鍵它意味著學(xué)院是數(shù)據(jù)的組織維度。設(shè)計(jì)員工表的時(shí)候?qū)W院字段不應(yīng)該是一個(gè)字符串而應(yīng)該落成一張部門表員工表里存部門ID。不然“按學(xué)院統(tǒng)計(jì)工資”這種后續(xù)需求一出來字符串字段就只能靠LIKE去匹配統(tǒng)計(jì)口徑說不清。員工信息里還隱含了兩個(gè)跟工資直接掛鉤的字段職務(wù)和職稱。文檔在后面工資標(biāo)準(zhǔn)設(shè)定模塊里說了“工資標(biāo)準(zhǔn)的依據(jù)恰好與教職員工的基本信息相一致形成對(duì)應(yīng)關(guān)系”。也就是說員工表里的職務(wù)、職稱就是查工資標(biāo)準(zhǔn)的鑰匙這兩列在需求階段就要確認(rèn)是必填項(xiàng)。另外“刪除”這個(gè)功能要小心物理刪掉一個(gè)員工他過往月份的工資記錄就會(huì)變成孤兒數(shù)據(jù)。需求文檔沒有明確說邏輯刪除還是物理刪除開發(fā)前需要跟財(cái)務(wù)確認(rèn)這屬于典型的待澄清點(diǎn)。文檔里寫“刪除”很輕松實(shí)際落到數(shù)據(jù)上一個(gè)離職員工和歷史工資表之間的關(guān)系不提前想清楚上線后補(bǔ)數(shù)據(jù)比寫代碼還痛苦。2.3 工資標(biāo)準(zhǔn)設(shè)定三類工資為什么不能揉在一張表里工資標(biāo)準(zhǔn)設(shè)定模塊包括職務(wù)工資標(biāo)準(zhǔn)、職稱工資標(biāo)準(zhǔn)、其他工資標(biāo)準(zhǔn)的設(shè)定、修改、刪除、保存。這個(gè)拆分是有講究的——職務(wù)工資按崗位級(jí)別走職稱工資按專業(yè)技術(shù)職稱走兩套體系互不搭界。舉個(gè)具體例子一個(gè)副教授兼系主任他的職務(wù)工資按“系主任”崗位算職稱工資按“副教授”算。如果把兩類標(biāo)準(zhǔn)塞進(jìn)同一張表要么出現(xiàn)同一人兩行記錄要么就得加類型字段區(qū)分查詢和統(tǒng)計(jì)都會(huì)繞路。拆成單獨(dú)的標(biāo)準(zhǔn)表各掛各的主鍵員工表里存職務(wù)和職稱兩個(gè)字段聯(lián)查時(shí)各取所需。其他工資標(biāo)準(zhǔn)是個(gè)兜底項(xiàng)績效、補(bǔ)貼、扣款之類都往里放。文檔沒展開其他工資包含什么但既然單獨(dú)列了“其他”就說明這類工資項(xiàng)的調(diào)整頻率比職務(wù)、職稱工資高做成單獨(dú)維護(hù)的字典表是合理的。工資標(biāo)準(zhǔn)獨(dú)立成表還有一個(gè)隱藏收益調(diào)薪不涉及改程序。財(cái)務(wù)在界面上把“教授”的職務(wù)工資從3500改成4000下個(gè)月生成工資表時(shí)全體教授自動(dòng)帶上新標(biāo)準(zhǔn)。如果當(dāng)初寫死在代碼里一次調(diào)薪就是一次發(fā)版。2.4 工資信息管理生成、查詢、修改、結(jié)算、統(tǒng)計(jì)、打印的完整鏈路工資信息管理模塊文檔里列的職責(zé)最多工資表生成、個(gè)人工資查詢、工資修改、工資結(jié)算、工資統(tǒng)計(jì)、工資表打印按月生成工資表并保存在數(shù)據(jù)庫中。這六個(gè)動(dòng)作是有順序的先生成再結(jié)算然后統(tǒng)計(jì)和打印查詢和修改穿插其中。從需求角度要抓住兩點(diǎn)一是“按月生成”說明時(shí)間維度是核心每月一張表二是“保存在數(shù)據(jù)庫中”說明歷史工資表要長留不是當(dāng)月算完就扔掉。“工資修改”這個(gè)功能要謹(jǐn)慎。如果允許財(cái)務(wù)隨便改工資表記錄那統(tǒng)計(jì)口徑就亂了。常見做法是讓工資修改走單獨(dú)的調(diào)整單改完之后在工資表里留一條變更記錄而不是直接UPDATE當(dāng)月數(shù)字。文檔里沒細(xì)到這個(gè)程度但需求評(píng)審時(shí)會(huì)把這個(gè)作為追問點(diǎn)提出來——財(cái)務(wù)能改什么、改了之后怎么留證據(jù)這兩件事不定清楚工資系統(tǒng)上線后必然對(duì)不上賬。3. 把需求落到數(shù)據(jù)與計(jì)算工資表生成、查詢統(tǒng)計(jì)的實(shí)現(xiàn)思路需求分析文檔寫得再好最終要變成能跑的程序中間還得過一道數(shù)據(jù)模型的橋。這一章把“職務(wù)工資職稱工資其他工資”的計(jì)算邏輯、月度工資表的生成流程以及查詢統(tǒng)計(jì)的維度拆開講。實(shí)現(xiàn)依據(jù)全部來自原文檔的功能定義但表結(jié)構(gòu)和計(jì)算細(xì)節(jié)屬于需求文檔沒寫全的部分按這套場(chǎng)景下最常見的做法補(bǔ)。3.1 工資構(gòu)成拆解三類工資的計(jì)算邏輯與對(duì)應(yīng)關(guān)系根據(jù)文檔的定義月工資由三塊構(gòu)成職務(wù)工資、職稱工資、其他工資。計(jì)算邏輯本身不復(fù)雜每個(gè)人按職務(wù)查職務(wù)工資標(biāo)準(zhǔn)表按職稱查職稱工資標(biāo)準(zhǔn)表其他工資按需取值三者相加就是當(dāng)月應(yīng)發(fā)。偽代碼寫出來是這個(gè)樣子# 單員工月度工資計(jì)算邏輯對(duì)應(yīng)文檔中的三類工資標(biāo)準(zhǔn) def calc_monthly_salary(employee, month): # 按職務(wù)查職務(wù)工資標(biāo)準(zhǔn)比如 系主任 - 3500 post_salary post_standard_table.get(employee.post) # 按職稱查職稱工資標(biāo)準(zhǔn)比如 副教授 - 1800 title_salary title_standard_table.get(employee.title) # 其他工資項(xiàng)可能是補(bǔ)貼、績效、扣款按員工單獨(dú)配置默認(rèn) 0 other_salary other_standard_table.get(employee.emp_id, default0) return { month: month, post_salary: post_salary, title_salary: title_salary, other_salary: other_salary, total: post_salary title_salary other_salary }參數(shù)說明employee.post是職務(wù)字段employee.title是職稱字段兩個(gè)維度獨(dú)立查表互不干擾other_standard_table按員工ID查其他工資配置查不到就返回0避免total出現(xiàn)空值。這里要留意的邊界情況員工沒有職稱怎么辦比如剛?cè)肼毜男姓藛T標(biāo)準(zhǔn)表里查不到對(duì)應(yīng)職務(wù)怎么辦。這兩個(gè)問題需求文檔沒覆蓋屬于開發(fā)前要跟財(cái)務(wù)確認(rèn)的點(diǎn)。我一般會(huì)在標(biāo)準(zhǔn)表里加一個(gè)“默認(rèn)檔位”記錄查不到時(shí)落到默認(rèn)檔同時(shí)記一條日志提醒維護(hù)人員補(bǔ)標(biāo)準(zhǔn)。還有一類常見誤用覺得“其他工資”沒人用就不做。結(jié)果月度績效一來財(cái)務(wù)只能在總金額上手工改一改就亂賬。寧可用一個(gè)空的配置表占位也別把其他工資合并進(jìn)職務(wù)工資里。3.2 月度工資表生成流程數(shù)據(jù)快照與記錄落庫月度工資表生成是系統(tǒng)的核心動(dòng)作。每月固定時(shí)間點(diǎn)觸發(fā)遍歷所有在職狀態(tài)的員工按當(dāng)時(shí)的工資標(biāo)準(zhǔn)計(jì)算把結(jié)果寫進(jìn)月度工資表。流程拆成四步鎖定員工范圍、讀取工資標(biāo)準(zhǔn)、計(jì)算金額、批量落庫。落庫這一步有個(gè)重要原則工資表里存的是金額快照不是員工ID的引用。意思是工資表記錄里要冗余“當(dāng)時(shí)職務(wù)工資是3500”這個(gè)數(shù)值而不是等查詢時(shí)再去關(guān)聯(lián)標(biāo)準(zhǔn)表。如果不冗余三個(gè)月后教授職務(wù)工資調(diào)到4000歷史月份的工資表查出來也會(huì)跟著變成4000財(cái)務(wù)對(duì)賬直接崩。生成語句可以寫成批量INSERT加JOIN效率比逐條算高很多-- 月度工資表生成示意從員工表與工資標(biāo)準(zhǔn)表聯(lián)查后批量落庫 INSERT INTO monthly_salary (emp_no, month, post_salary, title_salary, other_salary, total) SELECT e.emp_no, 2025-06, ps.amount, ts.amount, COALESCE(os.amount, 0), ps.amount ts.amount COALESCE(os.amount, 0) FROM employee e JOIN post_standard ps ON e.post ps.post JOIN title_standard ts ON e.title ts.title LEFT JOIN other_standard os ON e.emp_no os.emp_no WHERE e.status active;參數(shù)說明JOIN post_standard和JOIN title_standard是必須的內(nèi)連接每個(gè)正常員工都應(yīng)該有對(duì)應(yīng)的職務(wù)和職稱標(biāo)準(zhǔn)LEFT JOIN other_standard是左連接因?yàn)橛行﹩T工沒有單獨(dú)的其他工資配置COALESCE把空值轉(zhuǎn)成0保證總額算式不出現(xiàn)NULLWHERE e.status active把離職和掛起狀態(tài)的員工排除掉避免生成無效工資記錄。3.3 查詢與統(tǒng)計(jì)的維度設(shè)計(jì)按學(xué)院、職稱、月份聚合文檔里的查詢和統(tǒng)計(jì)需求可以拆成三個(gè)維度按人查個(gè)人工資查詢、按學(xué)院和職稱聚合工資統(tǒng)計(jì)、按月份對(duì)比。這三個(gè)維度對(duì)應(yīng)三條典型的 SQL 路徑。個(gè)人工資查詢的邏輯最簡單等值查詢按月過濾即可。工資統(tǒng)計(jì)稍微復(fù)雜一點(diǎn)需要按學(xué)院或職稱GROUP BY。月份對(duì)比則需要帶時(shí)間范圍的條件聚合。-- 按學(xué)院統(tǒng)計(jì)指定月份的工資總額與人數(shù) SELECT d.dept_name, COUNT(*) AS emp_cnt, SUM(m.total) AS total_pay FROM monthly_salary m JOIN employee e ON m.emp_no e.emp_no JOIN department d ON e.dept_no d.dept_no WHERE m.month 2025-06 GROUP BY d.dept_name ORDER BY total_pay DESC;這個(gè)查詢演示了兩個(gè)需求分析階段就要定的決策一是員工表必須帶dept_no外鍵不然按學(xué)院統(tǒng)計(jì)無從下手二是統(tǒng)計(jì)和明細(xì)分開看先出匯總再下鉆明細(xì)報(bào)表模塊基本都按這個(gè)模式走。統(tǒng)計(jì)維度看起來是查詢問題實(shí)際上在設(shè)計(jì)員工表和工資表時(shí)就已經(jīng)被決定了。3.4 用 SQL 驗(yàn)證需求四張核心表的字段設(shè)計(jì)與查詢對(duì)照把需求文檔翻譯成表結(jié)構(gòu)核心是四張表系統(tǒng)用戶表、員工信息表、工資標(biāo)準(zhǔn)表三類可視作一組、月度工資表。字段設(shè)計(jì)如下表名關(guān)鍵字段說明sys_useruser_id, user_name, password_hash, user_type, emp_nouser_type 區(qū)分管理員/教職工emp_no 關(guān)聯(lián)員工表employeeemp_no, name, dept_no, post, title, statusstatus 標(biāo)識(shí)在職/離職post 和 title 是工資計(jì)算鑰匙post_standardpost, amount職務(wù)工資標(biāo)準(zhǔn)post 為主鍵title_standardtitle, amount職稱工資標(biāo)準(zhǔn)title 為主鍵other_standardemp_no, item_name, amount其他工資項(xiàng)按員工配置monthly_salaryemp_no, month, post_salary, title_salary, other_salary, total金額快照冗余month 參與主鍵表結(jié)構(gòu)一旦立住需求文檔里的功能就可以逐條對(duì)應(yīng) SQL 驗(yàn)證。員工信息錄入對(duì)應(yīng)INSERT INTO employee工資標(biāo)準(zhǔn)設(shè)定對(duì)應(yīng)UPDATE post_standard SET amount月度工資表生成對(duì)應(yīng)上一小節(jié)的INSERT SELECT。需求分析做得好不好就看每個(gè)功能能不能在一張表或者一條 SQL 上找到落點(diǎn)。找不到落點(diǎn)的需求不是沒想清楚就是做不出來。4. 測(cè)試驗(yàn)收復(fù)盤Delphi 7.0 時(shí)代的功能測(cè)試怎么設(shè)計(jì)用例原文檔的測(cè)試部分分成測(cè)試概要、測(cè)試結(jié)果及發(fā)現(xiàn)、系統(tǒng)的運(yùn)行評(píng)價(jià)三塊但寫得比較簡略只給了一條“功能測(cè)試1、功能測(cè)試2完全正確實(shí)現(xiàn)”的結(jié)論測(cè)試概要要求的表格沒有真正展開也沒有說明實(shí)際測(cè)試和測(cè)試計(jì)劃之間的差異。這一章按測(cè)試設(shè)計(jì)的常規(guī)做法把這個(gè)項(xiàng)目的測(cè)試思路補(bǔ)全。測(cè)試環(huán)境那一段反而是一個(gè)有價(jià)值的遺產(chǎn)——它提醒我們需求階段的測(cè)試約束要對(duì)開發(fā)形成真實(shí)的限制。4.1 測(cè)試環(huán)境約束Pentium Ⅲ與128M內(nèi)存背后的取舍文檔里的測(cè)試環(huán)境寫得具體CPU Pentium Ⅲ以上、內(nèi)存128M以上、Windows 98以上、開發(fā)工具Delphi 7.0。這套配置放在今天看很老但在當(dāng)年是實(shí)打?qū)嵉募s束。128M內(nèi)存意味著客戶端不能把整個(gè)工資表一次性加載到內(nèi)存里Delphi 7 開發(fā)這類系統(tǒng)典型的是 C/S 架構(gòu)客戶端直連數(shù)據(jù)庫。如果教職工有幾千人、每人每月一條工資記錄不翻頁全量加載會(huì)直接把客戶端卡死。所以月度工資表查詢必須帶月份篩選和分頁條件這是硬件環(huán)境倒逼出來的設(shè)計(jì)。Pentium Ⅲ和128M的性能約束還影響一個(gè)決策月度工資生成盡量用數(shù)據(jù)庫端的批量操作而不是在客戶端逐行計(jì)算再寫回。把計(jì)算放到數(shù)據(jù)庫的存儲(chǔ)過程或一條INSERT SELECT里網(wǎng)絡(luò)傳輸和客戶端內(nèi)存占用都小很多。這條取舍到現(xiàn)在做 Web 系統(tǒng)依然成立只是很多人已經(jīng)不記得當(dāng)初為什么這么定了。測(cè)試環(huán)境還有一個(gè)容易忽略的點(diǎn)Delphi 7 的客戶端程序通常要裝數(shù)據(jù)庫引擎才能連庫測(cè)試時(shí)需要把引擎裝進(jìn)標(biāo)準(zhǔn)測(cè)試鏡像里。也就是說功能測(cè)試之前要有一段“環(huán)境預(yù)檢”——驗(yàn)證客戶端能連通數(shù)據(jù)庫、打印機(jī)驅(qū)動(dòng)正常、局域網(wǎng)權(quán)限到位。這套流程放到現(xiàn)在的 Web 系統(tǒng)里就是“測(cè)試環(huán)境部署檢查”性質(zhì)一樣。4.2 功能測(cè)試1與功能測(cè)試2輸入與刪除鏈路的驗(yàn)收要點(diǎn)原文檔的測(cè)試結(jié)論只有“完全正確實(shí)現(xiàn)”六個(gè)字這顯然是測(cè)試記錄而不是測(cè)試設(shè)計(jì)。按正規(guī)做法人員信息輸入和刪除兩個(gè)功能至少要覆蓋正常路徑、異常路徑和邊界路徑。補(bǔ)一份用例表供參考用例標(biāo)識(shí)測(cè)試內(nèi)容操作步驟預(yù)期結(jié)果TC-01-01員工信息正常錄入填寫完整信息并保存保存成功列表可見TC-01-02員工信息必填校驗(yàn)工號(hào)留空提交提示工號(hào)必填數(shù)據(jù)不落庫TC-01-03員工工號(hào)重復(fù)錄入輸入已存在工號(hào)提示唯一約束沖突TC-02-01員工信息正常刪除選擇無關(guān)聯(lián)記錄刪除記錄從列表移除TC-02-02刪除已有工資記錄員工刪除有歷史工資的員工提示存在關(guān)聯(lián)工資記錄需歸檔處理TC-02-02 是這次復(fù)盤里最值得補(bǔ)的一條。文檔里的刪除功能沒提約束但系統(tǒng)里有月度工資表員工一旦被物理刪除歷史工資表里指向他的記錄就懸空了。真正上線前必須跟財(cái)務(wù)確認(rèn)離職員工是保留檔案、邏輯刪除還是允許物理刪除但歷史工資表保留冗余字段。這個(gè)確認(rèn)做不做直接決定刪除功能能不能通過驗(yàn)收。原文檔在測(cè)試概要一節(jié)還要求“指明實(shí)際進(jìn)行的測(cè)試工作內(nèi)容與測(cè)試計(jì)劃中預(yù)先設(shè)計(jì)的內(nèi)容之間的差別說明作出這種改變的原因”這層記錄在正文里缺失了。實(shí)際操作時(shí)如果功能測(cè)試1按計(jì)劃要測(cè)八條用例實(shí)際只跑了兩條就得寫清原因——常見的是測(cè)試周期被壓縮或者某個(gè)用例依賴的功能還沒開發(fā)完。測(cè)試結(jié)論“完全正確實(shí)現(xiàn)”要成立前面必須有這條證據(jù)鏈不然驗(yàn)收方?jīng)]法判斷測(cè)試范圍到底夠不夠。4.3 測(cè)試通過不等于上線運(yùn)行評(píng)價(jià)里的六個(gè)非功能指標(biāo)文檔末尾的運(yùn)行評(píng)價(jià)部分列了六項(xiàng)硬件接口打印機(jī)接口、軟件接口局域網(wǎng)通信、故障處理重新安裝軟件、檢查網(wǎng)絡(luò)、安全保密權(quán)限和密碼驗(yàn)證、可移植性適用于各種操作系統(tǒng)、可維護(hù)性簡單維護(hù)。這六項(xiàng)里打印機(jī)接口和局域網(wǎng)通信是實(shí)打?qū)嵉男枨?。工資表要打印必須有報(bào)表格式模板系統(tǒng)要在局域網(wǎng)里共享數(shù)據(jù)數(shù)據(jù)庫和應(yīng)用要支持多客戶端并發(fā)訪問。安全保密對(duì)應(yīng)前面兩級(jí)權(quán)限設(shè)計(jì)這條已經(jīng)落在系統(tǒng)功能里了驗(yàn)收時(shí)用普通用戶賬號(hào)登錄看能不能摸到管理菜單一試便知。可移植性那句“適用于各種操作系統(tǒng)”是典型的需求文檔空話。Delphi 7 在 Windows 下開發(fā)的 VCL 應(yīng)用不可能跑在 Linux 或 macOS 上這條寫成“支持 Windows 98/2000/XP”才算數(shù)。故障處理也只寫了“重新安裝該軟件檢查網(wǎng)絡(luò)是否正?！甭涞介_發(fā)上要區(qū)分兩層程序異常要有日志定位網(wǎng)絡(luò)異常要有重連機(jī)制。這些非功能指標(biāo)還有個(gè)共通問題沒有配套測(cè)試數(shù)據(jù)。按常規(guī)做法測(cè)試前要準(zhǔn)備三到五個(gè)學(xué)院的教職工數(shù)據(jù)覆蓋有職稱和無職稱、有其他工資項(xiàng)和沒有其他工資項(xiàng)、在職和離職這幾類組合。數(shù)據(jù)不齊功能測(cè)試很容易出現(xiàn)“測(cè)了等于沒測(cè)”——你沒法證明刪除一個(gè)無職稱員工和有職稱員工走的是同一條邏輯。需求文檔如果能把測(cè)試數(shù)據(jù)的要求寫進(jìn)去后面驗(yàn)收會(huì)順暢很多。5. 需求分析避坑指南權(quán)限、工資標(biāo)準(zhǔn)、歷史數(shù)據(jù)三處高頻翻車點(diǎn)這份高校工資管理系統(tǒng)文檔本身不算差但需求分析這件事藏坑的地方往往不在寫出來的部分而在沒寫出來的部分。這一章列五條從類似項(xiàng)目里踩出來的坑每條按“現(xiàn)象、原因、解決”三步說清楚方便拿這份文檔做模板時(shí)提前對(duì)照。5.1 角色與人不分用戶表和員工表被當(dāng)成一張表現(xiàn)象開發(fā)時(shí)把“系統(tǒng)用戶管理”和“員工信息管理”合并成一張表以為教職工就是登錄用戶登錄用戶就是教職工。結(jié)果財(cái)務(wù)要開除一個(gè)沒有系統(tǒng)賬號(hào)的臨時(shí)工系統(tǒng)里壓根找不到這個(gè)人。原因需求文檔里“用戶”出現(xiàn)了兩層含義——系統(tǒng)登錄賬號(hào)和教職工檔案。文檔本身做了區(qū)分但實(shí)現(xiàn)時(shí)容易被“用戶”這個(gè)詞帶跑。解決建兩張表。sys_user管登錄、口令、權(quán)限級(jí)別employee管姓名、學(xué)院、職務(wù)、職稱。sys_user通過emp_no關(guān)聯(lián)employee一個(gè)教職工可以沒有系統(tǒng)賬號(hào)一個(gè)系統(tǒng)賬號(hào)必須對(duì)應(yīng)一個(gè)教職工。權(quán)限判斷只看sys_user.user_type數(shù)據(jù)操作只看employee。5.2 工資標(biāo)準(zhǔn)寫死在代碼里一次調(diào)薪一次發(fā)版現(xiàn)象第一版功能測(cè)試全過上線后財(cái)務(wù)要調(diào)整職稱工資標(biāo)準(zhǔn)開發(fā)改代碼、重新編譯、分發(fā)客戶端一次調(diào)薪折騰三天。原因需求文檔里雖然有工資標(biāo)準(zhǔn)設(shè)定模塊但開發(fā)優(yōu)先級(jí)被排到最后初期為了快速跑通流程直接把金額常量寫進(jìn)代碼。解決工資標(biāo)準(zhǔn)必須在第一版就獨(dú)立成表。職務(wù)工資標(biāo)準(zhǔn)、職稱工資標(biāo)準(zhǔn)、其他工資標(biāo)準(zhǔn)三張表建好配套增加維護(hù)界面。調(diào)薪就是改數(shù)據(jù)改完下個(gè)月工資表自動(dòng)按新標(biāo)準(zhǔn)算。這也是這份需求文檔本身的設(shè)計(jì)意圖照做能省掉后面所有的調(diào)薪發(fā)版。5.3 工資表不留金額快照歷史月份數(shù)據(jù)跟著標(biāo)準(zhǔn)變現(xiàn)象某月調(diào)整了副教授職稱工資財(cái)務(wù)對(duì)賬時(shí)發(fā)現(xiàn)三個(gè)月前已封賬的工資表總額也變了。原因月度工資表只存了員工ID和月份沒存金額查詢時(shí)實(shí)時(shí)關(guān)聯(lián)最新標(biāo)準(zhǔn)表。標(biāo)準(zhǔn)表一變歷史查詢結(jié)果跟著變。解決生成月度工資表時(shí)把職務(wù)工資、職稱工資、其他工資、合計(jì)金額全部冗余到工資表記錄里。標(biāo)準(zhǔn)表負(fù)責(zé)“下個(gè)月怎么算”工資表負(fù)責(zé)“當(dāng)時(shí)算出來是多少”。兩邊各司其職歷史數(shù)據(jù)永遠(yuǎn)穩(wěn)定。這也是第3章那條INSERT SELECT里把金額快照落庫的原因。5.4 測(cè)試只走正常路徑刪除、重復(fù)、越權(quán)全沒覆蓋現(xiàn)象功能測(cè)試1和功能測(cè)試2都過了上線第一天普通教師在權(quán)限菜單里看到了員工管理入口點(diǎn)進(jìn)去雖然報(bào)錯(cuò)但界面已經(jīng)暴露了越權(quán)路徑。原因測(cè)試用例跟著功能清單走輸入測(cè)成功、刪除測(cè)成功就收工沒有從角色權(quán)限和數(shù)據(jù)完整性角度補(bǔ)反向用例。解決每個(gè)功能寫用例時(shí)配一組反向場(chǎng)景。員工錄入要測(cè)空工號(hào)、重復(fù)工號(hào)刪除要測(cè)有關(guān)聯(lián)工資記錄的情況權(quán)限必須單獨(dú)列用例——用普通用戶身份調(diào)管理員的增刪改接口預(yù)期結(jié)果應(yīng)該是直接攔截。文檔里的“教職員工只能查詢和打印”要落到每個(gè)管理功能的反向用例上才算驗(yàn)完。5.5 非功能指標(biāo)寫成空話可移植性承諾做不到現(xiàn)象需求文檔寫“可移植性適用于各種操作系統(tǒng)”開發(fā)驗(yàn)收時(shí)問“Linux行不行”答不上來。原因可移植性、可維護(hù)性這類詞是模板話術(shù)寫文檔的人沒想過驗(yàn)證方法開發(fā)的人也沒當(dāng)約束。解決運(yùn)行評(píng)價(jià)里的每一條都改成可驗(yàn)證的語句。比如“可移植性”改成“支持 Windows 98/2000/XP數(shù)據(jù)庫服務(wù)端支持局域網(wǎng)多客戶端訪問”“可維護(hù)性”改成“預(yù)留日志輸出程序異常時(shí)能在日志中定位到模塊和操作人”。需求階段的指標(biāo)一旦能被驗(yàn)證后面就沒有扯皮空間。6. 把需求文檔用活轉(zhuǎn)數(shù)據(jù)字典、用例清單和需求跟蹤矩陣需求分析文檔的價(jià)值不在寫完那一刻而在后續(xù)開發(fā)和驗(yàn)收的每個(gè)環(huán)節(jié)。這一章給一個(gè)通用技巧把文檔里的功能定義結(jié)構(gòu)化直接生成供開發(fā)對(duì)照的清單。這個(gè)方法對(duì)任何管理信息系統(tǒng)類需求都通用我從做完這個(gè)工資系統(tǒng)項(xiàng)目之后一直這么干。6.1 先建數(shù)據(jù)字典把功能描述翻成字段拿到文檔把每個(gè)模塊里出現(xiàn)的名詞抄出來配上類型和約束。“員工基本信息”拆成工號(hào)、姓名、學(xué)院、職務(wù)、職稱工號(hào)必填唯一“工資標(biāo)準(zhǔn)”拆成職務(wù)、職稱、其他三類金額表“月度工資表”拆成月份、員工、三類金額、合計(jì)。不用等開發(fā)提綱這步在需求評(píng)審前就能做完。字段級(jí)約束寫清楚開發(fā)拿到手里的就不是一段描述文字而是一張可以直接建表的清單。6.2 再生成需求跟蹤矩陣一組腳本搞定驗(yàn)收清單文檔里的功能定義有七處員工信息錄入、修改、刪除工資標(biāo)準(zhǔn)設(shè)定工資信息瀏覽工資表創(chuàng)建工資調(diào)整工資統(tǒng)計(jì)加上用戶管理。逐條映射成“角色加操作加預(yù)期結(jié)果”的卡片用一段腳本生成需求跟蹤矩陣開發(fā)、測(cè)試、驗(yàn)收共用一份# 從功能定義生成需求跟蹤矩陣RTM供開發(fā)和測(cè)試對(duì)照 features [ {fid: F01, func: 員工信息錄入, module: 員工信息管理, role: 管理員, acceptance: 錄入后列表立即可查工號(hào)重復(fù)被攔截}, {fid: F02, func: 員工信息刪除, module: 員工信息管理, role: 管理員, acceptance: 刪除后列表移除歷史工資記錄不受影響}, {fid: F03, func: 工資標(biāo)準(zhǔn)設(shè)定, module: 工資標(biāo)準(zhǔn)設(shè)定, role: 管理員, acceptance: 三類標(biāo)準(zhǔn)均可增刪改改動(dòng)下月生效}, {fid: F04, func: 月度工資表生成, module: 工資信息管理, role: 系統(tǒng)定時(shí), acceptance: 按月生成歷史月份數(shù)據(jù)保持快照}, {fid: F05, func: 個(gè)人工資查詢, module: 工資信息管理, role: 教職員工, acceptance: 僅能查詢本人工資記錄}, {fid: F06, func: 工資統(tǒng)計(jì), module: 工資信息管理, role: 管理員, acceptance: 按學(xué)院/職稱維度匯總}, {fid: F07, func: 用戶管理, module: 用戶管理, role: 管理員, acceptance: 可添加/修改用戶口令權(quán)限級(jí)別生效}, ] # 輸出 Markdown 表格直接貼進(jìn)項(xiàng)目文檔 print(| 需求ID | 功能 | 模塊 | 角色 | 驗(yàn)收標(biāo)準(zhǔn) |) print(|--------|------|------|------|----------|) for f in features: print(f| {f[fid]} | {f[func]} | {f[module]} | {f[role]} | {f[acceptance]} |)這段腳本的要點(diǎn)在于把驗(yàn)收標(biāo)準(zhǔn)寫成“可觀察的行為”而不是“系統(tǒng)應(yīng)正?！薄肮δ苷_”這類空話。F05 那條最典型——它把文檔里那句“教職員工只能查詢”落成了“僅能查詢本人工資記錄”測(cè)試時(shí)拿普通用戶登錄多查一條別人的記錄就算失敗。角色字段單獨(dú)列出來是為了讓權(quán)限測(cè)試有據(jù)可依。當(dāng)年做一個(gè)類似的人事系統(tǒng)我把需求文檔背得滾瓜爛熟結(jié)果第一個(gè)月工資表出來就對(duì)不上賬——因?yàn)闅v史月份數(shù)據(jù)被新標(biāo)準(zhǔn)帶偏了。那次返工之后我養(yǎng)成了一個(gè)習(xí)慣拿到任何需求文檔先干兩件事一是把所有“標(biāo)準(zhǔn)”改成獨(dú)立字典表二是把每項(xiàng)功能定義拆成“角色、動(dòng)作、數(shù)據(jù)對(duì)象、驗(yàn)收標(biāo)準(zhǔn)”四列拆完文檔里沒寫的洞自己就露出來了。這份高校工資管理系統(tǒng)需求分析報(bào)告結(jié)構(gòu)上夠參考直接拿來當(dāng)?shù)装灏研Ｃ?、模塊、工資項(xiàng)換成自己項(xiàng)目的開工會(huì)快很多。照這個(gè)思路過一遍能省掉的返工比想象中多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取