第4章需求工程

1SoftwareRequirements第4章需求工程（1）學(xué)習(xí)引導(dǎo)

本章介紹軟件系統(tǒng)需求概念和發(fā)現(xiàn)并表達(dá)這些需求的多種方法。主要內(nèi)容：用戶需求和系統(tǒng)需求的概念以及這些需求要使用不同的方法表達(dá)的原因；功能需求和非功能需求之間的不同；需求如何組織在軟件需求文檔中。2軟件的描述是復(fù)雜的，但沒(méi)有大量的描述積累是不可能形成的，為此，我們必須從基本的描述入手，來(lái)嘗試這種復(fù)雜描述的方法，才能找到克服復(fù)雜性的一些思路。如果你打算賦予某件事情注意力，就必須描述它，而且必須直接地描述它，特別是它所在的問(wèn)題領(lǐng)域。3軟件的問(wèn)題就在于描述4程序設(shè)計(jì)軟件設(shè)計(jì)社會(huì)學(xué)與人類學(xué)模糊精確局部全局部分精確，部分不精確很不精確很精確基本概念對(duì)服務(wù)和約束的發(fā)現(xiàn)、分析、建立文檔、檢驗(yàn)的過(guò)程叫做需求工程.什么是需求工程？什么是軟件需求？開(kāi)發(fā)軟件所需要的各種條件。需求分析的任務(wù)是什么？需求分析的任務(wù)準(zhǔn)確地定義未來(lái)系統(tǒng)的目標(biāo)，確定為了滿足用戶的需求系統(tǒng)必須做什么。并用<需求規(guī)格說(shuō)明書(shū)>規(guī)范的形式準(zhǔn)確地表達(dá)用戶的需求。需求的層次和分類是什么？分兩個(gè)層次：用戶需求

系統(tǒng)需求分兩類：功能需求非功能需求重要性需求獲取困難一是用戶需求的動(dòng)態(tài)性(不穩(wěn)定性)二是需求的模糊性(不準(zhǔn)確性)三是需求必須得到用戶的確認(rèn)，否則毫無(wú)意義需求分析是發(fā)現(xiàn)、求精、建模、規(guī)格說(shuō)明和復(fù)審的過(guò)程；需求分析是系統(tǒng)設(shè)計(jì)的基礎(chǔ)，關(guān)系到工程的成敗和軟件產(chǎn)品的質(zhì)量。需求分析的重要性及困難是什么？軟件需求的層次:用戶需求是用自然語(yǔ)言加圖表的形式給出的關(guān)于系統(tǒng)需要提供哪些服務(wù)以及系統(tǒng)操作受到哪些約束的聲明。系統(tǒng)需求詳細(xì)地給出系統(tǒng)將要提供的服務(wù)以及系統(tǒng)所受到的約束。系統(tǒng)需求文檔有時(shí)也稱為功能描述，應(yīng)該是精確的。它可能成為系統(tǒng)買(mǎi)方和軟件開(kāi)發(fā)者之間合同的重要內(nèi)容。不同類型需求的讀者對(duì)象不同類型的需求描述的讀者用戶需求和系統(tǒng)需求舉例（1）1.MHC-PMS系統(tǒng)每月都要產(chǎn)生報(bào)告來(lái)顯示當(dāng)月每個(gè)診所所開(kāi)藥物的成本。用戶需求定義1.1在每個(gè)月的最后一個(gè)工作日,對(duì)新開(kāi)的藥物、藥物成本以及開(kāi)藥診所應(yīng)該產(chǎn)生一個(gè)匯總報(bào)告;I.2系統(tǒng)應(yīng)該在當(dāng)月最后一個(gè)工作日的17:3O之后自動(dòng)生成打印報(bào)告;I.3應(yīng)該為每一個(gè)診所生成一個(gè)報(bào)告,并列出各種藥的藥名、處方的總數(shù)、藥物總量,以及所開(kāi)藥物的成本；I.4如果藥物可以分為不同劑量單位(如10mg,mg),就要為每一劑量單位單獨(dú)生成報(bào)告;I.5對(duì)所有成本報(bào)告的訪問(wèn)權(quán)限應(yīng)只限于管理訪問(wèn)控制單上的授權(quán)用戶。系統(tǒng)需求描述比較用戶需求和系統(tǒng)需求舉例（2）1.軟件必須提供表達(dá)和訪問(wèn)外部文件的手段，這些外部文件是由其他工具創(chuàng)建的用戶需求定義1．1為用戶提供定義外部文件類型的工具1．2每種外部文件類型具有一個(gè)相關(guān)聯(lián)的工具1．3每種外部文件類型在界面上用一種專門(mén)的圖標(biāo)來(lái)表示1．4提供一種工具，使用圖標(biāo)表示由用戶定義的外部文件類型1．5當(dāng)用戶選擇一個(gè)代表外部文件的圖標(biāo)時(shí)，選擇的效果是將與該外部文件類型相關(guān)聯(lián)的工具啟動(dòng)起來(lái)系統(tǒng)需求描述比較練習(xí)：請(qǐng)對(duì)校園網(wǎng)學(xué)生活動(dòng)一卡通系統(tǒng)中的“IPQ統(tǒng)計(jì)分析”功能進(jìn)行描述系統(tǒng)需求和用戶需求。

一個(gè)軟件系統(tǒng)的需求描述了系統(tǒng)應(yīng)該做什么以及定義系統(tǒng)運(yùn)行時(shí)和實(shí)現(xiàn)時(shí)的約束。134.1功能需求和非功能需求怎樣開(kāi)發(fā)軟件？計(jì)算機(jī)以及運(yùn)行于其上的軟件是針對(duì)問(wèn)題的解決方案；而問(wèn)題則處于計(jì)算機(jī)以外的世界中?！?，軟件工程人員首先要懂得直接關(guān)注于問(wèn)題，而不是徑直進(jìn)入對(duì)解決方案的設(shè)計(jì)。在研究解決方案之前，我們應(yīng)該關(guān)注什么？——解決方案之前的問(wèn)題，就是軟件的需求問(wèn)題?！_(kāi)發(fā)者的失敗發(fā)生在捕獲和理解問(wèn)題上，而不是設(shè)計(jì)和實(shí)現(xiàn)解決方案上。14什么是軟件需求？一個(gè)軟件系統(tǒng)的需求，描述了系統(tǒng)應(yīng)該做什么以及定義系統(tǒng)運(yùn)行時(shí)和實(shí)現(xiàn)時(shí)的約束需求。然而，“需求”這個(gè)術(shù)語(yǔ)在軟件行業(yè)中使用得可能很不一致?！獜挠脩舻挠^點(diǎn)看，需求是系統(tǒng)應(yīng)該提供的服務(wù)或?qū)ο到y(tǒng)應(yīng)該受到的約束；——從開(kāi)發(fā)者的觀點(diǎn)看，需求被定義為系統(tǒng)的功能，是采取詳細(xì)的、甚至是用數(shù)學(xué)方法對(duì)軟件功能的形式化描述。15還有一些觀點(diǎn)，對(duì)于指導(dǎo)需求分析很有意義從過(guò)程文檔的觀點(diǎn)看，需求就是定義系統(tǒng)需要做什么而不是怎么做。這個(gè)觀點(diǎn)對(duì)于“問(wèn)題”格外關(guān)注，這是有益的。從表達(dá)方式看：一個(gè)需求是系統(tǒng)必須滿足的單一的、可測(cè)量的目標(biāo)，并使用清晰的文字來(lái)表達(dá)出每個(gè)需求。這個(gè)觀點(diǎn)強(qiáng)烈希望需求的描述與設(shè)計(jì)的思考合為一體，這對(duì)于一些關(guān)鍵系統(tǒng)的需求分析有著指導(dǎo)意義。從最終結(jié)果看，需求是系統(tǒng)必須具有的特征，或者是客戶可接受的、系統(tǒng)必須滿足的約束。16我的觀點(diǎn)需求的描述的結(jié)構(gòu)、內(nèi)容和形式，要努力靠近讓軟件體系結(jié)構(gòu)設(shè)計(jì)環(huán)節(jié)的需要；軟件體系結(jié)構(gòu)的設(shè)計(jì)，要努力滿足需求描述的那些特性和約束。17軟件描述軟件設(shè)計(jì)和實(shí)現(xiàn)過(guò)程推進(jìn)例如，在設(shè)計(jì)階段，體系結(jié)構(gòu)設(shè)計(jì)是首要的任務(wù)，主要解決以下內(nèi)容的決策：整個(gè)系統(tǒng)范圍內(nèi)，可以劃分為哪些功能？即我們需要完成哪些系統(tǒng)功能？這些功能可以在哪些子系統(tǒng)內(nèi)集成，從而提供特定的功能集或服務(wù)集？這些子系統(tǒng)又是分布在哪些商業(yè)運(yùn)作節(jié)點(diǎn)/物理地點(diǎn)？這些子系統(tǒng)提供各自的哪些接口，如何銜接？為此，設(shè)計(jì)階段要求其上一級(jí)的需求階段提供相應(yīng)的信息。18請(qǐng)看一個(gè)采用結(jié)構(gòu)化方法給出的需求分析19干部隊(duì)伍分析輔助決策支持系統(tǒng)

功能需求是有關(guān)系統(tǒng)一定要提供的服務(wù)或者是必須執(zhí)行的計(jì)算的描述。領(lǐng)域需求是起源于其應(yīng)用領(lǐng)域特性的功能需求。204.1.1功能需求關(guān)于功能需求的定義與解釋何為功能？我們先看看計(jì)算機(jī)所能做到的操作功能：生成，如：創(chuàng)建、消除、分配、釋放；連接，如：數(shù)據(jù)連接、程序連接、對(duì)象連接。；狀態(tài)，如：激活、掛起、等待、消除、終止等。執(zhí)行，如：程序執(zhí)行、解釋執(zhí)行、過(guò)程調(diào)用等中斷，如：中斷請(qǐng)求、中斷排隊(duì)、中斷分派等這些是需求要描述的功能嗎？——不是。應(yīng)該是來(lái)自系統(tǒng)模型描述的那些功能（見(jiàn)第5章系統(tǒng)模型，如上下文模型）21所以，我們就知道了功能需求應(yīng)該描述什么1.功能需求是系統(tǒng)應(yīng)該提供的服務(wù)、如何對(duì)輸入做出反應(yīng)以及系統(tǒng)在特定條件下的行為的描述。在某些情況下，功能需求可能還需明確聲明系統(tǒng)不應(yīng)該做什么。既然功能需求是用戶所要使用的那個(gè)系統(tǒng)的需求，那么，用戶為什么提出了那些功能需求呢？——為了解決用戶領(lǐng)域中的一些問(wèn)題。所以：2.領(lǐng)域需求這是來(lái)自系統(tǒng)的應(yīng)用領(lǐng)域的需求，反映了該領(lǐng)域的特點(diǎn)。它們也可能是功能需求或非功能需求。22解釋：領(lǐng)域問(wèn)題先看一個(gè)詞匯：Stakeholders，意思是“有利害關(guān)系的人”。通常，軟件系統(tǒng)的投入/廢棄，其影響將涉及到各類Stakeholder，或者說(shuō)，是這些Stakeholder的利益目標(biāo)追求的導(dǎo)致了軟件系統(tǒng)的投入。通過(guò)開(kāi)發(fā)和運(yùn)行某個(gè)軟件系統(tǒng)，來(lái)保證Stakeholder的利益目標(biāo)追求，是軟件需求的根本所在。Stakeholders的問(wèn)題，就是所謂的“領(lǐng)域問(wèn)題”。關(guān)注領(lǐng)域問(wèn)題，才能獲得真正的需求——所謂的“用戶需求分析”，其實(shí)只是一些業(yè)務(wù)人員從業(yè)務(wù)視角提出的信息收集和整理的需求。23關(guān)于功能需求的示例大學(xué)圖書(shū)館系統(tǒng)LIBSYS的幾種功能需求這個(gè)系統(tǒng)為學(xué)生和教工從其他圖書(shū)館借閱圖書(shū)和文獻(xiàn)提供服務(wù)：1.用戶能從總的數(shù)據(jù)庫(kù)中查詢或者是選擇其中的一個(gè)子集?！樵児δ?.系統(tǒng)能提供適當(dāng)?shù)臑g覽器供用戶閱讀館藏文獻(xiàn)?！獮g覽功能3.每次借閱能對(duì)應(yīng)一個(gè)獨(dú)特的識(shí)別符（ORDER_D），可拷貝到用戶賬戶的常備儲(chǔ)存區(qū)內(nèi)?！x者管理功能思考：從上述功能需求可以看到什么領(lǐng)域需求？24領(lǐng)域需求描述的一個(gè)例子例如一個(gè)圖書(shū)館系統(tǒng)的需求：1。需要一個(gè)基于Z39.50標(biāo)準(zhǔn)的、面向所有數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)用戶界面。2。因?yàn)榘鏅?quán)限制，一些文檔只能根據(jù)用戶需要輸出到本地打印機(jī)或網(wǎng)絡(luò)打印機(jī)上。關(guān)于版權(quán)法對(duì)圖書(shū)資料保護(hù)的需求，描述了一類文檔打印完立即刪除的功能功能需求

非功能需求約束所開(kāi)發(fā)的系統(tǒng)和所采用的開(kāi)發(fā)過(guò)程。它們可能是產(chǎn)品需求、機(jī)構(gòu)需求或者是外部需求。這些需求與系統(tǒng)的總體特性相關(guān)，且作用于系統(tǒng)整體。264.1.2非功能需求“非功能需求”這個(gè)概念的由來(lái)功能需求的“功能”，來(lái)自“解決問(wèn)題的設(shè)備”中的“功能”——即該設(shè)備可觀察到的行為?！胺枪δ堋敝傅氖桥c“解決問(wèn)題的設(shè)備”中的“功能”無(wú)關(guān)的需求。這是一種誤解——誤導(dǎo)了人們只關(guān)注“功能”而不關(guān)注所謂的“非功能”——認(rèn)為“非功能”與“功能”無(wú)關(guān)，至少非功能需求是被認(rèn)為是次要的。——對(duì)非功能需求的描述要求不嚴(yán)格，是模糊的和主觀的，對(duì)它們也只是給予它模糊和主觀的關(guān)注。272.非功能需求對(duì)系統(tǒng)提供的服務(wù)或功能給出的約束。包括時(shí)間約束、開(kāi)發(fā)過(guò)程的約束、標(biāo)準(zhǔn)等。非功能需求常用于整個(gè)系統(tǒng)。通常不用在單個(gè)系統(tǒng)或服務(wù)中。單個(gè)的非功能需求,比如一個(gè)信息安全性需求,可能會(huì)產(chǎn)生數(shù)個(gè)相關(guān)的功能性需求,這些功能性需求定義了新系統(tǒng)所要求的服務(wù)。非功能需求可能描述系統(tǒng)的性能、信息安全性、可用性和其他總體特性。這就意味著它們比功能需求對(duì)系統(tǒng)更關(guān)鍵。28非功能需求的分類非功能性需求示例（1）

——MHC-PMS中的非功能需求實(shí)例

產(chǎn)品需求MHC-PMS系統(tǒng)必須對(duì)所有診所在正規(guī)工作時(shí)間內(nèi)(周一至周五,08:30-17:30）都是可用的，任何一天的正規(guī)工作時(shí)間內(nèi)系統(tǒng)的關(guān)閉時(shí)間不應(yīng)超過(guò)5秒鐘。機(jī)構(gòu)需求MHC-PMS系統(tǒng)的用戶應(yīng)該使用他們的衛(wèi)生局身份證件來(lái)驗(yàn)證自己。外部需求系統(tǒng)必須依照法律Hstan-03-2006–priv貫徹病人隱私條款。非功能性需求示例（2）

——圖書(shū)館系統(tǒng)LIBSYS的幾個(gè)非功能需求產(chǎn)品方面：4.C.8它應(yīng)該能將所有APSE和用戶之間的必需的通信用標(biāo)準(zhǔn)的Ada字符集表達(dá)——這是一個(gè)約束：要求該系統(tǒng)必須能夠保持Ada語(yǔ)言程序設(shè)計(jì)支持環(huán)境（APSE）下具有符合該環(huán)境的標(biāo)準(zhǔn)字符集。機(jī)構(gòu)方面：9.32系統(tǒng)開(kāi)發(fā)過(guò)程和可交付的文檔將遵照XYZCo-SP-STAN-95中的相關(guān)定義——這也是一個(gè)約束：指定了系統(tǒng)的項(xiàng)目文檔所應(yīng)遵守的標(biāo)準(zhǔn)外部需求：7.6.5系統(tǒng)不應(yīng)該對(duì)系統(tǒng)的操作人員公開(kāi)客戶除名字和索引代碼之外的任何個(gè)人信息。——這是信息安全要求31非功能需求的檢驗(yàn)舉例系統(tǒng)應(yīng)該很好用，即使對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶，而且應(yīng)該使得用戶錯(cuò)誤降到最少系統(tǒng)目標(biāo)對(duì)一個(gè)沒(méi)有經(jīng)驗(yàn)的用戶來(lái)說(shuō)，經(jīng)過(guò)兩個(gè)小時(shí)的培訓(xùn)就應(yīng)該能使用系統(tǒng)的所有功能。在這樣的培訓(xùn)之后，一個(gè)有經(jīng)驗(yàn)的用戶每天的出錯(cuò)平均數(shù)不應(yīng)超過(guò)兩次可檢驗(yàn)的非功能需求非功能需求的檢驗(yàn)非常困難，用定量化的描述來(lái)衡量非功能需求是否達(dá)到目標(biāo)是一種不錯(cuò)的辦法。指定非功能需求的度量指定非功能需求的度量目標(biāo)依賴語(yǔ)句的百分?jǐn)?shù)目標(biāo)系統(tǒng)的數(shù)目失敗后重啟時(shí)間事件引起失敗的百分?jǐn)?shù)失敗中數(shù)據(jù)崩潰的概率平均失敗時(shí)間；不可用的概率失敗發(fā)生頻率；可用性培訓(xùn)時(shí)間幫助幀數(shù)兆字節(jié)數(shù)ROM芯片數(shù)處理的交易/秒；用戶/事件響應(yīng)時(shí)間；屏幕刷新時(shí)間度量可移植性魯棒性可靠性易用性規(guī)模速度屬性非功能需求和功能需求之間的關(guān)系非功能需求和功能需求之間會(huì)產(chǎn)生沖突，比如性能的要求和目標(biāo)之間。3D畫(huà)面，容量與功能等等。P56舉例。盡管非功能需求和功能需求在文檔困難，盡量分開(kāi)敘述，易于采用不同的指標(biāo)分析功能是否達(dá)到要求。不能分開(kāi)的視具體系統(tǒng)情況而定，可以采用折中辦法。

用戶需求是為面向購(gòu)買(mǎi)和使用系統(tǒng)的用戶而寫(xiě)的。應(yīng)該使用自然語(yǔ)言、表格或圖表的形式給出，以便用戶容易理解。36用戶需求和系統(tǒng)需求的比較

系統(tǒng)需求想要達(dá)到能以準(zhǔn)確的方式表述系統(tǒng)必須提供的功能。為減少二義性，可以采用某種結(jié)構(gòu)化自然語(yǔ)言輔之以表格和系統(tǒng)模型給出。關(guān)于用戶需求的描述

站在用戶的角度來(lái)描述系統(tǒng)功能和非功能需求只描述系統(tǒng)的外部行為，要盡量避免對(duì)系統(tǒng)設(shè)計(jì)特性的描述。使用自然語(yǔ)言、圖表和直觀的圖形描述的內(nèi)容是“中、高層次”的概念及其下的功能為。示例——LIBSYS應(yīng)該提供交易記費(fèi)系統(tǒng)以維護(hù)用戶的所有支付記錄。系統(tǒng)管理員會(huì)配置此系統(tǒng)使得長(zhǎng)期用戶會(huì)得到折扣。37關(guān)于系統(tǒng)需求的描述系統(tǒng)需求是對(duì)用戶需求的擴(kuò)展內(nèi)容，主要描述系統(tǒng)的外部行為和對(duì)它的操作上的限制，不包括系統(tǒng)應(yīng)該如何設(shè)計(jì)和如何實(shí)現(xiàn)。主要的描述內(nèi)容給出系統(tǒng)的初始的體系結(jié)構(gòu)，借助這個(gè)框架來(lái)構(gòu)造需求描述。然后按照構(gòu)成系統(tǒng)的不同子系統(tǒng)結(jié)構(gòu)來(lái)給出細(xì)節(jié)層次上更完善的定義。系統(tǒng)和其他已存在的系統(tǒng)存在互操作。38說(shuō)明系統(tǒng)需求是比用戶需求更詳細(xì)的需求描述，是系統(tǒng)實(shí)現(xiàn)的基本依據(jù)。因此，是一個(gè)完全的和一致的系統(tǒng)描述，是軟件工程人員系統(tǒng)設(shè)計(jì)的起點(diǎn)。系統(tǒng)需求描述可能包括許多不同模型，如對(duì)象模型和數(shù)據(jù)流模型。用戶需求和系統(tǒng)需求的描述，共同構(gòu)成需求文檔——在需求分析后期，軟件人員要編寫(xiě)出需求分析報(bào)告來(lái)提交給用戶看。在需求文檔中先概要地描述用戶需求；再使用模板描述系統(tǒng)需求；添加額外信息到自然語(yǔ)言的需求描述中——采用表格形式或圖形模型形式給出描述40

軟件需求文檔是經(jīng)過(guò)認(rèn)可的系統(tǒng)需求描述。它應(yīng)該被很好地組織，以便既可以供系統(tǒng)客戶使用又可以供軟件開(kāi)發(fā)者使用。414.2軟件需求文檔

要制訂專門(mén)的需求描述標(biāo)準(zhǔn)，與需求文檔相關(guān)的IEEE標(biāo)準(zhǔn)是一個(gè)合適的起點(diǎn)。軟件需求文檔（softwarerequirementspecification,SRS）是給系統(tǒng)開(kāi)發(fā)者看的、對(duì)應(yīng)當(dāng)實(shí)現(xiàn)的內(nèi)容的正式陳述?！⒁猓@可不是需求分析報(bào)告。軟件需求文檔是軟件項(xiàng)目組的第一個(gè)軟件文檔，需要有一個(gè)統(tǒng)一的，符合開(kāi)發(fā)組織特點(diǎn)的文檔模板（企業(yè)標(biāo)準(zhǔn)）教材中給出了基于IEEE標(biāo)準(zhǔn)的需求文檔模板，表4-7給出了這個(gè)需求文檔的結(jié)構(gòu)說(shuō)明42軟件需求文檔4.3需求描述系統(tǒng)需求是比用戶需求更詳細(xì)的需求描述，是系統(tǒng)實(shí)現(xiàn)的基本依據(jù)。因此，是一個(gè)完全的和一致的系統(tǒng)描述，是軟件工程人員系統(tǒng)設(shè)計(jì)的起點(diǎn)。需求描述就是在需求文檔中寫(xiě)下用戶需求和系統(tǒng)需求。系統(tǒng)需求描述可能包括許多不同模型，如對(duì)象模型和數(shù)據(jù)流模型。原則上講，系統(tǒng)需求應(yīng)該陳述系統(tǒng)應(yīng)該做什么而不包括系統(tǒng)應(yīng)該如何實(shí)現(xiàn)。然而，在細(xì)節(jié)層次上會(huì)提到設(shè)計(jì)信息.書(shū)寫(xiě)用戶需求應(yīng)該遵守的原則設(shè)計(jì)一個(gè)標(biāo)準(zhǔn)的格式，保證所有的需求定義都按照該格式書(shū)寫(xiě)。這種格式包括對(duì)初始需求描述的擴(kuò)展、用戶需求的基本原理以及詳細(xì)的系統(tǒng)需求描述的索引。使用一致的語(yǔ)言。尤其要區(qū)別強(qiáng)制性和希望性的需求。定義強(qiáng)制性需求時(shí)要使用“必須”，定義希望性需求時(shí)使用“應(yīng)該”。對(duì)文本加亮（使用黑體或斜體）來(lái)突出顯示關(guān)鍵性的需求。盡量避免用計(jì)算機(jī)專業(yè)術(shù)語(yǔ)。但不可避免地會(huì)用到應(yīng)用領(lǐng)域的專業(yè)術(shù)語(yǔ)。自然語(yǔ)言的問(wèn)題(NL)不夠清楚使用語(yǔ)言時(shí)有時(shí)候很難精確、清楚的描述需求混淆功能與非功能需求可能會(huì)產(chǎn)生混淆需求混合將好幾種不同需求一同表示Dogsmustbecarried.Shoesmustbeworn.（〔乘車(chē)時(shí)〕鞋子必須穿上）（〔乘車(chē)時(shí)〕必須穿著鞋子）（〔乘車(chē)時(shí)〕必須把鞋子穿在腳上）（〔乘車(chē)時(shí)〕狗必須抱著）（〔乘車(chē)時(shí)〕必須抱著狗）（〔乘車(chē)時(shí)〕必須把狗抱在身上）NL的表現(xiàn)到１９９９年底，它還欠款１０００元。自行車(chē)還沒(méi)有修好，修車(chē)的急壞了。北京圖書(shū)館收藏著章太炎的書(shū)。

這輛車(chē)沒(méi)有鎖。

巴勒斯坦游擊隊(duì)對(duì)以色列的進(jìn)攻是早有準(zhǔn)備的?！璑L規(guī)格的替代表示法結(jié)構(gòu)化語(yǔ)言結(jié)構(gòu)化語(yǔ)言描述判定表判定樹(shù)窗體式規(guī)格（1）結(jié)構(gòu)化語(yǔ)言描述結(jié)構(gòu)化語(yǔ)言使用的詞匯進(jìn)行了限制，并且可以使用固定的模板來(lái)定義系統(tǒng)的需求。例如：結(jié)構(gòu)化英語(yǔ)結(jié)構(gòu)化英語(yǔ)的詞匯表由英語(yǔ)命令動(dòng)詞數(shù)據(jù)詞典中定義的名字有限的自定義詞邏輯關(guān)系詞IF_THEN_ELSE、

CASE_OF、WHILE_DO、

REPEAT_UNTIL等組成。結(jié)構(gòu)化英語(yǔ)的特點(diǎn)是一種介于自然語(yǔ)言和形式化語(yǔ)言之間的語(yǔ)言語(yǔ)言的正文用基本控制結(jié)構(gòu)進(jìn)行分割，加工中的操作用自然語(yǔ)言短語(yǔ)來(lái)表示其基本控制結(jié)構(gòu)有三種：簡(jiǎn)單陳述句結(jié)構(gòu)：避免復(fù)合語(yǔ)句；重復(fù)結(jié)構(gòu)：while_do

或

repeat_until結(jié)構(gòu)。判定結(jié)構(gòu)：if_then_else

或

case_of結(jié)構(gòu)；商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”if發(fā)貨單金額超過(guò)$500thenif欠款超過(guò)了60天then

在償還欠款前不予批準(zhǔn)

else（欠款未超期）發(fā)批準(zhǔn)書(shū)，發(fā)貨單

else（發(fā)貨單金額未超過(guò)$500）

if欠款超過(guò)60天then

發(fā)批準(zhǔn)書(shū)，發(fā)貨單及賒欠報(bào)告

else（欠款未超期）發(fā)批準(zhǔn)書(shū)，發(fā)貨單

（2）判定表如果數(shù)據(jù)流圖的加工需要依賴于多個(gè)邏輯條件的取值，使用判定表來(lái)描述比較合適以“檢查發(fā)貨單”為例（3）判定樹(shù)判定樹(shù)也是用來(lái)表達(dá)加工邏輯的一種工具。有時(shí)侯它比判定表更直觀。檢查發(fā)貨單金額>$500金額$500欠款>60天不發(fā)出批準(zhǔn)書(shū)欠款60天發(fā)貨單發(fā)出批準(zhǔn)書(shū)、欠款>60天發(fā)出批準(zhǔn)書(shū)、發(fā)貨單及賒欠報(bào)告欠款60天發(fā)出批準(zhǔn)書(shū)、發(fā)貨單窗體式規(guī)格定義功能或?qū)嶓w描述輸入數(shù)據(jù)以及它們的來(lái)源描述輸出數(shù)據(jù)以及它們的去處指示其它所需的實(shí)體前條件與后條件副作用窗體式規(guī)格需求描述舉例（4）PDL(ProgramDescriptionLanguage)語(yǔ)言描述PDL語(yǔ)言即為程序描述語(yǔ)言，描述內(nèi)容接近極易于翻譯為程序代碼。表達(dá)系統(tǒng)功能的能力不夠充分；使用的符號(hào)專業(yè)；需求被看成了一個(gè)設(shè)計(jì)的過(guò)程，而不是幫助；用戶了解系統(tǒng)的一個(gè)模型。所描述的操作功能單一，且動(dòng)作執(zhí)行順序非常關(guān)鍵，而不易