軟件工程第4章

需求獲取SOFTWARE

ENGINEERING工程4.1

Capturing

the

requirements需求獲取Requirement: a

feature

of

the

system

or

adescription

of

something

the

system

iscapable

of ng

in

order

to

fulfill

thesystem’s

purpose需求是系統(tǒng)的特征，或?yàn)榱藢?shí)現(xiàn)系統(tǒng)目標(biāo)系統(tǒng)能做什么的一個(gè)描述。需求過程是用來導(dǎo)出、確認(rèn)和

系統(tǒng)需求文檔的一組結(jié)構(gòu)化活動(dòng)

需求分析的目標(biāo)是準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的

分析，將用戶的非形式的要求轉(zhuǎn)化為完整的需求定義，再將需求定義轉(zhuǎn)換為相應(yīng)的形式的規(guī)格說明。需求分析工作是生存期中重要的一步，也是決定性的一步。只有通過需求功能和性能的總體概念描述分析才能把為具體的開發(fā)的基礎(chǔ)。需求規(guī)格說明，從而奠定需求分析工作也是一個(gè)不斷認(rèn)識(shí)和逐步細(xì)化的過程。該過程將劃階段所確定的

范圍逐步細(xì)化到可詳細(xì)定義的程度，并分析出各種不同的

元素，然后為這些元素找到可行的解決方法。Why

are

requirements

important

?需求為什么重要？The

causesof

failed

projects

1994Standish

）1. plete

requirements

(13.1%)Lack

of

user

involvement

(12.4%)Lack

of

resources

(10.6%)Unrealistic

expectations

(9.9%)Lack

of

executive

support

(9.3%)不完整的需求缺少用戶的參與缺少資源不切實(shí)際的期望缺乏行政支持6.

Changing

requirements

and

specifications

(8.7%)改動(dòng)需求和規(guī)格說明Lack

of

planning

(8.1%)System

no

longer

needed

(7.5%)缺少計(jì)劃不再需要該系統(tǒng)需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)事實(shí)1在

生命周期中，一個(gè)錯(cuò)誤發(fā)現(xiàn)得越晚，修復(fù)錯(cuò)誤的費(fèi)用越高階段相對(duì)修復(fù)費(fèi)用需求階段0.1～0.2設(shè)計(jì)階段0.5編碼階段1單元測(cè)試階段2驗(yàn)收測(cè)試階段5階段20表4.1

生命周期中修復(fù)

的相對(duì)費(fèi)用需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)事實(shí)2許多錯(cuò)誤是潛伏的，并且在錯(cuò)誤產(chǎn)生后很長(zhǎng)一段時(shí)間才被檢查出來Boehm從TRW公司所做的

項(xiàng)目中得出結(jié)論：所有被檢測(cè)出來的錯(cuò)誤中的54％實(shí)際上是在編碼和單元測(cè)試階段以后才被發(fā)現(xiàn)的；更糟糕的是，此類錯(cuò)誤中的絕大部分（占45％）是屬于需求和設(shè)計(jì)階段的，而編碼階段的錯(cuò)誤只占9％。需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)事實(shí)3在需求過程中會(huì)產(chǎn)生很多錯(cuò)誤DeMarco在一份

中，被檢查出來的錯(cuò)誤的56％產(chǎn)生的根源可以追溯到需求階段。AIRMICS所進(jìn)行的一項(xiàng) 發(fā)現(xiàn)，在一份軍方大型管理信息系統(tǒng)的需求規(guī)格說明書中存在著500多個(gè)錯(cuò)誤，當(dāng)然這僅僅是一個(gè)

項(xiàng)目中的一次需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)事實(shí)4在需求階段，代表性的錯(cuò)誤為不明確、疏忽、不一致和二義性研究

對(duì) A7E飛機(jī)上的飛行操作程序進(jìn)行實(shí)地測(cè)試，得出的研究數(shù)據(jù)表明：

A7E項(xiàng)目中77％的需求錯(cuò)誤特點(diǎn)是不明確、疏忽、不一致和二義性。49％不正確的事實(shí)31％疏忽13％不一致5％

二義性2％

放錯(cuò)位置需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)事實(shí)5需求錯(cuò)誤是可以被檢查出來的發(fā)現(xiàn)錯(cuò)誤的方法 發(fā)現(xiàn)錯(cuò)誤的比例（％）651056檢查單元測(cè)試集成測(cè)試演進(jìn)其他Basili和Weiss的數(shù)據(jù)表明：在A-7E的 定義文檔中，33％的需求錯(cuò)誤是通過人工檢查出來的。Celko覺得利用自動(dòng)分析工具能夠從SRS中檢查出來相當(dāng)數(shù)量的錯(cuò)誤。需求為何重要—有關(guān)錯(cuò)誤的一些事實(shí)由上面這些事實(shí)，能得出如下四點(diǎn)結(jié)論：在需求過程中會(huì)產(chǎn)生很多錯(cuò)誤（事實(shí)3和4）許多錯(cuò)誤并沒有在早期被發(fā)現(xiàn)（事實(shí)2）這樣的錯(cuò)誤是能夠在產(chǎn)生的初期被檢查出來的（事實(shí)5）費(fèi)用會(huì)–如果沒有及時(shí)檢查出來這些錯(cuò)誤，直線上升（事實(shí)1）需求過程不僅是可能的而且也是值得的需求分析的任務(wù)“建造一個(gè)系統(tǒng)的最的部分是決定要建造什么……沒有別的工作在做錯(cuò)時(shí)會(huì)如此影響最終系統(tǒng)，沒有別的工作比以后矯正更?！盕red

BrooksThe

process

of

determining

the

requirementsforasoftwarebasedsystem基于

系統(tǒng)的需求定義過程需求分析階段研究的對(duì)象是

項(xiàng)目的用戶要求。

開發(fā)項(xiàng)目是要實(shí)現(xiàn)目標(biāo)系統(tǒng)的物理模型。作為目標(biāo)系統(tǒng)的參考，需求分析的任務(wù)就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的"做什么"的問題。實(shí)現(xiàn)步驟如圖：1、獲得當(dāng)前系統(tǒng)的物理模型所謂當(dāng)前系統(tǒng)可能是需要改進(jìn)的某個(gè)已在計(jì)算機(jī)上運(yùn)行的數(shù)據(jù)處理系統(tǒng)，也可能是一個(gè)人工的數(shù)據(jù)處理過程。在這一步首先分析現(xiàn)實(shí)世界，理解當(dāng)前系統(tǒng)是如何運(yùn)行的，了解當(dāng)前系統(tǒng)的組織機(jī)構(gòu)、輸入輸出、資源利用情況和日常數(shù)據(jù)處理過程，并用一個(gè)具體模型來反映自己對(duì)當(dāng)前系統(tǒng)的理解。這一模型應(yīng)客觀地反映現(xiàn)實(shí)世界的實(shí)際情況。2

抽象出當(dāng)前系統(tǒng)的邏輯模型在理解當(dāng)前系統(tǒng)"怎樣做"的基礎(chǔ)上，抽取其"做什么"的本質(zhì)，從而從當(dāng)前系統(tǒng)的物理模型抽象出當(dāng)前系統(tǒng)的邏輯模型。在物理模型中有許多物理的因素，隨著分析工作的深入，有些非本質(zhì)的物理因素就成為不必要的負(fù)擔(dān)，因而需要對(duì)物理模型進(jìn)行分析，區(qū)分出本質(zhì)的和非本質(zhì)的因素，去掉那些非本質(zhì)的因素即可獲得反映系統(tǒng)本質(zhì)的邏輯模3

建立目標(biāo)系統(tǒng)的邏輯模型分析目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)到底要"做什么"，從而從當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。具體做法：①

目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)在邏輯上的差別；②將變化的部分看做是新的處理步驟，對(duì)數(shù)據(jù)流圖進(jìn)行調(diào)整；③由外向里對(duì)變更部分進(jìn)行分析，憑經(jīng)驗(yàn)推斷其結(jié)構(gòu)，獲得目標(biāo)系統(tǒng)的邏輯模型。4、補(bǔ)充目標(biāo)系統(tǒng)的邏輯模型補(bǔ)充內(nèi)容包括：①說明目標(biāo)系統(tǒng)的用戶界面。根據(jù)目標(biāo)系統(tǒng)所處的應(yīng)用環(huán)境及它與外界環(huán)境的相互關(guān)系，有可能與它發(fā)生聯(lián)系和作用的部分，從而決定人機(jī)界面。②說明至今尚未詳細(xì)考慮的細(xì)節(jié)。這些細(xì)節(jié)包括系統(tǒng)的啟動(dòng)和結(jié)束、出錯(cuò)處理、系統(tǒng)的輸入輸出和系統(tǒng)性能方面的需求。③其它。例如系統(tǒng)的其它必須滿足的性能和限制等等。需求分析的過程需求分析階段的工作，可以分成以下四個(gè)方面：?jiǎn)栴}識(shí)別（提取）分析與綜合編制需求分析階段的文檔需求分析評(píng)審1

問題識(shí)別解決要求被開發(fā)

做什么，做到什么程度的問題。另外，需要建立分析所需要的通信途徑，以保證能順利地對(duì)問題進(jìn)行分析。需求分析的通信途徑功能，2

分析與綜合進(jìn)行各種要求的一致性分析檢查；從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細(xì)化所有的功能；對(duì)數(shù)據(jù)域進(jìn)行分解，并分配到各個(gè)子功能上，以確定系統(tǒng)的構(gòu)成和各個(gè)主要成分；找出系統(tǒng)各成分之間的聯(lián)系、接口特性和設(shè)計(jì)上的限制。判斷是否存在因片面性或短期行為而導(dǎo)致的不合理的用戶要求，是否有用戶尚未 真正有價(jià)值的潛在要求。剔除其不合理的部分，增加其需要部分。綜

系統(tǒng)的解決方案，給出目標(biāo)系統(tǒng)的詳細(xì)邏輯模型。3

編制需求分析階段的文檔需求說明書：把分析 和用戶雙方共同的理解和分析結(jié)果用規(guī)范的方式描述出來，作為今后各項(xiàng)工作的基礎(chǔ)；初步的用戶手冊(cè)：著重反映目標(biāo) 的用戶功能界面和用戶使用的具體要求。用戶手冊(cè)能強(qiáng)制分析 從用戶使用的觀點(diǎn)來思考問題；編寫確認(rèn)測(cè)試計(jì)劃，作為今后確認(rèn)測(cè)試的依據(jù)；修改和完善 開發(fā)計(jì)劃：在需求分析階段對(duì)目標(biāo)系統(tǒng)有了更進(jìn)一步的了解，因此能夠更準(zhǔn)確地估算開發(fā)成本、進(jìn)度和資源需求，需要對(duì) 開發(fā)計(jì)劃做適當(dāng)?shù)男薷摹?

需求分析評(píng)審對(duì)功能的正確性、文檔的一致性、完備性、準(zhǔn)確性和清晰性，以及其它需求給予評(píng)價(jià)。必須理解并描述問題的信息域，根據(jù)這條準(zhǔn)則應(yīng)該建立數(shù)據(jù)模型；必須定義應(yīng)完成的功能，這條準(zhǔn)則要求建立功能模型；必須描述作為外部事件結(jié)果的行為，這條準(zhǔn)則要求建立行為模型；必須對(duì)描述信息、功能和行為的模型進(jìn)行分解，用層次的方式展示細(xì)節(jié).需求分析的任務(wù)需求分析的原則.需要能夠表達(dá)和理解問題的信息域和功能域.以層次化的方式對(duì)問題進(jìn)行分解和不斷細(xì)化.要給出系統(tǒng)的邏輯視圖和物理視圖需求分析形成需求文檔需求確認(rèn)需求定義（不斷演進(jìn)）需求規(guī)約（不斷演進(jìn)）設(shè)計(jì)階段需求過程的總結(jié)需求提取需求提取、分析和協(xié)商的螺旋4.2

需求獲取技術(shù)需求獲取技術(shù)包括兩方面的工作：·建立獲取用戶要求的方法的框架；·支持和

需求獲取的過程的機(jī)制。Requiremen

icitation

需求提?。ㄒ觯┬枨筇崛∈峭ㄟ^與客戶、系統(tǒng)用戶和其他與系統(tǒng)開發(fā)相關(guān)的

交流來發(fā)現(xiàn)需求的過程。必須從項(xiàng)目干系人的角度考慮問題，花時(shí)間找到他們的真正需求為提出系統(tǒng)需求，必須理解待解決問題、組織的

業(yè)務(wù)過程、系統(tǒng)可能使用方式、系統(tǒng)的應(yīng)用領(lǐng)域，以及文檔中與系統(tǒng)相關(guān)的內(nèi)容，

相關(guān)人員

他們需要的系統(tǒng)服務(wù)和系統(tǒng)約束主要來源是新系統(tǒng)的各種系統(tǒng)相關(guān)者，即項(xiàng)目干系人。主要考慮下面這些：1.系統(tǒng)的用戶，從兩個(gè)方向來收

料：流水平方向：在各分工協(xié)作部門中尋找物流、人力流信息流、單據(jù)流、報(bào)表流、數(shù)據(jù)流等流程。垂直方向：針對(duì)不同層次用戶提取業(yè)務(wù)操作用戶：錄入、修改、提交、處理、打印、界面、傳輸、通信、時(shí)間、速度等方面的需求管理用戶：業(yè)務(wù)管理、作業(yè)控制需求主管（決策）用戶：宏觀上的統(tǒng)計(jì)、查詢、決策需求系統(tǒng)需求的資料來源，項(xiàng)目預(yù)2.客戶：項(xiàng)目小組要向客戶匯算技術(shù)

：技術(shù)、

方面的需求從各類系統(tǒng)相關(guān)者中識(shí)別出關(guān)鍵的人做領(lǐng)域其他來源：領(lǐng)域模型當(dāng)前的組織、系統(tǒng)、狀態(tài)模型現(xiàn)有文檔需求模板庫(kù)、可重用需求庫(kù)等系統(tǒng)需求的資料來源向用戶

需求

表召開需求調(diào)研會(huì)深入重點(diǎn)崗位了解實(shí)際業(yè)務(wù)工作邊收集分析、邊整理、邊征求修改意見定期向各用戶層次分別匯報(bào)、演示需求提取的實(shí)際入手方法確定系統(tǒng)的邊界從多個(gè)角度

待解決的問題對(duì)確定需求優(yōu)先級(jí)很有幫助：多個(gè)角度下都被建議的需求應(yīng)該具有高優(yōu)先級(jí)需求提取中注意的事項(xiàng)Three

kinds

of

requirements

三類需求：those

thatabsolu y

must

be

met絕對(duì)需要滿足的需求those

that

are

highly

desirable

but

notnecessary想要但并非必須的需求those

that

are

possible

but

could

be

eliminated可以接受但也可以排除的需求“我知道你相信你已經(jīng)理解了你認(rèn)為我所說的內(nèi)容，但是我并不能肯定你已經(jīng)認(rèn)識(shí)到你所聽到的并不是我所想要的?！毙枨筇崛≈凶⒁獾氖马?xiàng)需求獲取的主要4.3

Types

and

Characteristics

of

requirements需求類型和特征sThe

requirements

definition

and

specificationdescribe

everything

about

how

the

system

is

to

interactwith

i

vironment.

Included

are

the

following

kindsOfitems.需求定義和詳細(xì)說明文檔描述了系統(tǒng)如何與環(huán)境交互的所有事情。包括：Physical

environmentInterfacesUsers

and

human

factorsFunctionalityationDataResourcesSecurityQuality

assurancePhysical

environment物理環(huán)境Where

is

the

equipment

to

function?設(shè)備在哪運(yùn)行？Is

there

one

location

or

several?在一個(gè)地方還是多個(gè)地方？Are

there

any

environment

restrictions,

such

astemperature,

humidity,

or

magnetic

interference?是否有環(huán)境的限制，如溫度、濕度或電磁干擾等？Interfaces

接口Is

the

input

coming

from

one

or

more

other

systems?有來自其它系統(tǒng)的輸入嗎？Is

the

output

going

to

one

or

more

other

systems?有到其它系統(tǒng)的輸出嗎？Is

there

a

prescribed

wayin

which

the

data

must

beformatted?Is

there

a

prescribed

medium

that

the

datamust

use?對(duì)數(shù)據(jù)

介質(zhì)有規(guī)定嗎？Users

and

human

factors用戶與人的因素Who

will

use

the

system?誰使用系統(tǒng)？Will

there

be

several

types

of

users?會(huì)有多種用戶嗎？What

is

the

skill

level

of

each

type

of

user?各種用戶熟練程度？What

kind

of

training

will

be

required

for

end

type

of

user?各類用戶需受什么類型的培訓(xùn)？How

easy

will

it

be

for

a

user

to

understand

and

use

thesystem?用戶理解、使用系統(tǒng)的難度？How

difficult

will

it

be

for

auser

to

misuse

the

system?用戶錯(cuò)誤操作系統(tǒng)的可能性？Functionality功能性t?What

will

the

system

do?系統(tǒng)做什么？What

will

the

system系統(tǒng)什么時(shí)候做？Are

there

several

modes

of

operation?操作是否有多種模式？

Howandwhencanthesystembechangedorenhanced？何時(shí)及如何改變或擴(kuò)充系統(tǒng)？Are

there

constraints

on

execution

speed,

responsetime,

or

throughput?執(zhí)行速度、響應(yīng)時(shí)間或吞吐量是否有限制？ation文檔ation

is

required?How

much需要多少文檔？Should

it

beon-line,

in

book

format,

orboth?印刷形式，還是兩種都要？ationTo

what

audience

is

each

type

ofaddressed?文檔針對(duì)哪些讀者？Data數(shù)據(jù)Forbothinputandoutput,whatshouldtheformatofthedatabe?輸入、輸出數(shù)據(jù)的格式？Howoftenwilltheybereceivedorsent?接收、發(fā)送數(shù)據(jù)的頻率？Howaccuratemusttheybe?數(shù)據(jù)的準(zhǔn)確性要求多高？Towhatdegreeofprecisionmustthecalculationsbemade?計(jì)算精度要求多高？Howmuchdataflowthroughthesystem?系統(tǒng)中有多少數(shù)據(jù)流？Mustanydataberetainedforanyperiodoftime?數(shù)據(jù)在任何時(shí)段都要保存嗎？Resources資源What

materials

nelor

other

resources

are

requiredto

build,

use and

maintain

the

system?構(gòu)造、

和使用系統(tǒng)時(shí)，需要哪些材料

或其它資源。What

skills

must

the

developers

have?開發(fā)

應(yīng)該具有怎樣的技能。How

much

physical

space

will

be

taken

up

by

the

system?系統(tǒng)占據(jù)多少物理空間？heating orairWhat

are

the

requirements

for

powerconditioning?動(dòng)力、供暖或空調(diào)的需求？Is

there

a

prescribed

timetable

for

development?有規(guī)定的開發(fā)時(shí)間表嗎？Is

there

a

limit

on

the

amount

of

money

to

be

spent

ondevelopment

or

on

hardware

and

software?開發(fā)或

硬件上有無

的限制？Security安全性Must

access

to

the

system

or

to

information

be

controlled?需要控制對(duì)系統(tǒng)或信息的

嗎？How

will

one

user’s

data

be

isolated

from

others?如何

用戶之間的數(shù)據(jù)？How

will

user

programs

be

isolated

from

other

programs

andfrom

the

operating

system?用戶程序如何與其它程序和操作系統(tǒng)

？How

often

will

the

system

be

backed

up?系統(tǒng)多久備份一次？Must

the

backup

copies

be

stared

at

a

different

location?備份拷貝要保存到其他地方嗎？Should

precautions

be

taken

against

fire water

damage,

ortheft?要采取預(yù)防措施防止水災(zāi)、火災(zāi)或者

嗎？Quality

assurance質(zhì)量保證What

are

the

requirements

for

reliability,

availability,

maintainability,

security,and

the

other

quality

attributes

introduced

in

chapter

1?第一章中介紹的系統(tǒng)的可靠性、可用性、可

性、安全性和其他屬是什么？How

must

the

characteristics

of

the

system

be

demonstrated

to

others?要向其他人展示系統(tǒng)的特征嗎？Must

the

system

detect

and

isolate

faults?系統(tǒng)必須監(jiān)測(cè)和

錯(cuò)誤嗎？What

is

the

prescribed

me between

failures?規(guī)定的平均故障間隔時(shí)間是多少？Is

there

a um

time

allowed

for

restarting

the

system

after

a

failure?產(chǎn)生故障后重啟系統(tǒng)允許的最大時(shí)間是多少？How

can

the

system

incorporate

changes

to

the

design?系統(tǒng)是怎樣將變動(dòng)和設(shè)計(jì)相結(jié)合的？Will

maintenance

merely

correct

errors

or

will

it

also

include

improving

the

system?是只修改錯(cuò)誤還是也包括對(duì)改進(jìn)系統(tǒng)？What

efficiency

measures

will

apply

to

resource

usage

and

response

time?使用什么效率測(cè)量方法測(cè)量資源使用和響應(yīng)時(shí)間How

easy

should

it

be

to

move

the

system

from

one

location

to

another

or

from

onetype

of

computer

to

another?將系統(tǒng)從一個(gè)地方移到另一個(gè)地方或者從一種計(jì)算機(jī)移到另一種計(jì)算機(jī)上容易嗎？Characteristics

of

requirements需求的特征Are

they

correct?Are

they

consistent?Are

they

complete?Are

they

realistic?需求是正確的嗎？需求是一致的嗎？需求是完整的嗎？需求是現(xiàn)實(shí)的嗎？Does

each

describe

something

the

customerneeds?是否每個(gè)需求都描述了顧客要求的某件事？Are

they

verifiable?Are

they

traceable?需求是可驗(yàn)證的嗎？需求是可追蹤的嗎？關(guān)于需求的完整性Requirement

is

Completed:

if

all

possible

states,

statechanges,

inputs,

products,

and

constraints

are

described

bysome

requirement.需求是完整的：如果某些需求描述了所有可能的狀態(tài)，以及狀態(tài)的變化、輸入、過程和約束。A

system

description

is

externally

complete:

if

thedescription

constrains

all

the

proper

ties

to

the

environmentdesired

by

the

customer.系統(tǒng)描述是外部完整的：如果描述包含的所有關(guān)系都與顧客想要的環(huán)境相關(guān)時(shí)。A

system

description

is

internally

complete:

if

there

are

noundefined

references

among

the

requirements.系統(tǒng)描述是

完整的：需求之間沒有未定義的

。4.4

需求分析方法需求分析方法由對(duì)的信息域和功能域的系統(tǒng)分析過程及其表示方法組成。目前存在許多需求分析方法，每一種分析方法都引入了的不同的記號(hào)和分析策略。它們具有以下的共性:支持信息域分析的機(jī)制功能表示的方法接口的定義問題分解的機(jī)制以及對(duì)抽象的支持必須理解并描述問題的信息域，根據(jù)這條準(zhǔn)則應(yīng)該建立數(shù)據(jù)模型；必須定義應(yīng)完成的功能，這條準(zhǔn)則要求建立功能模型；必須描述作為外部事件結(jié)果的行為，這條準(zhǔn)則要求建立行為模型；必須對(duì)描述信息、功能和行為的模型進(jìn)行分解，用層次的方式展示細(xì)節(jié).需求分析的任務(wù)Natural

language

may

not

bethe

precise

andunambiguous

medium

needed

for

expressing

thesystem’s

functionality

and

the

relationship

of

itsrelevant

parts.

Requirements

are

not

always

easilyseparated

according

to

the

system

elements

withwhich

they

deal.

Theuse

of

natural

languagecanadd

to

confusion

here.How

to

express

requirementsWe

have

investigated

many

ways

to

definerequirements

in

a

more

rigorous

andcontrolled

fashion.應(yīng)用更嚴(yán)格、更受約束的方式來定義需求。需求的描述分為靜態(tài)描述和動(dòng)態(tài)描述A

system

description

lists

the

system

entitiesor

objects,

their

attributes,

and

their

relationswith

each

other.

but

it

does

not

describe

howrelationships

change

with

time.

this

view

isstatic.Static

descriptions

of

requirements需求的靜態(tài)描述方法Indirect

reference

and

RecurrencerelationsExample: k

equations

in

n

variables(n元k個(gè)方程)F(0)=1;

F(1)=1;

F(n+1)=F(n)+F(n-1)Axiomatic

definition<condition><bool-term>::=::=<bool-term>

|

<bool-term>

or<condition><bool-factor>

|

<bool-factor>

and

<bool-term><bool-factor>::=<expr>

<relop>

<expr>

|(<condition>)<relop>::=<

|

<

|

=

|

>

|

>

|

<

><expr>::=<term>

|

<expr>

<addop>

<term>

|

<addop>

<expr><term>::=<factor>

|

<term>

<mpyop>

<factor><factor>::=<scaled-expr>

|

<primary><scaled-expr><primary><number><regname><integer><regchar><addop><digit>::=::=(<expr>)<scale>

|

<number>

<scale>::=

(<expr>)

<regname>

|

<number>

|

<func>

(<expr>)::=

<integer>

|

<integer>.

|

.<integer>

|

<integer>.<integer>::=

$

<regchar>

|

<regname>

<regchar>::=

<digit>

|

<digit>

<integer>::=

<digit>

|

<letter>

|

<underscore>::=

+

|

-0

|

1

|

2

|

3

|

4

|

5

|

6

|

7

|

8

|

9<func>::=abs

|

trunc<letter>::=A

|

a

|

B

|

b|

C

|

c

|

D

|

d

|

E

|

e

|.

.

.

|

Y<myop>|

y

|

Z

|::=z*

|

/

|

mod<scale>::=c

|

d

|

h|

i

|

l

|

P

|

p

|

q

|

t

|

v<underscore>::=_

(ASCII

character95)Expression

as

a

languageData ion

數(shù)據(jù)抽象Semester

recordSemester

typeSemester

dateGrade-pointaverageCompleted

hoursSemester

type(Fall,

Spring,

Summer)Address

informationephone

numberStreet

address

CityStatePostal

codeStudent

recordNameStudent

numberAddress

informationNumberof

semesters{Semester

record}Dynamic

descriptions

動(dòng)態(tài)描述Decision

tables判定表High

standardizHigh

gradesOutside

activitieGood

recommeSend

rejection

lend

admission表的左端為條件和動(dòng)作，表中的數(shù)據(jù)表示處于的狀態(tài)和要遵守的規(guī)則?！癟”表示條件為真，“F”表示條件 -”表示無所謂，“X”表示采取的動(dòng)作。如果一個(gè)需求(數(shù)據(jù)流圖的加工)需要依賴于多個(gè)邏輯條件的取值，使用判定表來描述比較合適。判定表商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”判定樹也是用來表達(dá)加工邏輯的一種工具。有時(shí)侯它比判定表更直觀。檢查發(fā)貨單金額>$500金額$500欠款>60天欠款60天發(fā)貨單不發(fā)出批準(zhǔn)書發(fā)出批準(zhǔn)書、欠款>60天發(fā)出批準(zhǔn)書、發(fā)貨單及賒欠報(bào)告欠款60天發(fā)出批準(zhǔn)書、發(fā)貨單判定樹Functional

descriptions

and

transition

d

agrams功能性描述與變遷圖f(Si,

Cj)

SkTable

4.2.

Transition

table.Current

stateInputNext

stateS10S2S11S1S20S2S21S1S30S1S31S3變遷表狀態(tài)遷移圖(簡(jiǎn)稱為狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件，來表示系統(tǒng)的行為狀態(tài)：狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，規(guī)定了系統(tǒng)對(duì)事件的響應(yīng)方式事件：在某個(gè)特定時(shí)刻發(fā)生的事情，它是對(duì)引起系統(tǒng)做動(dòng)作或(和)從一個(gè)狀態(tài)轉(zhuǎn)換到另一個(gè)狀態(tài)的外界事件的抽象狀態(tài)遷移圖狀態(tài)轉(zhuǎn)換圖狀態(tài)遷移圖和與其等價(jià)的狀態(tài)轉(zhuǎn)換表示例柵欄圖Jackson

的有限狀態(tài)機(jī)4 Event

tables事件表Table

4.3.

Event

table.ModeEvent

1Event

2Event

3Event

4GraphicsAction

1Action

80XArchitectureXAction

2

followed

by

Action

3Actions

5

and

6

in

parallel0Native0Action

4Actions

1,

2

and

3Action

7Petri網(wǎng)，簡(jiǎn)稱PNG

(Petri

Net

Graph)

最早是作為表達(dá)異步系統(tǒng)的控制規(guī)則的圖形表示法提出來的，現(xiàn)在已廣泛地應(yīng)用于硬件與系統(tǒng)的開發(fā)中，它適用于描述與分析相互獨(dú)立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。5 Petri

NetPetri網(wǎng)是一種有向圖，它有兩種結(jié)點(diǎn)：位置（

place）：符號(hào)為“○”，它用來表示系統(tǒng)的狀態(tài)。轉(zhuǎn)移（

transition

）：符號(hào)為“

”

或“︱”，它用來表示系統(tǒng)中的事件。圖中的有向邊表示對(duì)轉(zhuǎn)移的輸入，或由轉(zhuǎn)移的輸出：“→”表示事件發(fā)生的前提，即對(duì)轉(zhuǎn)移（事件）的輸入，“︱→”表示事件的結(jié)果，即由轉(zhuǎn)移（事件）的輸出。Petri

Net稱轉(zhuǎn)移的啟動(dòng)為激發(fā)或開火（fire），它是轉(zhuǎn)移的輸出；只有當(dāng)作為輸入的所有位置的條件都滿足時(shí)才標(biāo)記

或稱令牌(token)，是表明系統(tǒng)當(dāng)前處于什么狀態(tài)的標(biāo)志5

Petri網(wǎng)處理兩個(gè)進(jìn)程的同步問題Additional

notations

其他方法Hierarchical

techniques（Warnier

diagrams）Structured ysis

and

Design

Technique(SADT)Object-oriented

specifications面 象的規(guī)格說明層次方框圖:

用樹形結(jié)構(gòu)的一系列多層次的矩形描述數(shù)據(jù)的層次結(jié)構(gòu)層次技術(shù)Warnier

DiagramsWarnier

圖示例報(bào)紙專欄的數(shù)據(jù)層次結(jié)構(gòu)○+IPO圖（input

,processing

,output)其他圖形工具改進(jìn)的IPO圖其他圖形工具Douglas

Ross提出，由DeMarco推廣，由Ward和Mellor以及后來的Hatley和Pirbhai

構(gòu)化分析方法的框架。結(jié)構(gòu)化分析方法是一種建模技術(shù)。它建立的分析模型

。這種分析模型必須達(dá)到三個(gè)主要目標(biāo)：(1)

描述用戶要求；(2)

建立(3)

定義設(shè)計(jì)的基礎(chǔ)；開發(fā)完成時(shí)必須確認(rèn)的一組需求。在模型的是數(shù)據(jù)詞典，它描述了所有的在目標(biāo)系統(tǒng)中使用的和生成的數(shù)據(jù)對(duì)象。圍繞著這個(gè)的有三種圖：實(shí)體 關(guān)系圖(ERD)描述數(shù)據(jù)對(duì)象及數(shù)據(jù)對(duì)象之間的關(guān)系；數(shù)據(jù)流圖(DFD)描述數(shù)據(jù)在系統(tǒng)中如何被傳送或變換，以及描述如何對(duì)數(shù)據(jù)流進(jìn)行變換的功能（子功能）；狀態(tài)

遷移圖(STD)描述系統(tǒng)對(duì)外部事件如何響應(yīng)，如何動(dòng)作。（2）功能建模和數(shù)據(jù)流（3）行為建模（4）數(shù)據(jù)詞典數(shù)據(jù)建模數(shù)據(jù)模型包括三種互相關(guān)聯(lián)的信息：數(shù)據(jù)對(duì)象描述對(duì)象的屬性描述對(duì)象間相互連接的關(guān)系數(shù)據(jù)建模方法用來創(chuàng)建部分分析模型，但它也可以用于數(shù)據(jù)庫(kù)設(shè)計(jì)并支持其他的需求分析方法。1數(shù)據(jù)對(duì)象數(shù)據(jù)對(duì)象是需被目標(biāo)系統(tǒng)所理解的復(fù)合信息的表示。所謂復(fù)合信息是具有若干不同特征或?qū)傩缘男畔ⅰ?shù)據(jù)對(duì)象可以是外部實(shí)體（如顯示器），事物（如報(bào)表或顯示），角色（如教師或?qū)W生），行為（如一個(gè)

呼叫）或事件（如單擊鼠標(biāo)左鍵），組織單位（如院），地點(diǎn)（如室）或結(jié)構(gòu)（如文件）。數(shù)據(jù)對(duì)象只封裝了數(shù)據(jù)，沒有包含作用于這些數(shù)據(jù)上的操作。這與面象開發(fā)方法中的類和對(duì)象不同。具有相同特征的數(shù)據(jù)對(duì)象組成的集合仍然稱為數(shù)據(jù)對(duì)象，其中的某一個(gè)對(duì)象叫做該數(shù)據(jù)對(duì)象的一個(gè)實(shí)例。2、屬性屬性定義了數(shù)據(jù)對(duì)象的特可用來：(1)

為數(shù)據(jù)對(duì)象的實(shí)例命名；描述這個(gè)實(shí)例；建立對(duì)另一個(gè)數(shù)據(jù)對(duì)象的另一個(gè)實(shí)例的。如學(xué)生數(shù)據(jù)對(duì)象的屬性可以有學(xué)號(hào)、出生年月、籍貫等。為了唯一地標(biāo)識(shí)數(shù)據(jù)對(duì)象的某一個(gè)實(shí)例，定義數(shù)據(jù)對(duì)象中的一個(gè)屬性或幾個(gè)屬性為關(guān)鍵碼(key)，書寫為_id，例如在"學(xué)生"數(shù)據(jù)對(duì)象中用"學(xué)號(hào)"做關(guān)鍵碼，它可唯一地標(biāo)識(shí)一個(gè)"學(xué)生"數(shù)據(jù)對(duì)象中的實(shí)例。3、關(guān)系各個(gè)數(shù)據(jù)對(duì)象的實(shí)例之間可以按多種不同的方式相連接。4、基數(shù)和參與性提供更進(jìn)一步的有關(guān)數(shù)據(jù)對(duì)象關(guān)聯(lián)的信息。實(shí)例的關(guān)聯(lián)有三種：①

一對(duì)一

；②

一對(duì)多(1:m)；③

多對(duì)多(n:m)。這種實(shí)例的關(guān)聯(lián)稱為“基數(shù)”。基數(shù)表明了“重復(fù)性”。5

―關(guān)系圖數(shù)據(jù)對(duì)象及其關(guān)系可用ERD表示。ERD最初是由PeterChen為關(guān)系數(shù)據(jù)庫(kù)提出來的，后來又經(jīng)過了擴(kuò)展。ERD的主要目的是表示數(shù)據(jù)對(duì)象及其關(guān)系。它包括的基本成分有數(shù)據(jù)對(duì)象、屬性、關(guān)系和各種類型符號(hào)。實(shí)體―關(guān)系圖的建立步驟(1)在捕獲需求的過程中，要求用戶列出應(yīng)用或業(yè)務(wù)過程涉及到的所有“事物”。這些事物將來可能會(huì)演變?yōu)橐幌盗械妮斎?輸出數(shù)據(jù)對(duì)象以及生產(chǎn)和消費(fèi)信息的外部實(shí)體。(2)一次考慮一個(gè)對(duì)象。分析和用戶共同確認(rèn)這個(gè)對(duì)象與其他對(duì)象之間是否存在連接（在本階段不命名）。(3)

當(dāng)存在連接時(shí)，分析

和用戶應(yīng)創(chuàng)建一個(gè)或多個(gè)對(duì)象--關(guān)系對(duì)。(4)對(duì)每一個(gè)對(duì)象--關(guān)系對(duì)，它的基數(shù)和參與性。(5)迭代執(zhí)行步驟(2)～(4)，直到所有對(duì)象--關(guān)系對(duì)定義完成。在這個(gè)過程中發(fā)生遺漏是很正常的。在每次迭代時(shí)總會(huì)增加新的對(duì)象和關(guān)系。(6)(7)規(guī)范化并復(fù)審實(shí)體--關(guān)系圖。(8)重復(fù)執(zhí)行步驟(1)～(7)，直到數(shù)據(jù)建模完成。E-R圖中表示實(shí)體聯(lián)系的符號(hào)如下：在E-R圖中，每個(gè)方框表示實(shí)體型或?qū)傩裕娇蛑g的連線表示實(shí)體之間，或?qū)嶓w與屬性之間的聯(lián)系。出現(xiàn)在連線上的短豎線可以看成是“1”，而圓圈隱含表示“0”。例如，在教學(xué)管理中，一個(gè)教師可以教授零門、一門或多門課程，每位學(xué)生也需要學(xué)習(xí)幾門課程。因此，教學(xué)管理中涉及的對(duì)象（實(shí)體型）有學(xué)生、教師和課程。用E-R圖描述它們之間的聯(lián)系，得下圖。其中，學(xué)生與課程是多對(duì)多的聯(lián)系，而教師與課程的聯(lián)系是一對(duì)零或多。、專確定屬性。例如，學(xué)生具有學(xué)號(hào)、業(yè)（其它略）等屬性；課程具有課程號(hào)、課程名、學(xué)分、學(xué)時(shí)數(shù)等屬性；等教師具有職工號(hào)、屬性。此外，學(xué)生通過學(xué)號(hào)、分?jǐn)?shù)與課程發(fā)生聯(lián)系。如此可得教學(xué)實(shí)體模型。教學(xué)實(shí)體模型數(shù)據(jù)規(guī)范化的目的：為減少數(shù)據(jù)冗余，避免出現(xiàn)過程，通常用“范式(normal

forms)”定義消除數(shù)據(jù)冗余的程度數(shù)據(jù)規(guī)范化每個(gè)屬性值都必須是原子值，即僅僅是一個(gè)簡(jiǎn)單值而不含 結(jié)構(gòu)，第一范式（1NF）第二范式滿足第一范式條件，而且每個(gè)非關(guān)鍵字屬性都由整個(gè)關(guān)鍵字決定(而不是由關(guān)鍵字的一部分來決定)第二范式（2NF）數(shù)據(jù)冗余：同一門課程由n個(gè)學(xué)生選修，“學(xué)分”就重復(fù)n-1次；同一個(gè)學(xué)生選修了m門課程，

和

就重復(fù)了m-1次。更新異常：若調(diào)整了某門課程的學(xué)分，數(shù)據(jù)表中所有行的

“學(xué)分”值都要更新，否則會(huì)出現(xiàn)同一門課程學(xué)分不同的情況。異常：假設(shè)要開設(shè)一門新的課程，暫時(shí)還沒有人選修。這樣，由于還沒有“學(xué)號(hào)”關(guān)鍵字，課程名稱和學(xué)分也無法記錄入數(shù)據(jù)庫(kù)。刪除異常：假設(shè)一批學(xué)生已經(jīng)完成課程的選修，這些選修記錄就應(yīng)該從數(shù)據(jù)庫(kù)表中刪除。但是，與此同時(shí)，課程名稱和學(xué)分信息也被刪除了。第二范式（2NF）的例子把選課關(guān)系表SelectCourse改為如下三個(gè)表：學(xué)生：Student(學(xué)號(hào),

,

)；課程：Course(課程名稱,

學(xué)分)；選課關(guān)系：SelectCourse(學(xué)號(hào),課程名稱,成績(jī))。這樣的數(shù)據(jù)庫(kù)表是符合第二范式的，消除了數(shù)據(jù)冗余

更新異常、

異常和刪除異常。所有單關(guān)鍵字的數(shù)據(jù)庫(kù)表都符合第二范式

因?yàn)椴豢赡艽嬖诮M合關(guān)鍵字。第二范式（2NF）的例子第三范式符合第二范式的條件，且非主屬性相互獨(dú)立，即任何非主屬性間不存在函數(shù)依賴。假定學(xué)生關(guān)系表為Student(學(xué)號(hào),,,所在學(xué)院,學(xué)院地點(diǎn),學(xué)院)，關(guān)鍵字為單一關(guān)鍵字“學(xué)號(hào)”(學(xué)號(hào))→(,,所在學(xué)院,學(xué)院地點(diǎn),學(xué)院電話)這個(gè)數(shù)據(jù)庫(kù)是符合2NF的，但是不符合3NF，因?yàn)榇嬖诜顷P(guān)鍵字段“學(xué)院地點(diǎn)”、“學(xué)院”對(duì)非關(guān)鍵字段“所在學(xué)院”的函數(shù)依賴：(所在學(xué)院)→(學(xué)院地點(diǎn),學(xué)院)第三范式（3NF）功能建模和數(shù)據(jù)流最初，結(jié)構(gòu)化分析方法僅數(shù)據(jù)流建模。目標(biāo)系統(tǒng)被表示成數(shù)據(jù)變換流程圖。系統(tǒng)的功能體現(xiàn)在核心的數(shù)據(jù)變換中。系統(tǒng)的輸入源于用方框表示的外部實(shí)體，這種輸入系統(tǒng)的數(shù)據(jù)變換，產(chǎn)生傳遞給外部實(shí)體的輸出。功能建模的思想就是用抽象模型的概念，按照數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，直到找到滿足功能要求的所有可實(shí)現(xiàn)的為根據(jù)DeMarco

了數(shù)據(jù)流圖來表達(dá)系統(tǒng)內(nèi)數(shù)據(jù)的運(yùn)動(dòng)情況，而數(shù)據(jù)流的變換則用結(jié)構(gòu)化語言、判定表與判定樹來描述。1、數(shù)據(jù)流圖（Data

Flow

Diagrams）DFD的符號(hào)或數(shù)據(jù)的源點(diǎn)/終點(diǎn)或或變換數(shù)據(jù)的處理/加工/變換數(shù)據(jù)

（文件）數(shù)據(jù)流源點(diǎn)和終點(diǎn)源點(diǎn)和終點(diǎn)是系統(tǒng)之外的實(shí)體，可以是人、物或其他系統(tǒng)。源點(diǎn)和終點(diǎn)是為了幫助理解系統(tǒng)接口而引入的。加工/變換對(duì)數(shù)據(jù)進(jìn)行處理的單元。在分層數(shù)據(jù)流圖中，要對(duì)加工進(jìn)行

，以便于管理。加工也要選取適當(dāng)?shù)拿郑蕴岣邤?shù)據(jù)流圖的易讀性。DFD的符號(hào)數(shù)據(jù)流由一組數(shù)據(jù)項(xiàng)組成。例如，數(shù)據(jù)流“訂票單由住址航班號(hào)、日期始點(diǎn)終點(diǎn)等數(shù)據(jù)項(xiàng)組成；數(shù)據(jù)流“航班”由航班號(hào)、日期和等數(shù)據(jù)項(xiàng)組成數(shù)據(jù)流可以從加工流向加工，如“航班”、

“費(fèi)用”；可以從源點(diǎn)流向加工，或從加工流向終點(diǎn)；可以從加工流向數(shù)據(jù)或從數(shù)據(jù)流向加工DFD的符號(hào)文件用來暫時(shí) 數(shù)據(jù)的。如果加工要讀文件，則數(shù)據(jù)流的方向是從文件到加工；如果加工要寫文件，則數(shù)據(jù)流的方向是從加工到文件；如果加工既要讀文件又要寫文件，則數(shù)據(jù)流的方向是雙向的DFD的符號(hào)旅行社旅客預(yù)定機(jī)票機(jī)票準(zhǔn)備記帳DFDDFD的符號(hào)++AB⊕C有A或有B，但不能A、B同時(shí)存在，就有C采購(gòu)部每天需要一張定貨報(bào)表通過放在倉(cāng)庫(kù)中的CRT終端把事務(wù)報(bào)告給定貨系統(tǒng)。怎樣畫DFD：定貨系統(tǒng)的例子怎樣畫DFD：定貨系統(tǒng)的例子源點(diǎn)/終點(diǎn)采購(gòu)員倉(cāng)庫(kù)管理員數(shù)據(jù)流定貨報(bào)表零件 零件名稱定貨數(shù)量

目前價(jià)格主要供應(yīng)者

次要供應(yīng)者事務(wù)零件事務(wù)類型數(shù)量處理產(chǎn)生報(bào)表處理事務(wù)數(shù)據(jù)定貨信息（同定貨報(bào)表）庫(kù)存零件庫(kù)存量庫(kù)存量臨界值定貨系統(tǒng)的基本系統(tǒng)模型定貨系統(tǒng)的功能級(jí)數(shù)據(jù)流圖把處理事務(wù)的功能進(jìn)一步分解后的數(shù)據(jù)流圖2、分層數(shù)據(jù)流圖為了表達(dá)數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，用一個(gè)數(shù)據(jù)流圖是不夠的。稍為復(fù)雜的實(shí)際問題，在數(shù)據(jù)流圖上常常出現(xiàn)十幾個(gè)甚至幾十個(gè)加工。這樣的數(shù)據(jù)流圖看起來很不清楚。層次結(jié)構(gòu)的數(shù)據(jù)流圖能很好地解決這一問題。按照系統(tǒng)的層次結(jié)構(gòu)進(jìn)行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結(jié)構(gòu)關(guān)系，能清楚地表達(dá)和容易理解整個(gè)系統(tǒng)。把基本系統(tǒng)模型加上源點(diǎn)和終點(diǎn)作為頂層數(shù)據(jù)流圖自頂向下逐層畫數(shù)據(jù)流圖的步驟分層的數(shù)據(jù)流圖分層的數(shù)據(jù)流圖分層的數(shù)據(jù)流圖畫數(shù)據(jù)流圖不是畫流程圖父圖和子圖的平衡問題局部文件的問題命名問題畫數(shù)據(jù)流圖需要注意的幾個(gè)問題12435763.13.23.33.43.63.5ACBYEXWVFDGHDFGH父圖和子圖的平衡問題12344.44.34.24.1AGCBFDEEHLFG1323.13.2考生成績(jī)錄取通知書考生準(zhǔn)考證號(hào)通訊地址考生成績(jī)文件(數(shù)據(jù)

)總是局部于分層數(shù)據(jù)流圖的某一層或某幾層,所以數(shù)據(jù)流圖中引入的文件都是局部文件局部文件的問題12.132.242.3ABCABCDEG2FFED一個(gè)加工的分解最好不要超過9個(gè)子加工。超過9個(gè)時(shí)，可以用增加層次，減少子加工數(shù)的方法。分解在邏輯上應(yīng)合

能硬性分割。也就是說，要根據(jù)問題的邏輯特性進(jìn)行分解。在保證數(shù)據(jù)流的易理解的前提下，盡量減少分解層次。這樣可以減少層次的界面。分解要均勻。即在一張數(shù)據(jù)流圖中，不要有這樣的情況：有些加工已是基本加工，另一些加工還要分解好幾層，但絕對(duì)均勻不可能，不要相差太大。數(shù)據(jù)流命名名字應(yīng)代表整個(gè)數(shù)據(jù)流（有時(shí)也會(huì)把現(xiàn)實(shí)環(huán)境中傳遞的一組數(shù)據(jù)中最重要的那個(gè)數(shù)據(jù)的名字作為數(shù)據(jù)流的名字）命名問題（數(shù)據(jù)流）考生成績(jī)分類后的考生成績(jī)錄取分類現(xiàn)實(shí)環(huán)境中，傳遞的一些表格、單據(jù)的名字可以直接作為數(shù)據(jù)流的名字。命名問題（數(shù)據(jù)流）車間調(diào)度全廠統(tǒng)計(jì)生產(chǎn)報(bào)表統(tǒng)計(jì)表日?qǐng)?bào)表月報(bào)表不要使用空洞的、缺乏具體含義的名字控制流作為數(shù)據(jù)流。如果在為某個(gè)數(shù)據(jù)流命名時(shí)遇到

，可能是數(shù)據(jù)流圖分解不當(dāng)，應(yīng)考慮重新分解DFD命名問題（數(shù)據(jù)流）錄取分類取下一個(gè)考生成績(jī)加工（處理）命名頂層的加工名可以是項(xiàng)目的名字。不要使用空洞的、缺乏具體含義的名字。通常先為數(shù)據(jù)流命名，然后再為與之相關(guān)聯(lián)的處理命名。這樣命名比較容易，而且體現(xiàn)了人類

的“由表及里”的思考過程。如果在為某個(gè)加工命名時(shí)遇到

，可能是數(shù)據(jù)流圖分解不當(dāng)，應(yīng)考慮重新分解DFD。命名問題（處理）加工的名字最好由一個(gè)謂語動(dòng)詞加上一個(gè)賓語組成。如“計(jì)算運(yùn)費(fèi)”、“準(zhǔn)備機(jī)票

。也可以把賓語和謂語動(dòng)詞顛倒書寫。如“運(yùn)費(fèi)計(jì)算”、“機(jī)票準(zhǔn)備”。名字應(yīng)該反映整個(gè)處理的功能，而不是它的一部分功能。通常名字中僅包括一個(gè)動(dòng)詞，如果必須用兩個(gè)動(dòng)詞才能描述整個(gè)處理的功能，則把這個(gè)處理再分解成兩個(gè)處理可能更恰當(dāng)些。命名問題（處理）從數(shù)據(jù)流圖出發(fā)出結(jié)構(gòu)從數(shù)據(jù)流圖出發(fā)出結(jié)構(gòu)3

加工規(guī)格說明用來說明DFD中的數(shù)據(jù)加工的加工細(xì)節(jié)。加工規(guī)格說明描述了數(shù)據(jù)加工的輸入，實(shí)現(xiàn)加工的算法以及產(chǎn)生的輸出。另外，加工規(guī)格說明指明了加工（功能）的約束和限制，與加工相關(guān)的性能要求，以及影響加工的實(shí)現(xiàn)方式的設(shè)計(jì)約束。寫加工規(guī)格說明的主要目的是要表達(dá)"做什么"，而不是"怎樣做"。因此它應(yīng)描述數(shù)據(jù)加工實(shí)現(xiàn)加工的策略而不是實(shí)現(xiàn)加工的細(xì)節(jié)。用于寫加工邏輯說明的工具結(jié)構(gòu)化英語（Structured

English）判定表（Decision

Table）判定樹（Decision

Tree）是一種介于自然語言和形式化語言之間的語言。結(jié)構(gòu)化英語的詞匯表由英語命令動(dòng)詞；數(shù)據(jù)詞典中定義的名字；有限的自定義詞；控制結(jié)構(gòu)CASE_OFIF_THEN_ELSEWHILE_DOREPEAT_UNTIL等組成。結(jié)構(gòu)化英語語言的正文用基本控制結(jié)構(gòu)進(jìn)行分割，加工中的操作用自然語言短語來表示其基本控制結(jié)構(gòu)有三種：簡(jiǎn)單陳述句結(jié)構(gòu)；重復(fù)結(jié)構(gòu)：while do

或

repeat_until

結(jié)構(gòu)；判定結(jié)構(gòu)：if_then

或

case_of

結(jié)構(gòu)；if

發(fā)貨單金額超過$500

thenif

欠款超過了60天then在償還欠款前不予批準(zhǔn)else

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

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

欠款超過60天then發(fā)批準(zhǔn)書，發(fā)貨單及賒欠報(bào)告else

（欠款未超期）發(fā)批準(zhǔn)書，發(fā)貨單例：商店業(yè)務(wù)處理系統(tǒng)中“檢查發(fā)貨單”4

針對(duì)實(shí)時(shí)系統(tǒng)的Ward&Mellor擴(kuò)展為適應(yīng)實(shí)時(shí)系統(tǒng) 以下要求進(jìn)行的擴(kuò)展：(1)在時(shí)間連續(xù)的基礎(chǔ)上接收或產(chǎn)生數(shù)據(jù)流；(2)貫穿系統(tǒng)的控制信息和相關(guān)的控制處理；在多任務(wù)的情況下可能會(huì)遇到同一個(gè)加工的多個(gè)實(shí)例；系統(tǒng)狀態(tài)以及導(dǎo)致系統(tǒng)狀態(tài)遷移的機(jī)制。時(shí)間連續(xù)的數(shù)據(jù)流與普通數(shù)據(jù)流事件可以作為普通數(shù)據(jù)加工的輸入數(shù)據(jù)流，控制也可以接收普通的輸入數(shù)據(jù)流。5

Hatley和Pirbhai對(duì)結(jié)構(gòu)化分析技術(shù)的擴(kuò)展該擴(kuò)展主要關(guān)注面向控制的規(guī)格說明，而不是擴(kuò)充數(shù)據(jù)流圖的圖形符號(hào)。通過建立控制流圖(CFD)以區(qū)別于數(shù)據(jù)流圖(DFD)。在控制流圖中的加工與數(shù)據(jù)流圖中相同，但傳遞的是控制流而不是數(shù)據(jù)流。用數(shù)據(jù)流圖表示對(duì)數(shù)據(jù)和操作數(shù)據(jù)的加工；用控制流圖表示事件在加工之間如何流動(dòng)，說明導(dǎo)致各個(gè)加工激活的外部事件。Ward

&

Pirbhai方法行為建模行為建模給出需求分析方法的所有操作原則，只在結(jié)構(gòu)化分析方法的擴(kuò)充版本才提供這種建模的符號(hào)。行為建模的工具：1、狀態(tài) 遷移圖Petri網(wǎng)控制規(guī)格說明（狀態(tài)

遷移圖(STD)

、加工激活表

）數(shù)據(jù)字典（DD）數(shù)據(jù)詞典精確地、嚴(yán)格地定義了每一個(gè)與系統(tǒng)相關(guān)的數(shù)據(jù)元素，并以字典式順序?qū)⑺鼈兘M織起來，使得用戶和分析員對(duì)所有的輸入、輸出、

成分和中間計(jì)算有共同的理解。數(shù)據(jù)詞典表示每個(gè)數(shù)據(jù)對(duì)象和控制項(xiàng)的特性數(shù)據(jù)字典是對(duì)數(shù)據(jù)流圖中包含的所有元素的定義的集合，使得每個(gè)圖形元素都有確切解釋。數(shù)據(jù)字典與數(shù)據(jù)流圖共同構(gòu)成系統(tǒng)的邏輯模型，數(shù)據(jù)子詞典與數(shù)據(jù)流圖配合，能清楚地表達(dá)數(shù)據(jù)處理的要求。詞條描述是對(duì)在數(shù)據(jù)流圖中每一個(gè)被命名的圖形元素的定義，內(nèi)容有:圖形元素名字、別名或、分類、描述、定義、位置、其它等。定義絕大多數(shù)復(fù)雜事物的方法，都是用被定義的事物的成分的某種組合表示這個(gè)事物，這些組成成分又由更低層的成分的組合來定義。順序即以確定次序連接兩個(gè)或多個(gè)分量選擇即從兩個(gè)或多個(gè)可能的元素中選取一個(gè)重復(fù)即把指定的分量重復(fù)零次或多次可選即一個(gè)分量是可有可無的(重復(fù)零次或一次)符號(hào)含義舉例＋“被定義為與x=a＋bx由a和b組成或

x=[a,b]，

x由a或由b組成或

x=[a

|b]，

x由a或由b組成重復(fù)

x={a}，

x由0個(gè)或多個(gè)a組成重復(fù)

x=3{a}8，x由3到8個(gè)a組成可選

x

=(a)，在x中a可有可無[...

,

...][...|...]{

...

}m{...}n(...)“...”..基本數(shù)據(jù)元素

x=“a”，x是取值為a的元素連結(jié)符

x

=

1..9，x可取1到9中任一值數(shù)據(jù)流條目中出現(xiàn)的符號(hào)數(shù)據(jù)流是數(shù)據(jù)結(jié)構(gòu)在系統(tǒng)內(nèi)

的路徑。一個(gè)數(shù)據(jù)流詞條應(yīng)有以下幾項(xiàng)內(nèi)容：數(shù)據(jù)流名；說明：簡(jiǎn)要介紹作用即它產(chǎn)生的原因和結(jié)果；數(shù)據(jù)流來源：來自何方；數(shù)據(jù)流去向：去向何處；數(shù)據(jù)流組成：數(shù)據(jù)結(jié)構(gòu)；每個(gè)數(shù)據(jù)量的流通量：數(shù)據(jù)量，流通量；（1）數(shù)據(jù)流詞條描述數(shù)據(jù)流條目的例子數(shù)據(jù)流條目的例子戶名＋所號(hào)＋帳號(hào)＋

日＋性質(zhì)＋(印密)＋1{存取行}50戶名＝2{字母}24所號(hào)＝“001”..“999”帳號(hào)＝“00000001”..“99999999”日

年＋月＋日

1”..“6”

注：“1”表示普通戶，“5”表示工資戶等印密＝“0”

注：印密在

上不顯示存取行＝日期＋（

）＋支出＋存入＋余額＋操作＋復(fù)核DFD中每個(gè)數(shù)據(jù)結(jié)構(gòu)都是由數(shù)據(jù)元素構(gòu)成的，數(shù)據(jù)元素是數(shù)據(jù)處理中最小的、不可再分的單位，它直接反映事物的某一特征，其描述需要以下信息：數(shù)據(jù)元素名；編碼類類型：數(shù)字（離散值，連續(xù)值）型）；長(zhǎng)度；取值范圍；相關(guān)的數(shù)據(jù)元素及數(shù)據(jù)結(jié)構(gòu)；（2）數(shù)據(jù)元素詞條描述數(shù)據(jù)元素條目描述在實(shí)際應(yīng)用中，對(duì)數(shù)據(jù)流和數(shù)據(jù)元素的描述可以靈活地剪裁，數(shù)據(jù)流元素的描述也可以采用和數(shù)據(jù)流相似的方式。例如：名字（數(shù)據(jù)流名）：定貨報(bào)表別名：定貨信息描述（說明）：每天一次送給采購(gòu)員的需要定貨的零件表定義（數(shù)據(jù)流組成）：定貨報(bào)表

零件

+零件名稱+定貨數(shù)量+目前價(jià)格+主要供應(yīng)者+次要供應(yīng)者位置（數(shù)據(jù)流去向）：輸出到名字：定貨數(shù)量別名：描述：某個(gè)零件一次定貨的數(shù)量定義：定貨數(shù)量=1{數(shù)字}5位置（相關(guān)的數(shù)據(jù)結(jié)構(gòu)）：定貨報(bào)表定貨信息數(shù)據(jù)文件是數(shù)據(jù)結(jié)構(gòu)保存的地方。本類詞條應(yīng)有以下內(nèi)容：數(shù)據(jù)文件名；簡(jiǎn)述：存放的是什么數(shù)據(jù)；輸入數(shù)據(jù)；輸出數(shù)據(jù)；數(shù)據(jù)文件組成：數(shù)據(jù)結(jié)構(gòu)；方式：順序

直接，關(guān)鍵碼；存取頻率；（3）數(shù)據(jù)文件詞條描述加工到后來就是一段程序，它的表達(dá)方式有判定表、判定樹、結(jié)構(gòu)化英語等，在一個(gè)詞條中。主要內(nèi)容有：全部描述有加工名；加工加工的層次；簡(jiǎn)要描述：加工邏輯及功能簡(jiǎn)述；輸入數(shù)據(jù)流；輸出數(shù)據(jù)流；加工邏輯：簡(jiǎn)述加工程序，加工順序；（4）加工邏輯詞條描述對(duì)于數(shù)據(jù)處理系統(tǒng)來說，源點(diǎn)和匯點(diǎn)應(yīng)比較少，否則就會(huì)缺少獨(dú)立性，人機(jī)界面太立性。復(fù)雜，這時(shí)應(yīng)考慮減少以提高系這類詞條應(yīng)包括：名稱：外部實(shí)體名；簡(jiǎn)要描述：什么外部實(shí)體；有關(guān)數(shù)據(jù)流；數(shù)目；（5）源點(diǎn)及匯（終）點(diǎn)詞條描述分房標(biāo)準(zhǔn)文件住房文件住房文件房租文件調(diào)房咨詢退房查詢住戶情況、查詢房租統(tǒng)計(jì)數(shù)據(jù)流分析實(shí)例房管部門住戶檢查要求處理類型分配住房房租計(jì)算調(diào)房退房處理統(tǒng)計(jì)咨詢類別處理住房查詢房租查詢打印處理消去房租調(diào)房處理房租核計(jì)核對(duì)條件住房住房標(biāo)準(zhǔn)文件住房文件房租文件文件住房文件住房文件房租文件文件Object-oriented

specifications面 象的規(guī)格說明Each

entity

in

thesystem

isan

objectA

method

oroperation

is

an

action

thatcanbeperformed

directly

by

the

object

or

can

happen

totheobjectEncapsulation:

the

methods

form

a

protectiveboundary

around

an

objectClass

hierarchies

of

objec courage

inheritancePolymorphism: same

method

for

different

objects,each

with

different

behavior4.5

prototy

requirementsRapidprototy原型化需求buildsections

of

theproposedsystem

to

determine

the

necessity,desirability,orfeasibilityofrequirements.快速原型化構(gòu)造了部分期望的系統(tǒng)來確定需求的必要性、愿望或可行性。A

prototypegives

us

the

opportunity

to“fine

tune”what

our

customers

wantor

whatwe

think

willworkbest

ina

design.原型給了我們“調(diào)整”顧客想要什么或者我們認(rèn)為在設(shè)計(jì)中會(huì)最有效的東西的機(jī)會(huì)。

原型化方法是在研究需求分析階段的方法和技術(shù)中產(chǎn)生的，它主要針對(duì)傳統(tǒng)方法所的

。因此，也面向

開發(fā)的其它項(xiàng)目的特點(diǎn)和運(yùn)行原型的目的不同，原型有三種不同的作用類型：探索型、實(shí)驗(yàn)型、演化型。探索型：目的是要弄清對(duì)目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性要針對(duì)開發(fā)目標(biāo)模糊，用戶和開發(fā)者對(duì)項(xiàng)目都缺乏經(jīng)驗(yàn)的情況。之前，考核方案是實(shí)驗(yàn)型：用于大規(guī)模開發(fā)否合適，規(guī)格說明是否可靠。演化型：目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在