【正文】 可能的。一方面是因?yàn)橄到y(tǒng)固有的復(fù)雜性，另一方面是因?yàn)橛^點(diǎn)不同，需求也會(huì)發(fā)生矛盾。 非功能需求 對(duì)系統(tǒng)提供的服務(wù)或功能給出的約束。包括時(shí)間約束、開發(fā)過程約束、標(biāo)準(zhǔn)等。 非功能需求愿于用戶的限制，包括預(yù)算上的約束、機(jī)構(gòu)政策、與其他軟硬件系統(tǒng)間的相互操作，還包括如安全規(guī)章、隱私權(quán)利保護(hù)等外部因素。主要有的類型如 圖 非功能需求的類型 . 機(jī)構(gòu)需求 可用性 效率 可靠性 移植性 交付 實(shí)現(xiàn) 標(biāo)準(zhǔn) 互操作 道德 法律 。 。 。 產(chǎn)品需求 外部需求 非功能需求 緒論 4 領(lǐng)域需求 這是來自系統(tǒng)的應(yīng)用程序領(lǐng)域的需求，反映了該領(lǐng)域的特點(diǎn)。他們也可能是功能需求或非功能需求。 軟件需求文檔 有時(shí)叫做軟件需求描述（ SRS）是對(duì)系統(tǒng)開發(fā)者要求的正式陳述 。 IEEE 標(biāo)準(zhǔn)為需求文檔提出了以下結(jié)構(gòu)：引言（目的、范圍、縮略詞等），一般描述（產(chǎn)品透視、功能、用戶特征、約束等），專門需求（功能、非功能、接口），附錄，索引。 圖 需求文檔的形成 業(yè)務(wù)需求 用戶需求 質(zhì)量屬性 非功能需求 系統(tǒng)需求 功能需求 約束條件 項(xiàng)目視圖和范圍文檔 使用實(shí)例文檔 軟件需求描述文檔 方法論 5 第二章 方法論 問題域（應(yīng)用領(lǐng)域） 問題所存在的現(xiàn)實(shí)世界中的那個(gè)部分。 問題域是需求分析員所要研究的首要對(duì)象。 就一個(gè)電梯控制系統(tǒng)來說，它將包含任何現(xiàn)存的硬件（電梯、指示器、傳感器、按鈕等）、建筑物特征（樓層和電梯井的數(shù)目）、預(yù)期的使用模式、用戶特征、使用約束（如限制短途搭乘）等等。在這個(gè)問題域內(nèi) ，問題可以確定為“讓電梯在建筑物中更有效使用的控制系 統(tǒng)”。為了解決問題，‘解系統(tǒng)’顯然有必要在問題域內(nèi)產(chǎn)生某些效果， 構(gòu)成軟件需求的正是這些想要獲得的效果 ，也就是 為何 做軟件需求 的原因和目的 。 圖 問題域與 解系統(tǒng)的相互關(guān)系 上圖中也定義了三個(gè)主要 軟件 開發(fā)活動(dòng)的 階段 任務(wù)。分析，關(guān)注問題 域 和存在于其中的問題 ，目的在于真實(shí)的了解問題域 。 規(guī)格說明，關(guān)注問題域與解系統(tǒng)之間的相互關(guān)系 ，定義了系統(tǒng)預(yù)期的目標(biāo) 。設(shè)計(jì)，關(guān)注解系統(tǒng)內(nèi)部的運(yùn)作實(shí)現(xiàn) ，構(gòu)建計(jì)算機(jī)中的“現(xiàn)實(shí)世界”即軟件 （不屬于需求工程部分）。 到現(xiàn)在為止，我們得到初步論點(diǎn)。在構(gòu)建一個(gè)新 軟件 系統(tǒng)之前，最好先決定它應(yīng)當(dāng) 能夠 做些什么 又不要做些什么 ；從問題域的研究入手，獲得問題的描述，以及新的解系統(tǒng)在其中將產(chǎn)生效果的陳述（即需求）；確定新系統(tǒng)所需的行為，以便讓它在問題域內(nèi)產(chǎn)生 所需要的效果。 需求分析 通過對(duì)問題 域 的研究，獲得對(duì)該領(lǐng)域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明。 需求分析旨在揭示一個(gè)現(xiàn)有的系統(tǒng)（問題域）的方法論 6 結(jié)構(gòu)，而內(nèi)部設(shè)計(jì)則是要?jiǎng)?chuàng)建出一個(gè)尚未存在的 軟件 系統(tǒng)（解系統(tǒng)）的結(jié)構(gòu)。 對(duì)于這一重要任務(wù)其特性如下： 分析關(guān)注問題域及 對(duì) 其建 立的模型， 而不是解系統(tǒng)； 主要目標(biāo)是要獲得對(duì)問題域及存在于其中的問題本質(zhì)的理解； 分析在本質(zhì)上先于解系統(tǒng)行為的規(guī)格說明（盡管有重疊和反復(fù)的過程）。 方法論 方法不只是一種技術(shù)，它是解決任務(wù)的一種途徑，并且通常由一組技術(shù)組成。任何分 析方法， 要使它得到很好的利用 ，都應(yīng)當(dāng)要求并且 做到 便于描述以下幾個(gè)方面： 1. 問題域的結(jié)構(gòu)，根據(jù)其子域及其相互間的關(guān)系； 2. 問題域數(shù)據(jù)，語法和語義方面 3. 問題子域的內(nèi)在屬性和行為； 4. 問題域中的重要事件及現(xiàn)象； 5. 需求，解系統(tǒng)在問題域中應(yīng)產(chǎn)生的效果。 結(jié)構(gòu)化分析 （ SA） 結(jié)構(gòu)化分析 （ SA） 是一種具有相當(dāng)長歷史的分析方法，其演化的方式既微妙又顯得很重要。 如同結(jié)構(gòu)化編程一樣， 它致力于系統(tǒng)范圍內(nèi)的 事物 處理，數(shù)據(jù)流以及存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)的建模。 建模主要包括數(shù)據(jù)流模型（ DFD），數(shù)據(jù)字典（ DD），實(shí)體關(guān)系圖（ ERD）。 結(jié)構(gòu)化分 析所用的原型 ， 無論是對(duì)開發(fā)者還是客戶都顯得直觀易懂，若將初始重點(diǎn)放在對(duì)原有系統(tǒng)的建模是對(duì)實(shí)現(xiàn)理解問題域這一基本的分析目標(biāo)的有力支持。 結(jié)構(gòu)化分析方法和人們的思維方式和相似，注重的是事物的過程和方面。利用結(jié)構(gòu)化分析很容易去理解一個(gè)剛剛接觸的問題域，適合對(duì)比較生疏領(lǐng)域做軟件需求。 面向?qū)ο蠓治?（ OOA） 面向?qū)ο蠓椒ㄗ畛踔皇且环N系統(tǒng)的結(jié)構(gòu)進(jìn)行建模的方式，后來擴(kuò)展到了內(nèi)部方法論 7 設(shè)計(jì)，如今也已經(jīng)開始廣泛應(yīng)用于分析階段。面向?qū)ο蠓治龌舅枷胧牵喝绻褜?duì)象類的建模限定在需求問題域，那么面向?qū)ο蟮幕驹?、模型以及表?法均可以用于分析。 OOA（面向?qū)ο蠓治觯?算不上一種真正的需求方法， OOA 的起點(diǎn)是一份原有的需求文檔，或者甚至是一份行為規(guī)格說明，并且 OOA 隱含的假設(shè)問題域分析已經(jīng)完成 ，即分析員已經(jīng)了解了所要研究的事物 。 OOA 的真正本質(zhì)意義是作為解系統(tǒng)的高層體系結(jié)構(gòu)的設(shè)計(jì)，并且有利于系統(tǒng)的下一步開發(fā)設(shè)計(jì) （如果是 OOD 開發(fā)的話） 。 OOA 的大致方法是 ? 標(biāo)識(shí)出問題域中的對(duì)象類； ? 定義這些類的屬性和方法； ? 定義這些類的行為； ? 對(duì)這些類間的關(guān)系建模。 面向問題域分析 （ PDOA） 面向問題域分析 面向問題域的分析 （ PDOA） 是一種新技術(shù) 。 PDOA 更 多的強(qiáng)調(diào)描述，而較少的強(qiáng)調(diào)建模。描述大致劃分為兩個(gè)部分：一部分關(guān)注于問題域，而另一部分關(guān)注于解系統(tǒng)的待求行為。 一般 建議同時(shí)有兩個(gè)單獨(dú)文檔：第一文檔含有對(duì)問題域相關(guān)部分的描述以及一個(gè)需求在該域中求解的問題列表（即需求）；第二文檔（規(guī)格說明書）包含的是對(duì)解系統(tǒng)的待求行為的描述以解決需求。其中第一文檔才是通過 做 分析產(chǎn)生的；第二文檔推遲到后續(xù)的規(guī)格說明任務(wù)中。 PDOA 整個(gè)方法過程的基本步驟： ? 搜集基本的信息并開發(fā)問題框架（一種模型），以建立問題域的類型 ? 在問題框架類型的指導(dǎo)下， 進(jìn)一步搜集詳細(xì)信息并給出一個(gè)問題域相關(guān)的特性描述 ? 基于以上兩點(diǎn)，收集并用文檔說明新系統(tǒng)的需求 問題框架 問題框架是將問題域建模成一系列互相關(guān)聯(lián)的子域。一個(gè)子域可以是那些可方法論 8 能算是精選出來的問題域的任一部分。問題框架的目標(biāo)就是大量地捕獲更多有關(guān)問題域的信息?；诓煌瑔栴}子域的本質(zhì)及存在于問題子域間的關(guān)系，可以把問題框架分類： ? 工件系統(tǒng) —— 系統(tǒng)必須完成針對(duì)只存在于系統(tǒng)中的這些對(duì)象的直接操作。 ? 控制系統(tǒng) —— 系統(tǒng)控制部分問題域的行為，包括待求行為框架和受控行為框架。 ? 信息系統(tǒng) —— 系統(tǒng)將提供有關(guān)的問題域的信 息，包括，信息是自動(dòng)提供的，和，信息只在響應(yīng)具體的請(qǐng)求時(shí)提供。 ? 轉(zhuǎn)換系統(tǒng) —— 系統(tǒng)必須將某種特定格式的輸入數(shù)據(jù)轉(zhuǎn)換成相應(yīng)的、另一種特定格式的輸出。 ? 連接系統(tǒng) —— 系統(tǒng)必須維持那些相互沒有直接連接的子域間的通信。 問題框架法在應(yīng)用時(shí)，建議采用直截了當(dāng)?shù)牟呗裕? ? 抽象問題域： 1. 標(biāo)識(shí)子域 2. 標(biāo)識(shí)子域間的交互 3. 刻畫每個(gè)子域的特征 4. 生成一個(gè)上下文圖 ? 識(shí)別出相關(guān)的標(biāo)準(zhǔn)框架 ? 調(diào)整框架，盡可能使之適用 于問題 ? 使用關(guān)于相關(guān)框架的內(nèi)容技術(shù)表來指導(dǎo)進(jìn)一步的分析與文檔編制任務(wù)。 問題域的描述與必須滿足的需求二者之間有著明顯的區(qū)別，對(duì)新的解 系統(tǒng)的行為創(chuàng)建與定義應(yīng)單獨(dú)處理并且推遲到下一步的規(guī)格說明階段。 方法的對(duì)比 結(jié)構(gòu)化 分析及其相應(yīng)的派生方法，曾一度風(fēng)行了許多年頭。它最初的版本主要是圍繞對(duì)數(shù)據(jù)流以及問題域的數(shù)據(jù)結(jié)構(gòu)進(jìn)行建模，而現(xiàn)代的 SA 則直接將重點(diǎn)放在開發(fā)解系統(tǒng)的模型。描述問題域的 SA 可以算是想當(dāng)不錯(cuò)的，所產(chǎn)生的功效可見一斑。然而，它對(duì)其他方面的支持卻不夠完善，在處理一些其他類型問題時(shí)顯得有些笨拙。 方法論 9 面向?qū)ο蠓治鍪钱?dāng)今主流的方法。 OOA 要求所有的系統(tǒng)均可以按照對(duì)象的特點(diǎn)來建模。它也繼承了很多結(jié)構(gòu)化分析的思想體系。 OOA 不能對(duì)問題域有 個(gè)清楚的了解，因而它的起點(diǎn)若是有一份原需求文檔，便可大大簡化問題域的分析。 OOA并不區(qū)分問題域描述與解系統(tǒng)描述之間的差異，而是直接交付出新的解系統(tǒng)的高層設(shè)計(jì)。 SA 和 OOA 還是有幾點(diǎn)相同特性的： ? 主要模型是結(jié)構(gòu)模型（關(guān)于模型，在下章有詳細(xì)介紹）。 ? 通常焦點(diǎn)集中在對(duì)解系統(tǒng)的建模上。 ? 兩中方法都較少地應(yīng)用于需求獲取領(lǐng)域。 ? 分析與內(nèi)部設(shè)計(jì)之間沒有明顯差異。 面向問題域分析被認(rèn)為是一種較為理想的方法。 PDOA 特點(diǎn)是重新將重點(diǎn)定位在問題域及需求上，通過對(duì)問題域的分類，向分析人員提供具體問題的相關(guān)指南。 并且它將規(guī)格說明 作為另行的任務(wù)處理，它的成果只是一份問題域的全面描述和一份需求列表而已。 PDOA 豐富和完善了現(xiàn)今的“分析”方法，然而人們對(duì)它的了解和掌握還差一大段距離。 因地制宜的應(yīng)用三種方法，不僅能夠如實(shí)的認(rèn)識(shí)問題域，創(chuàng)建出健全的解系統(tǒng)，還能夠向用戶和設(shè)計(jì)人員都提供滿意的需求文檔。 建模技術(shù) 10 第三章 建模技術(shù) 系統(tǒng)建?？偟膩碚f是軟件開發(fā)過程中、尤其是需求工程中的一個(gè)極其重要的部分。相