指南需求分析過(guò)程

需求分析過(guò)程指南Version0.1修訂歷史日期版本描述作者2010-09-110.1需求分析過(guò)程指南初稿譚勇

目錄TOC\o"1-3"\h\z1 緒言和目標(biāo) 31.1 目的 31.2 范圍 31.3 定義及縮寫 31.4 參考 32 角色和職責(zé) 33 進(jìn)入標(biāo)準(zhǔn) 34 輸入 35 過(guò)程 45.1 需求研發(fā) 45.2 變更控制 46 輸出 47 退出標(biāo)準(zhǔn) 48 控制機(jī)制 49 度量 4

緒言和目標(biāo)目的本文檔為軟件項(xiàng)目開(kāi)發(fā)中需求分析工作提供了一個(gè)可遵循的規(guī)范標(biāo)準(zhǔn)，通過(guò)本規(guī)范的使用可以提高需求分析工作的質(zhì)量、可管理性、可跟蹤性和可維護(hù)性，促進(jìn)在業(yè)務(wù)部門、技術(shù)部門和開(kāi)發(fā)商之間的對(duì)系統(tǒng)需求的充分的共同理解，提高項(xiàng)目的質(zhì)量和用戶滿意度。范圍本文檔主要面向的讀者和使用人員是：管理應(yīng)用開(kāi)發(fā)的有關(guān)人員，開(kāi)發(fā)商的設(shè)計(jì)開(kāi)發(fā)人員。文檔概述本文檔描述了軟件項(xiàng)目開(kāi)發(fā)中，需求分析工作應(yīng)遵循的過(guò)程規(guī)范、基本原則和可選擇的需求分析方法。定義及縮寫縮寫定義需求系統(tǒng)必須滿足的條件和實(shí)現(xiàn)的功能需求管理對(duì)系統(tǒng)需求進(jìn)行引入、組織和文檔化的一種系統(tǒng)化的方法與步驟，以及建立和維護(hù)開(kāi)發(fā)人員與業(yè)務(wù)部門之間關(guān)于系統(tǒng)需求變更的確認(rèn)的過(guò)程參考文檔名標(biāo)題《軟件工程——實(shí)踐者的研究方法》需求分析過(guò)程標(biāo)準(zhǔn)需求管理流程分為四個(gè)階段：階段工作內(nèi)容提交成果責(zé)任人確認(rèn)人1業(yè)務(wù)需求調(diào)研《業(yè)務(wù)需求說(shuō)明書》需求管理人員業(yè)務(wù)部門負(fù)責(zé)人2確定系統(tǒng)需求《系統(tǒng)需求說(shuō)明書》需求管理人員、系統(tǒng)架構(gòu)管理人員技術(shù)管理部門負(fù)責(zé)人3詳細(xì)需求調(diào)研和需求分析《系統(tǒng)需求規(guī)格說(shuō)明書》需求管理人員、系統(tǒng)架構(gòu)管理人員、系統(tǒng)開(kāi)發(fā)商業(yè)務(wù)部門項(xiàng)目經(jīng)理、技術(shù)管理部門項(xiàng)目經(jīng)理4需求變更管理《系統(tǒng)變更單》需求管理人員、系統(tǒng)架構(gòu)管理人員、系統(tǒng)開(kāi)發(fā)商業(yè)務(wù)部門負(fù)責(zé)人、技術(shù)管理部門負(fù)責(zé)人第一階段主要對(duì)應(yīng)于業(yè)務(wù)部門確定的業(yè)務(wù)需求。第二階段主要對(duì)應(yīng)于技術(shù)管理部門確定的系統(tǒng)范圍和系統(tǒng)需求。前兩個(gè)階段對(duì)應(yīng)于項(xiàng)目合同簽訂前的活動(dòng)，需求管理人員必須完成制定系統(tǒng)的高層需求的工作。第三階段主要對(duì)應(yīng)于系統(tǒng)開(kāi)發(fā)商對(duì)業(yè)務(wù)需求和系統(tǒng)需求的細(xì)化和分析，是項(xiàng)目合同簽訂后的活動(dòng)。第四階段主要對(duì)應(yīng)于前三階段的提交成果產(chǎn)生基線版本后需要對(duì)需求內(nèi)容進(jìn)行修改時(shí)的活動(dòng)，是貫穿于系統(tǒng)整個(gè)生命周期的活動(dòng)。因?yàn)樾枨笊婕皬母叩降偷牟煌母爬▽哟?，出于分工的需要，需求管理人員將持續(xù)維護(hù)的高層需求，并管理開(kāi)發(fā)商維護(hù)系統(tǒng)的詳細(xì)需求。業(yè)務(wù)需求調(diào)研業(yè)務(wù)需求反映：業(yè)務(wù)部門對(duì)系統(tǒng)高層次的目標(biāo)要求；用戶對(duì)系統(tǒng)使用和運(yùn)行方式的重要規(guī)定；業(yè)務(wù)涉及的組織機(jī)構(gòu)；主要的業(yè)務(wù)流程和參與角色；重要的影響到系統(tǒng)的外部約束和假設(shè)（如必須遵從的標(biāo)準(zhǔn)、規(guī)范，與其他部門的接口，其它關(guān)聯(lián)的系統(tǒng)，和業(yè)務(wù)有關(guān)的法律、法規(guī)等）。業(yè)務(wù)需求調(diào)研階段產(chǎn)生的提交成果為《業(yè)務(wù)需求說(shuō)明書》。需求管理人員制訂需求調(diào)研計(jì)劃需求管理人員與業(yè)務(wù)部門有關(guān)人員會(huì)談，了解業(yè)務(wù)部門對(duì)系統(tǒng)高層次的目標(biāo)要求，并共同確定：1）需求信息（包括組織機(jī)構(gòu)信息、標(biāo)準(zhǔn)、規(guī)范、法律、法規(guī)、與其他部門和業(yè)務(wù)的接口、其它關(guān)聯(lián)的系統(tǒng)等）的獲得途徑和時(shí)間進(jìn)度，這部分信息的獲取一般采用資料收集的手段；2）要進(jìn)行調(diào)研的主要業(yè)務(wù)流程、指定的描述流程的業(yè)務(wù)人員和時(shí)間安排，提供這部分調(diào)研一般采用與有關(guān)業(yè)務(wù)人員面談的手段。3）需求調(diào)研計(jì)劃納入到《項(xiàng)目工作計(jì)劃》中。需求管理人員調(diào)研業(yè)務(wù)流程將要涉及到的業(yè)務(wù)流程明確下來(lái)之后，需求管理人員在業(yè)務(wù)部門的協(xié)調(diào)下，按計(jì)劃調(diào)研確定每一個(gè)業(yè)務(wù)流程中的參與人員角色、每個(gè)角色所執(zhí)行的活動(dòng)、在活動(dòng)中所使用的業(yè)務(wù)實(shí)體、以及在活動(dòng)中要遵循的一些業(yè)務(wù)規(guī)則。調(diào)研結(jié)果填寫在《需求調(diào)研表》中。需求管理人員撰寫《業(yè)務(wù)需求說(shuō)明書》需求管理人員通過(guò)對(duì)前一階段業(yè)務(wù)需求調(diào)研結(jié)果的整理，形成《業(yè)務(wù)需求說(shuō)明書》。業(yè)務(wù)部門負(fù)責(zé)人確認(rèn)《業(yè)務(wù)需求說(shuō)明書》業(yè)務(wù)部門負(fù)責(zé)人審閱（或安排相關(guān)業(yè)務(wù)人員審閱）并簽字確認(rèn)《業(yè)務(wù)需求說(shuō)明書》后，作為一個(gè)基線版本，將不允許直接改動(dòng)，除非通過(guò)正規(guī)的變更流程。當(dāng)有較大的變更時(shí)，應(yīng)創(chuàng)建新的基線版本。確定系統(tǒng)需求需求管理人員、系統(tǒng)架構(gòu)管理人員，根據(jù)用戶業(yè)務(wù)需求，結(jié)合相關(guān)技術(shù)約束條件，確定將來(lái)系統(tǒng)所要提供的高層的、概括的功能特性，將來(lái)系統(tǒng)所要具有的非功能特性，系統(tǒng)的用戶界面特性，系統(tǒng)的運(yùn)行環(huán)境，系統(tǒng)設(shè)計(jì)需遵循的技術(shù)標(biāo)準(zhǔn)和原則，系統(tǒng)必須提供的接口等。通過(guò)《系統(tǒng)需求說(shuō)明書》，參與各方都能理解將來(lái)系統(tǒng)的概況，并且一致同意將來(lái)系統(tǒng)就按照《系統(tǒng)需求說(shuō)明書》的要求來(lái)開(kāi)發(fā)。非功能特性可包括：性能指標(biāo)；可靠性指標(biāo)；可維護(hù)性；可用性；靈活性；可移植性；可重用性；可測(cè)試性；易用性。確定系統(tǒng)需求階段產(chǎn)生的提交成果為《系統(tǒng)需求說(shuō)明書》。需求管理人員和系統(tǒng)架構(gòu)管理人員根據(jù)業(yè)務(wù)需求，規(guī)劃新系統(tǒng)需求管理人員和系統(tǒng)架構(gòu)管理人員根據(jù)《業(yè)務(wù)需求說(shuō)明書》的內(nèi)容，結(jié)合技術(shù)條件的約束和要求，分析需要并可能構(gòu)建一個(gè)什么樣的系統(tǒng)來(lái)解決業(yè)務(wù)部門的問(wèn)題和實(shí)現(xiàn)業(yè)務(wù)部門的目標(biāo)，將系統(tǒng)的主要的功能特性、非功能性需求以及其它一些約束條件明確定義下來(lái)，作為對(duì)系統(tǒng)的完整定義。這一定義是高層的、概括的，偏重于整體架構(gòu)和關(guān)鍵特性。需求管理人員和系統(tǒng)架構(gòu)管理人員編寫《系統(tǒng)需求說(shuō)明書》在《系統(tǒng)需求說(shuō)明書》中，可包括問(wèn)題說(shuō)明、系統(tǒng)定位、系統(tǒng)功能特性、系統(tǒng)非功能性需求等。主要業(yè)務(wù)部門和技術(shù)管理部門確認(rèn)《系統(tǒng)需求說(shuō)明書》《系統(tǒng)需求說(shuō)明書》的內(nèi)容須經(jīng)由其涉及到的主要業(yè)務(wù)部門和技術(shù)管理部門負(fù)責(zé)人的確認(rèn)后，作為一個(gè)基線版本，將不允許直接改動(dòng)，除非通過(guò)正規(guī)的變更流程。當(dāng)有較大的變更時(shí)，應(yīng)創(chuàng)建新的基線版本。《系統(tǒng)需求說(shuō)明書》和《業(yè)務(wù)需求說(shuō)明書》一起，定義了系統(tǒng)開(kāi)發(fā)商必須滿足的要求。詳細(xì)需求調(diào)研和需求分析系統(tǒng)開(kāi)發(fā)合同簽訂后，開(kāi)發(fā)商在理解了《業(yè)務(wù)需求說(shuō)明書》和《系統(tǒng)需求說(shuō)明書》的內(nèi)容以后，為了進(jìn)行系統(tǒng)設(shè)計(jì)，一般還需要進(jìn)行詳細(xì)的業(yè)務(wù)需求調(diào)研，并進(jìn)行需求分析，撰寫《系統(tǒng)需求規(guī)格說(shuō)明書》。這一階段的工作在需求管理人員的管理下進(jìn)行。用戶項(xiàng)目經(jīng)理和開(kāi)發(fā)商項(xiàng)目經(jīng)理討論《業(yè)務(wù)需求說(shuō)明書》和《系統(tǒng)需求說(shuō)明書》的內(nèi)容用戶方（包括業(yè)務(wù)部門和技術(shù)部門）與開(kāi)發(fā)方須對(duì)《業(yè)務(wù)需求說(shuō)明書》和《系統(tǒng)需求說(shuō)明書》達(dá)成一致的理解，盡早發(fā)現(xiàn)問(wèn)題并經(jīng)過(guò)探討后可進(jìn)行必要的變更。由此雙方形成對(duì)要開(kāi)發(fā)的系統(tǒng)的進(jìn)一步的共識(shí)。用戶項(xiàng)目經(jīng)理和開(kāi)發(fā)商項(xiàng)目經(jīng)理制訂詳細(xì)需求調(diào)研計(jì)劃需求管理人員、開(kāi)發(fā)商項(xiàng)目經(jīng)理共同確定：詳細(xì)需求信息（包括組織機(jī)構(gòu)信息、標(biāo)準(zhǔn)、規(guī)范、法律、法規(guī)、與其他部門和業(yè)務(wù)的接口、其它關(guān)聯(lián)的系統(tǒng)等）的獲得途徑和時(shí)間進(jìn)度，這部分信息的獲取一般采用資料收集的手段；要進(jìn)行調(diào)研的主要業(yè)務(wù)流程、指定的描述流程的業(yè)務(wù)人員和時(shí)間安排，提供這部分調(diào)研一般采用與有關(guān)業(yè)務(wù)人員面談的手段。詳細(xì)需求調(diào)研計(jì)劃納入到《項(xiàng)目工作計(jì)劃》中。開(kāi)發(fā)商詳細(xì)需求定義人員調(diào)研業(yè)務(wù)流程將要涉及到的業(yè)務(wù)流程明確下來(lái)之后，開(kāi)發(fā)商詳細(xì)需求定義人員在業(yè)務(wù)部門的協(xié)調(diào)下，按計(jì)劃調(diào)研確定每一個(gè)業(yè)務(wù)流程中的參與人員角色、每個(gè)角色所執(zhí)行的活動(dòng)、在活動(dòng)中所使用的業(yè)務(wù)實(shí)體、以及在活動(dòng)中要遵循的一些業(yè)務(wù)規(guī)則。調(diào)研結(jié)果填寫在《需求調(diào)研表》中。開(kāi)發(fā)商整理詳細(xì)需求調(diào)研結(jié)果，初步確定《系統(tǒng)需求規(guī)格說(shuō)明書》的框架內(nèi)容根據(jù)對(duì)《業(yè)務(wù)需求說(shuō)明書》和《系統(tǒng)需求說(shuō)明書》的共同理解，并整理詳細(xì)需求調(diào)研的結(jié)果，開(kāi)發(fā)商可由此提出發(fā)現(xiàn)的問(wèn)題，并提出變更《系統(tǒng)需求說(shuō)明書》的有關(guān)內(nèi)容。開(kāi)發(fā)商并初步確定《系統(tǒng)需求規(guī)格說(shuō)明書》的框架內(nèi)容，包括建立用例模型。開(kāi)發(fā)商開(kāi)發(fā)界面原型開(kāi)發(fā)商根據(jù)當(dāng)前對(duì)業(yè)務(wù)需求和系統(tǒng)需求的理解，開(kāi)發(fā)完成初步的界面原型，以反映出要開(kāi)發(fā)的系統(tǒng)的概念框架和使用模式。開(kāi)發(fā)商詳細(xì)需求定義人員用例模型和界面原型為基礎(chǔ)與業(yè)務(wù)部門用戶溝通開(kāi)發(fā)商詳細(xì)需求定義人員用例模型和界面原型為基礎(chǔ)與業(yè)務(wù)部門用戶溝通，進(jìn)一步了解業(yè)務(wù)部門的要求和期望。開(kāi)發(fā)商詳細(xì)需求定義人員細(xì)化《系統(tǒng)需求規(guī)格說(shuō)明書》的內(nèi)容詳細(xì)需求定義人員根據(jù)對(duì)業(yè)務(wù)部門的調(diào)研結(jié)果，對(duì)軟件需求和界面原型進(jìn)行完善，最終明確定義以用例表達(dá)的功能性需求和非功能性需求，細(xì)化《系統(tǒng)需求規(guī)格說(shuō)明書》的內(nèi)容。業(yè)務(wù)部門、技術(shù)管理部門評(píng)審《系統(tǒng)需求規(guī)格說(shuō)明書》召開(kāi)評(píng)審會(huì)議，《系統(tǒng)需求規(guī)格說(shuō)明書》的內(nèi)容須經(jīng)由其涉及到的業(yè)務(wù)部門以及技術(shù)管理部門的一致確認(rèn)后，作為一個(gè)基線版本將不允許直接改動(dòng)，除非通過(guò)正規(guī)的變更流程。當(dāng)有較大的變更時(shí)，應(yīng)創(chuàng)建新的基線版本?！断到y(tǒng)需求規(guī)格說(shuō)明書》的內(nèi)容完整地定義了軟件開(kāi)發(fā)商必須滿足的要求。需求變更管理需求變更的目的是保證對(duì)需求提出的變更申請(qǐng)以一種可控的、受管理的方式納入到軟件開(kāi)發(fā)活動(dòng)中。需求變更通過(guò)《系統(tǒng)變更單》來(lái)管理。需求變更申請(qǐng)人提出變更申請(qǐng)需求變更申請(qǐng)人可以是業(yè)務(wù)部門用戶、系統(tǒng)維護(hù)人員、設(shè)計(jì)人員、開(kāi)發(fā)人員或測(cè)試人員等任何發(fā)現(xiàn)系統(tǒng)的問(wèn)題或改進(jìn)的機(jī)會(huì)的人，通過(guò)填寫《系統(tǒng)變更單》，來(lái)提交變更申請(qǐng)給需求管理人員。需求管理人員和系統(tǒng)架構(gòu)管理人員分析需求變更的影響和可行性需求管理人員和系統(tǒng)架構(gòu)管理人員評(píng)估變更對(duì)系統(tǒng)性能、成本、進(jìn)度和風(fēng)險(xiǎn)的影響，判斷變更的合理性、可行性，并核定工作量影響。將有關(guān)信息填寫到《系統(tǒng)變更單》。業(yè)務(wù)部門負(fù)責(zé)人、技術(shù)管理部門負(fù)責(zé)人審核變更申請(qǐng)業(yè)務(wù)部門負(fù)責(zé)人、技術(shù)管理部門負(fù)責(zé)人根據(jù)需求變更申請(qǐng)人、需求管理人員和系統(tǒng)架構(gòu)管理人員在《系統(tǒng)變更單》中提供的信息，審核變更的必要性、合理性和可行性，決定是否執(zhí)行變更，并填寫審核意見(jiàn)到《系統(tǒng)變更單》。執(zhí)行變更變更通過(guò)審核后，需求管理人員根據(jù)跟蹤關(guān)系，組織開(kāi)發(fā)商執(zhí)行對(duì)《系統(tǒng)需求規(guī)格說(shuō)明書》以及設(shè)計(jì)文檔、測(cè)試文檔和用戶手冊(cè)等受影響的內(nèi)容的修改，并提交新版本給文檔管理人員。開(kāi)發(fā)商并執(zhí)行對(duì)軟件代碼或系統(tǒng)配置的修改，在測(cè)試管理人員的組織下對(duì)新系統(tǒng)進(jìn)行測(cè)試，并部署到生產(chǎn)環(huán)境中。需求分析原則必須表示和理解問(wèn)題的信息域在開(kāi)始建立分析模型前先理解問(wèn)題。人們通?？偞嬖诩庇谇蟪傻膬A向，甚至在問(wèn)題被很好地理解前，這經(jīng)常會(huì)導(dǎo)致產(chǎn)生一個(gè)解決錯(cuò)誤問(wèn)題的優(yōu)美軟件的誕生。必須定義軟件將完成的功能必須表示軟件的行為(作為外部事件的結(jié)果必須劃分描述信息、功能和行為的模型，從而使得可以以層次的方式揭示細(xì)節(jié)分析過(guò)程應(yīng)該從要素信息移向細(xì)節(jié)實(shí)現(xiàn)開(kāi)發(fā)原型使得用戶能夠了解將如何發(fā)生人機(jī)交互。因?yàn)槿藗円话銓?duì)軟件質(zhì)量的感覺(jué)經(jīng)?；趯?duì)界面“友好性”的感覺(jué)，因此，強(qiáng)力推薦使用原型方法(以及相應(yīng)產(chǎn)生的迭代)記錄每個(gè)需求的起源及原因這是建立回溯到客戶的可追蹤性的第一步。使用多個(gè)需求視圖建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖，這將減少忽視某些東西的可能性，并增加識(shí)別不一致性的可能性。給需求賦予優(yōu)先級(jí)過(guò)短的時(shí)限可能使每個(gè)軟件需求得于實(shí)現(xiàn)的可能性減小，如果采用增量過(guò)程模型(第2章)，必須標(biāo)識(shí)那些將在第一個(gè)增量中要交付的需求。努力刪除含糊性因?yàn)榇蠖鄶?shù)需求以自然語(yǔ)言描述，存在含糊性的可能，正式的技術(shù)復(fù)審是發(fā)現(xiàn)并刪除含糊性的一種方法。需求分析方法結(jié)構(gòu)化分析創(chuàng)建實(shí)體—關(guān)系圖實(shí)體—關(guān)系圖使得軟件工程師可以完整地刻劃系統(tǒng)輸入和輸出的數(shù)據(jù)對(duì)象、定義這些對(duì)象的性質(zhì)的屬性、以及對(duì)象間的關(guān)系。與分析模型中的其他元素一樣，ERD是以迭代的方式構(gòu)造的?？梢圆捎靡韵碌姆椒ǎ涸谛枨笏鸭倪^(guò)程中，要求客戶列出應(yīng)用軟件或業(yè)務(wù)過(guò)程涉及到的“事物”。這些“事物”演化為一組輸入和輸出的數(shù)據(jù)對(duì)象，以及生產(chǎn)和消費(fèi)信息的外部實(shí)體。一次考慮一個(gè)對(duì)象，分析員和客戶定義這個(gè)對(duì)象和其他對(duì)象間是否存在連接(在這個(gè)階段沒(méi)有命名)。當(dāng)連接存在時(shí)，分析員和客戶應(yīng)創(chuàng)建一個(gè)或多個(gè)對(duì)象—關(guān)系對(duì)。對(duì)每個(gè)對(duì)象—關(guān)系對(duì)，考察其基數(shù)和形態(tài)。迭代地進(jìn)行步驟2到步驟4，直至定義了所有的對(duì)象—關(guān)系對(duì)。在這個(gè)過(guò)程進(jìn)展中發(fā)現(xiàn)遺漏是很正常的。當(dāng)進(jìn)行若干次迭代時(shí)，將總是不斷地增加新的對(duì)象和關(guān)系。定義每個(gè)實(shí)體的屬性。形式化并復(fù)審實(shí)體—關(guān)系圖。重復(fù)步驟1到步驟7，直到數(shù)據(jù)建模完成。創(chuàng)建數(shù)據(jù)流圖(DFD)數(shù)據(jù)流圖(DFD)使得軟件工程師可以同時(shí)開(kāi)發(fā)信息域和功能域的模型。當(dāng)DFD被精化到較細(xì)的級(jí)別時(shí)，分析員對(duì)系統(tǒng)進(jìn)行了隱式的功能分解，這樣完成了第四條操作性分析原則。同時(shí)，當(dāng)數(shù)據(jù)流過(guò)體現(xiàn)應(yīng)用的加工時(shí)，DFD的精化導(dǎo)致了數(shù)據(jù)的相應(yīng)精化。第0層的數(shù)據(jù)流圖應(yīng)將軟件/系統(tǒng)描述為一個(gè)泡泡；應(yīng)仔細(xì)地標(biāo)記主要的輸入和輸出；通過(guò)隔離要表示在下一層中的候選加工、數(shù)據(jù)對(duì)象和存儲(chǔ)而開(kāi)始精化過(guò)程；所有的箭頭和泡泡應(yīng)使用有意義的名稱標(biāo)記；當(dāng)從一個(gè)級(jí)別到另一個(gè)級(jí)別時(shí)要維護(hù)“信息流連續(xù)性”；一次精化一個(gè)泡泡。經(jīng)常存在一種使數(shù)據(jù)流圖過(guò)分復(fù)雜的自然趨勢(shì)，當(dāng)分析員試圖過(guò)早地顯示過(guò)多的細(xì)節(jié)或在信息流中表示軟件的過(guò)程時(shí)，會(huì)發(fā)生這種情況。DFD的精化可以連續(xù)進(jìn)行，直至每個(gè)泡泡只執(zhí)行一個(gè)簡(jiǎn)單的操作，即直至每個(gè)泡泡所代表的加工執(zhí)行一個(gè)可以很容易地實(shí)現(xiàn)為程序組成部分的功能。創(chuàng)建控制流模型對(duì)于事件驅(qū)動(dòng)的應(yīng)用軟件，產(chǎn)生控制信息，而不是報(bào)告或顯示值；處理信息時(shí)非常關(guān)注時(shí)間和性能。這些應(yīng)用軟件在數(shù)據(jù)流建模以外還需要使用控制流建模。創(chuàng)建CFD的方法，從數(shù)據(jù)流模型中“剝?nèi)ァ彼械臄?shù)據(jù)流箭頭，然后向圖中加入事件和控制項(xiàng)(虛線箭頭)，并顯示一個(gè)到控制規(guī)約的“窗口”(豎短線)。以以下方法選擇潛在的候選事件：·列出所有被軟件“讀取”的傳感器?！ち谐鏊械闹袛鄺l件?！ち谐鏊斜徊僮髡唛_(kāi)動(dòng)的“開(kāi)關(guān)”?！ち谐鏊械臄?shù)據(jù)條件?！せ貞泴?duì)加工敘述進(jìn)行的名詞—?jiǎng)釉~掃描，回顧所有作為可能的CSPEC的輸入/輸出的“控制項(xiàng)”。·通過(guò)標(biāo)識(shí)其狀態(tài)描述系統(tǒng)的行為；標(biāo)識(shí)這些狀態(tài)是如何達(dá)到的，并定義狀態(tài)間的變遷?！りP(guān)注可能的省略——這是在刻劃控制時(shí)非常普遍的錯(cuò)誤(例如，問(wèn)“有什么其他的途徑可以達(dá)到這個(gè)狀態(tài)或從它離開(kāi)嗎？”)?？刂埔?guī)約(CSPEC)控制規(guī)約(CSPEC)在兩個(gè)不同的方面表示系統(tǒng)的行為(在它被引用的層次上)，CSPEC包括一個(gè)狀態(tài)變遷圖(STD)，它是行為的“順序規(guī)約”；CSPEC還包括加工激活表(PAT)——行為的“組合規(guī)約。通過(guò)研究STD，軟件工程師可以確定系統(tǒng)的行為，更重要的是，可以確定被描述的行為中是否存在“空洞(ho1e)”。一種不同的表示行為的模式是“加工激活表”(PAT)，PAT在加工的語(yǔ)境中，而不是在狀態(tài)的語(yǔ)境中，表示STD中包含的信息，即這張表指明當(dāng)事件發(fā)生時(shí)，流模型中的哪些加工(泡泡)被激活。PAT可以作為那些必須確立執(zhí)行者來(lái)控制在該層次上表示的加工的設(shè)計(jì)者的指南。加工規(guī)約(PSPEC)加工規(guī)約(PSPEC)用來(lái)描述出現(xiàn)在求精過(guò)程的最終層次的所有流模型加工。加工規(guī)約的內(nèi)容可以包括敘述性正文、加工算法的“程序設(shè)計(jì)語(yǔ)言”(PDL)描述①、數(shù)學(xué)方程、表、圖或圖表。為流模型中的每個(gè)泡泡提供了PSPEC，軟件工程師就創(chuàng)建了一個(gè)“小規(guī)約”，它可以作為創(chuàng)建軟件需求規(guī)約的第一步，并作為對(duì)實(shí)現(xiàn)加工的程序成分進(jìn)行設(shè)計(jì)的指南。數(shù)據(jù)字典分析模型中包含對(duì)