軟件開發(fā)項(xiàng)目需求分析與文檔撰寫規(guī)范引言在軟件開發(fā)項(xiàng)目中，需求分析是連接用戶需求與系統(tǒng)實(shí)現(xiàn)的關(guān)鍵橋梁，而需求文檔則是這一橋梁的“工程藍(lán)圖”。據(jù)IEEE（電氣和電子工程師協(xié)會）統(tǒng)計(jì)，約40%的項(xiàng)目失敗源于需求不明確或變更失控；CMMI（能力成熟度模型集成）也將“需求管理”列為軟件過程改進(jìn)的核心域之一。規(guī)范的需求分析與文檔撰寫，能有效減少歧義、控制變更、降低風(fēng)險(xiǎn)，確保項(xiàng)目交付符合用戶預(yù)期。本文結(jié)合行業(yè)標(biāo)準(zhǔn)（如IEEE____《軟件需求規(guī)格說明書模板》）與實(shí)踐經(jīng)驗(yàn)，系統(tǒng)闡述需求分析的全流程及文檔撰寫規(guī)范，為開發(fā)團(tuán)隊(duì)提供可落地的操作指南。一、需求分析的核心邏輯與流程需求分析的本質(zhì)是將用戶的“業(yè)務(wù)需求”轉(zhuǎn)化為“系統(tǒng)需求”，其核心目標(biāo)是明確“系統(tǒng)做什么”（功能需求）與“系統(tǒng)怎么做”（非功能需求）。完整的需求分析流程包括以下四個(gè)階段：（一）需求捕獲：從用戶聲音到原始需求需求捕獲是需求分析的起點(diǎn)，目標(biāo)是收集用戶的真實(shí)需求，避免“偽需求”。常見方法包括：1.用戶訪談（UserInterview）適用場景：獲取深層需求（如用戶的痛點(diǎn)、期望）、復(fù)雜業(yè)務(wù)流程（如企業(yè)內(nèi)部審批流程）。技巧：采用“開放式問題+封閉式問題”組合（如“您使用當(dāng)前系統(tǒng)時(shí)最困擾的是什么？”→“您希望系統(tǒng)增加自動提醒功能嗎？”）；避免引導(dǎo)性問題（如“您覺得我們的系統(tǒng)應(yīng)該增加支付功能，對嗎？”）；記錄訪談內(nèi)容（文字+錄音），后續(xù)整理為用戶需求列表。2.問卷調(diào)查（Survey）適用場景：獲取廣泛用戶的共性需求（如C端產(chǎn)品的用戶偏好）。技巧：問題要具體（如“您每周使用在線課程的時(shí)間是？”→選項(xiàng)：1-3小時(shí)/3-5小時(shí)/5小時(shí)以上）；樣本量足夠（建議覆蓋目標(biāo)用戶的80%以上）；用統(tǒng)計(jì)工具（如SPSS、問卷星）分析結(jié)果，提煉高頻需求。3.原型法（Prototype）適用場景：驗(yàn)證模糊需求（如用戶對界面布局的偏好）、減少歧義。技巧：制作低保真原型（如Axure、Sketch），重點(diǎn)展示核心功能流程；讓用戶親自操作原型，記錄反饋（如“注冊流程太復(fù)雜”“課程列表應(yīng)該按分類展示”）；快速迭代原型，直到用戶確認(rèn)需求。4.業(yè)務(wù)流程建模（BusinessProcessModeling）適用場景：梳理復(fù)雜業(yè)務(wù)流程（如電商的訂單處理流程、銀行的貸款審批流程）。技巧：用流程圖（Flowchart）或BPMN（業(yè)務(wù)流程建模符號）描述流程的起點(diǎn)、終點(diǎn)、步驟、參與者、判斷條件；與用戶確認(rèn)流程的準(zhǔn)確性（如“訂單支付成功后，系統(tǒng)是否自動通知倉庫發(fā)貨？”）。（二）需求分析與建模：從原始需求到系統(tǒng)需求需求捕獲得到的“原始需求”往往零散、模糊，需要通過分析與建模將其轉(zhuǎn)化為結(jié)構(gòu)化、可驗(yàn)證的“系統(tǒng)需求”。常見方法包括：1.用例分析（UseCaseAnalysis）目標(biāo)：描述系統(tǒng)的功能需求，明確“誰（參與者）”需要“做什么（用例）”。輸出：用例圖（UseCaseDiagram）+用例描述（UseCaseDescription）。用例描述模板（IEEE推薦）：字段說明用例名稱簡潔描述用例的功能（如“用戶注冊”“訂單支付”）參與者用例的執(zhí)行者（如“用戶”“系統(tǒng)管理員”“第三方支付接口”）前置條件用例執(zhí)行前必須滿足的條件（如“用戶未注冊”“賬戶余額充足”）基本流程用例的正常執(zhí)行步驟（按順序描述，如“1.用戶輸入手機(jī)號；2.系統(tǒng)發(fā)送驗(yàn)證碼；3.用戶輸入驗(yàn)證碼；4.系統(tǒng)驗(yàn)證通過，創(chuàng)建賬戶”）異常流程用例執(zhí)行中的異常情況（如“驗(yàn)證碼輸入錯(cuò)誤”→“系統(tǒng)提示錯(cuò)誤，允許重新輸入”）后置條件用例執(zhí)行成功后系統(tǒng)的狀態(tài)（如“用戶賬戶創(chuàng)建成功”“訂單狀態(tài)變?yōu)椤阎Ц丁保?.數(shù)據(jù)建模（DataModeling）目標(biāo)：描述系統(tǒng)的數(shù)據(jù)需求，明確“需要存儲什么數(shù)據(jù)”“數(shù)據(jù)之間的關(guān)系”。輸出：實(shí)體-關(guān)系圖（ERDiagram）+數(shù)據(jù)字典（DataDictionary）。ER圖元素：實(shí)體（Entity）：需要存儲的數(shù)據(jù)對象（如“用戶”“課程”“訂單”）；屬性（Attribute）：實(shí)體的特征（如“用戶”的屬性包括“手機(jī)號”“姓名”“性別”）；關(guān)系（Relationship）：實(shí)體之間的關(guān)聯(lián)（如“用戶”與“訂單”是“一對多”關(guān)系，一個(gè)用戶可以有多個(gè)訂單）；主鍵（PrimaryKey）：唯一標(biāo)識實(shí)體的屬性（如“用戶ID”“訂單ID”）。數(shù)據(jù)字典模板：字段說明數(shù)據(jù)項(xiàng)名稱數(shù)據(jù)的名稱（如“用戶ID”“課程名稱”）數(shù)據(jù)類型數(shù)據(jù)的類型（如“字符串”“整數(shù)”“日期”）長度數(shù)據(jù)的長度（如“手機(jī)號”長度為11位）約束條件數(shù)據(jù)的限制（如“用戶ID”不能為空、“課程名稱”必須唯一）描述數(shù)據(jù)的含義（如“用戶ID是用戶的唯一標(biāo)識”）3.非功能需求分析（Non-FunctionalRequirementAnalysis）目標(biāo)：描述系統(tǒng)的質(zhì)量屬性，明確“系統(tǒng)要做得怎么樣”。分類（ISO/IEC____《系統(tǒng)與軟件質(zhì)量模型》）：性能：系統(tǒng)的響應(yīng)時(shí)間、吞吐量、并發(fā)能力（如“用戶登錄響應(yīng)時(shí)間不超過2秒”“支持1000個(gè)并發(fā)用戶在線選課”）；可靠性：系統(tǒng)的可用性、容錯(cuò)性（如“系統(tǒng)全年可用性不低于99.9%”“數(shù)據(jù)庫崩潰后，30分鐘內(nèi)恢復(fù)數(shù)據(jù)”）；安全性：系統(tǒng)的保密性、完整性、訪問控制（如“用戶密碼采用SHA-256加密存儲”“只有管理員能刪除用戶數(shù)據(jù)”）；易用性：系統(tǒng)的學(xué)習(xí)成本、操作效率（如“新用戶注冊流程不超過3步”“用戶能在1分鐘內(nèi)找到所需課程”）；可維護(hù)性：系統(tǒng)的修改成本、擴(kuò)展性（如“新增課程類型時(shí)，無需修改核心代碼”“系統(tǒng)支持插件式擴(kuò)展”）。（三）需求驗(yàn)證：確保需求的正確性與可行性需求分析的輸出必須經(jīng)過驗(yàn)證，避免“需求錯(cuò)誤”流入后續(xù)開發(fā)階段。常見驗(yàn)證方法包括：1.需求評審（RequirementReview）參與人員：用戶代表、產(chǎn)品經(jīng)理、開發(fā)人員、測試人員、項(xiàng)目經(jīng)理。評審內(nèi)容：需求的完整性（是否覆蓋了所有用戶需求？）；需求的準(zhǔn)確性（是否符合用戶的真實(shí)意圖？）；需求的可行性（技術(shù)上是否能實(shí)現(xiàn)？成本是否可控？）；需求的一致性（術(shù)語、流程、數(shù)據(jù)是否一致？）。流程：1.評審前：分發(fā)需求文檔（如SRS）給評審人員，提前閱讀；2.評審中：召開會議，逐一討論需求，記錄評審意見（如“用戶注冊的異常流程未覆蓋‘手機(jī)號已注冊’的情況”）；3.評審后：根據(jù)評審意見修改需求文檔，重新提交評審，直到所有意見解決。2.原型測試（PrototypeTesting）目標(biāo)：通過原型驗(yàn)證需求的可理解性與可用性。流程：1.開發(fā)原型（低保真或高保真）；2.讓用戶試用原型，完成指定任務(wù)（如“注冊賬戶”“選一門課程”）；3.記錄用戶的反饋（如“原型的界面布局太混亂”“選課按鈕不明顯”）；4.修改原型，再次測試，直到用戶確認(rèn)。3.測試用例設(shè)計(jì)（TestCaseDesign）目標(biāo)：驗(yàn)證需求的可測試性（即需求是否能通過測試用例驗(yàn)證）。流程：1.根據(jù)需求文檔設(shè)計(jì)測試用例（如“用戶注冊”的測試用例包括“正確輸入手機(jī)號和驗(yàn)證碼”“輸入錯(cuò)誤驗(yàn)證碼”“輸入已注冊的手機(jī)號”）；2.檢查測試用例是否覆蓋了所有需求（如“用戶注冊”的基本流程和異常流程是否都有對應(yīng)的測試用例）；3.如果某個(gè)需求無法設(shè)計(jì)測試用例（如“系統(tǒng)要友好”），說明需求不明確，需要修改。（四）需求管理：從需求到交付的全生命周期跟蹤需求管理的目標(biāo)是控制需求變更，確保需求的一致性與可追溯性。常見工具包括：1.需求跟蹤矩陣（RequirementsTraceabilityMatrix,RTM）目標(biāo)：跟蹤需求的全生命周期（從原始需求到實(shí)現(xiàn)、測試、交付）。模板：原始需求ID系統(tǒng)需求ID用例ID設(shè)計(jì)文檔ID測試用例ID狀態(tài)（未實(shí)現(xiàn)/實(shí)現(xiàn)中/已實(shí)現(xiàn)）備注R1S1UC1D1TC1已實(shí)現(xiàn)用戶注冊功能2.變更控制流程（ChangeControlProcess）目標(biāo)：避免隨意變更，確保變更的必要性與影響可控。流程（IEEE推薦）：1.提交變更請求：用戶或開發(fā)人員提交變更請求（如“需要增加‘課程分享’功能”），包括變更的原因、內(nèi)容、優(yōu)先級；2.評估變更影響：項(xiàng)目經(jīng)理組織開發(fā)人員、測試人員評估變更的影響（如“增加‘課程分享’功能需要修改前端界面、后端接口、數(shù)據(jù)庫，預(yù)計(jì)耗時(shí)3天，成本增加5%”）；3.審批變更：變更控制委員會（CCB，由項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理、用戶代表組成）審批變更（如“同意變更，優(yōu)先級為高”）；4.實(shí)施變更：開發(fā)人員根據(jù)審批結(jié)果修改系統(tǒng)，測試人員測試變更；5.更新文檔：修改需求文檔（如SRS）、設(shè)計(jì)文檔、測試用例，確保文檔與系統(tǒng)一致；6.通知相關(guān)方：將變更結(jié)果通知用戶、開發(fā)人員、測試人員、項(xiàng)目經(jīng)理。二、需求文檔撰寫規(guī)范：從結(jié)構(gòu)化到標(biāo)準(zhǔn)化需求文檔是需求分析的輸出，是開發(fā)、測試、驗(yàn)收的依據(jù)。常見的需求文檔包括：《需求規(guī)格說明書》（SoftwareRequirementsSpecification,SRS）：最核心的需求文檔，描述系統(tǒng)的功能需求與非功能需求；《用戶手冊》（UserManual）：面向用戶的操作指南；《系統(tǒng)設(shè)計(jì)說明書》（SystemDesignSpecification,SDS）：面向開發(fā)人員的設(shè)計(jì)文檔（基于SRS）。本文重點(diǎn)介紹《需求規(guī)格說明書》（SRS）的撰寫規(guī)范（基于IEEE____標(biāo)準(zhǔn)）。（一）SRS的結(jié)構(gòu)與內(nèi)容要求SRS的結(jié)構(gòu)應(yīng)結(jié)構(gòu)化、層次清晰，便于閱讀與維護(hù)。以下是IEEE推薦的SRS模板：1.引言（Introduction）目的：說明SRS的編寫目的（如“本文檔描述在線教育平臺的需求，作為開發(fā)、測試、驗(yàn)收的依據(jù)”）；范圍：說明系統(tǒng)的邊界（如“本系統(tǒng)包括用戶注冊、登錄、選課、上課、作業(yè)、考試、管理等功能，不包括支付功能（由第三方支付接口實(shí)現(xiàn)）”）；定義、術(shù)語和縮寫：解釋文檔中使用的術(shù)語（如“參與者：用例的執(zhí)行者，包括用戶、系統(tǒng)管理員”）；參考文檔：列出編寫SRS時(shí)參考的文檔（如“《在線教育平臺用戶訪談記錄》《IEEE____標(biāo)準(zhǔn)》”）；概述：簡要描述SRS的結(jié)構(gòu)（如“本文檔分為引言、功能需求、非功能需求、系統(tǒng)架構(gòu)、接口需求、驗(yàn)收標(biāo)準(zhǔn)、附錄等部分”）。2.功能需求（FunctionalRequirements）用例模型：用用例圖描述系統(tǒng)的功能模塊（如“在線教育平臺的用例圖包括用戶注冊、登錄、選課、上課、作業(yè)、考試、管理等用例”）；用例描述：按“用例描述模板”詳細(xì)描述每個(gè)用例（如“用戶注冊”用例的基本流程、異常流程）；業(yè)務(wù)流程：用流程圖或BPMN描述關(guān)鍵業(yè)務(wù)流程（如“選課流程：用戶登錄→瀏覽課程→選擇課程→加入購物車→支付→選課成功”）；功能模塊劃分：按模塊劃分功能（如“用戶模塊：注冊、登錄、個(gè)人信息管理；課程模塊：選課、上課、作業(yè)、考試；管理模塊：用戶管理、課程管理、訂單管理”）。3.非功能需求（Non-FunctionalRequirements）性能需求：描述系統(tǒng)的響應(yīng)時(shí)間、吞吐量、并發(fā)能力（如“用戶登錄響應(yīng)時(shí)間不超過2秒；支持1000個(gè)并發(fā)用戶在線選課；訂單處理吞吐量不低于100筆/分鐘”）；可靠性需求：描述系統(tǒng)的可用性、容錯(cuò)性（如“系統(tǒng)全年可用性不低于99.9%；數(shù)據(jù)庫崩潰后，30分鐘內(nèi)恢復(fù)數(shù)據(jù)；系統(tǒng)支持?jǐn)帱c(diǎn)續(xù)傳（如上課視頻播放中斷后，重新播放時(shí)從斷點(diǎn)開始）”）；安全性需求：描述系統(tǒng)的保密性、完整性、訪問控制（如“用戶密碼采用SHA-256加密存儲；用戶的個(gè)人信息（如手機(jī)號、身份證號）采用AES-256加密傳輸；只有管理員能刪除用戶數(shù)據(jù)；系統(tǒng)支持多因素認(rèn)證（如手機(jī)號+驗(yàn)證碼登錄）”）；易用性需求：描述系統(tǒng)的學(xué)習(xí)成本、操作效率（如“新用戶注冊流程不超過3步；用戶能在1分鐘內(nèi)找到所需課程；界面采用MaterialDesign風(fēng)格，符合用戶的使用習(xí)慣”）；可維護(hù)性需求：描述系統(tǒng)的修改成本、擴(kuò)展性（如“系統(tǒng)采用微服務(wù)架構(gòu)，新增功能時(shí)無需修改其他服務(wù)；代碼采用Java語言，遵循阿里巴巴《Java開發(fā)手冊》；數(shù)據(jù)庫采用MySQL，使用ORM框架（如MyBatis），減少SQL語句的編寫”）；兼容性需求：描述系統(tǒng)的運(yùn)行環(huán)境（如“系統(tǒng)支持Windows、macOS、iOS、Android操作系統(tǒng)；支持Chrome、Firefox、Safari等主流瀏覽器；支持MySQL5.7及以上版本”）。4.系統(tǒng)架構(gòu)（SystemArchitecture）目標(biāo)：描述系統(tǒng)的整體結(jié)構(gòu)，明確“系統(tǒng)由哪些部分組成”“各部分之間的關(guān)系”。輸出：系統(tǒng)架構(gòu)圖（SystemArchitectureDiagram）+架構(gòu)描述。架構(gòu)描述模板：系統(tǒng)分層：如“系統(tǒng)采用三層架構(gòu)，包括presentation層（前端界面）、business層（業(yè)務(wù)邏輯）、data層（數(shù)據(jù)存儲）”；組件劃分：如“presentation層包括用戶端（Web/APP）、管理端（Web）；business層包括用戶服務(wù)、課程服務(wù)、訂單服務(wù)、支付服務(wù)；data層包括MySQL數(shù)據(jù)庫、Redis緩存、文件存儲（如阿里云OSS）”；接口描述：如“用戶服務(wù)提供注冊、登錄接口；課程服務(wù)提供選課、上課接口；支付服務(wù)調(diào)用第三方支付接口（如微信支付、支付寶）”。5.接口需求（InterfaceRequirements）目標(biāo)：描述系統(tǒng)與外部系統(tǒng)或組件的接口。分類：用戶接口：描述系統(tǒng)與用戶的交互界面（如“用戶端界面采用響應(yīng)式設(shè)計(jì)，適應(yīng)不同屏幕尺寸；管理端界面采用表格、表單、圖表等組件，便于數(shù)據(jù)查看與操作”）；外部系統(tǒng)接口：描述系統(tǒng)與第三方系統(tǒng)的接口（如“支付接口：調(diào)用微信支付的JSAPI接口，實(shí)現(xiàn)訂單支付；短信接口：調(diào)用阿里云短信接口，發(fā)送驗(yàn)證碼”）；6.驗(yàn)收標(biāo)準(zhǔn)（AcceptanceCriteria）目標(biāo)：描述系統(tǒng)驗(yàn)收的條件，明確“系統(tǒng)如何才算合格”。模板（基于BDD（行為驅(qū)動開發(fā)）風(fēng)格）：場景給定（Given）當(dāng)（When）那么（Then）用戶注冊成功用戶未注冊，系統(tǒng)正常運(yùn)行用戶輸入手機(jī)號、驗(yàn)證碼、密碼系統(tǒng)創(chuàng)建用戶賬戶，返回成功信息用戶注冊失敗用戶已注冊，系統(tǒng)正常運(yùn)行用戶輸入已注冊的手機(jī)號系統(tǒng)提示“手機(jī)號已注冊”，不創(chuàng)建賬戶訂單支付成功用戶已選課程，賬戶余額充足用戶點(diǎn)擊“支付”按鈕系統(tǒng)調(diào)用支付接口，訂單狀態(tài)變?yōu)椤耙阎Ц丁保ㄖ脩?.附錄（Appendix）附錄A：需求跟蹤矩陣（RTM）；附錄B：原型截圖（如低保真原型的注冊界面、選課界面）；附錄C：術(shù)語表（如“用例：描述系統(tǒng)的一個(gè)功能”）；附錄D：參考資料（如《在線教育平臺用戶訪談記錄》《IEEE____標(biāo)準(zhǔn)》）。（二）SRS的撰寫技巧與注意事項(xiàng)1.語言要求：準(zhǔn)確、簡潔、無歧義避免模糊詞匯：如“快速”“友好”“高效”，應(yīng)替換為具體的指標(biāo)（如“響應(yīng)時(shí)間不超過2秒”“注冊流程不超過3步”）；避免歧義：如“用戶可以修改個(gè)人信息”應(yīng)明確為“用戶可以修改手機(jī)號、姓名、頭像，不能修改用戶ID”；使用標(biāo)準(zhǔn)化術(shù)語：如采用IEEE、ISO的術(shù)語，避免使用方言或俚語（如“用戶”不要寫成“使用者”，“用例”不要寫成“功能點(diǎn)”）。2.結(jié)構(gòu)要求：層次清晰、邏輯一致采用分級標(biāo)題：如“2.功能需求”→“2.1用戶模塊”→“2.1.1用戶注冊”→“2.1.1.1用例描述”，便于導(dǎo)航；保持內(nèi)容一致：如“用戶注冊”的用例描述中的前置條件、基本流程應(yīng)與驗(yàn)收標(biāo)準(zhǔn)中的場景一致；使用列表與表格：如用表格描述用例、驗(yàn)收標(biāo)準(zhǔn)，用列表描述流程步驟，提高可讀性。3.版本管理：確保文檔的可追溯性版本號規(guī)則：采用“主版本號.次版本號.修訂號”（如V1.0.0表示初始版本，V1.0.1表示修訂了minor問題，V1.1.0表示增加了新功能）；版本記錄：在文檔的首頁添加版本記錄，包括版本號、修改日期、修改內(nèi)容、修改人（如“V1.0.0，____，初始版本，張三”；“V1.0.1，____，修改了用戶注冊的異常流程，李四”）；文檔存儲：使用版本控制工具（如Git、SVN）存儲文檔，避免文檔丟失或混亂。三、常見問題與對策（一）需求不明確表現(xiàn)：用戶說“我要一個(gè)好用的系統(tǒng)”，但無法描述具體功能；對策：用原型法讓用戶直觀看到系統(tǒng)的功能，通過“迭代-反饋”減少歧義；用開放式問題引導(dǎo)用戶（如“你覺得當(dāng)前系統(tǒng)最不好用的地方是什么？”）。（二）需求變更頻繁表現(xiàn)：用戶不斷提出新需求，導(dǎo)致開發(fā)進(jìn)度延遲；對策：建立變更控制流程，評估變更的必要性與影響；在項(xiàng)目初期與用戶確認(rèn)“需求凍結(jié)期”（如“項(xiàng)目啟動后2周內(nèi)，允許變更需求；2周后，只接受critical變更”）。（三）需求遺漏表現(xiàn)：開發(fā)完成后，用戶說“我需要的功能怎么沒有？”；對策：用需求跟蹤矩陣跟蹤每個(gè)需求的來源與實(shí)現(xiàn)；在需求捕獲階段，覆蓋所有用戶角色（如在線教育平臺的用戶包括學(xué)生、老師、管理員）。（四）需求與技術(shù)沖突表現(xiàn)：用戶要求“系統(tǒng)響應(yīng)時(shí)間不超過1秒”，但技術(shù)上無法實(shí)現(xiàn)；對策：與用戶溝通，說明技術(shù)限制，尋找替代方案（如“將響應(yīng)時(shí)間調(diào)整為2秒，同時(shí)優(yōu)化系統(tǒng)性能，如使用緩存、異步處理”）。四、案例分析：在線教育平臺需求分析與文檔撰寫（一）項(xiàng)目背景某教育機(jī)構(gòu)需要開發(fā)一個(gè)在線教育平臺，支持學(xué)生選課、上課、提交作業(yè)，老師發(fā)布課程、批改作業(yè)，管理員管理用戶與課程。（二）需求捕獲用戶訪談：與學(xué)生、老師、管理員溝通，捕獲原始需求（如“學(xué)生需要在線觀看課程視頻”“老師需要批改作業(yè)并給出評分”“管理員需要統(tǒng)計(jì)課程的報(bào)名人數(shù)”）；原型法：制作低保真原型（如Axure），展示注冊、登錄、選課、上課界面，讓用戶試用，反饋意見（如“選課界面應(yīng)該按分類展示課程”“作業(yè)提交界面需要支持上傳文件”）。（三）需求分析與建模用例分析：繪制用例圖，包括“學(xué)生注冊”“學(xué)生選課”“老師發(fā)布課程”“管理員管理用戶”等用例；編寫用例描述，明確每個(gè)用例的參與者、前置條件、基本流程、異常流程；數(shù)據(jù)建模：繪制ER圖，實(shí)體包括“用戶”（學(xué)生、老師、管理員）、“課程”、“作業(yè)”、“訂單”，關(guān)系包括“學(xué)生選課程”（多對多）、“老師發(fā)布課程”（一對多）、“學(xué)生提交作業(yè)”（一對多）；非