【正文】 刻畫系統(tǒng)輸出對于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對話框等形式。系統(tǒng)是否可以提高效率，減少人員的工作量。 系統(tǒng)目的許多醫(yī)院存在高峰期掛號(hào)排隊(duì)時(shí)間長，就診等待時(shí)間長，倒號(hào)現(xiàn)象頻發(fā)的問題。本節(jié)屬于引言部分，主要用于對文檔本身進(jìn)行定義和描述。（1）系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕：系統(tǒng)的預(yù)約頁面可以顯示未來1至3天的出診醫(yī)生及其所有可被預(yù)約的出診時(shí)段。l 非功能性需求 為了保證預(yù)約掛號(hào)系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（2）系統(tǒng)運(yùn)營成本低：系統(tǒng)在運(yùn)行過程中，應(yīng)該盡可能少的占用資源。 假定與依賴本系統(tǒng)假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統(tǒng)的引導(dǎo)和提示下正常使用系統(tǒng)。患者被告知預(yù)約選擇結(jié)果。 操作過程模型本部分將主要對圖 51，圖 53和圖 54所示的操作過程模型進(jìn)行說明，并以表格的形式列出各操作過程的參與主體及對應(yīng)需求。以上部分涉及到的操作過程及與之對應(yīng)的主體、需求如表 41所示。患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過系統(tǒng)提供的頁面與系統(tǒng)進(jìn)行交互。l 患者預(yù)約系統(tǒng)系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕。l 管理員負(fù)責(zé)對出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。 為了保證預(yù)約掛號(hào)系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（2）系統(tǒng)接收到預(yù)約提交請求：當(dāng)患者點(diǎn)擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請求。由于系統(tǒng)整體較為復(fù)雜，因此本小節(jié)只包含已構(gòu)建目標(biāo)模型的功能性需求和非功能性需求。l 安全保障系統(tǒng)網(wǎng)上預(yù)約掛號(hào)系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡(luò)及數(shù)據(jù)庫安全。因此，基于之前構(gòu)建的各類模型，撰寫系統(tǒng)的需求說明文檔，并將其作為后續(xù)項(xiàng)目設(shè)計(jì)、項(xiàng)目開發(fā)和項(xiàng)目測試的指導(dǎo)。比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應(yīng)該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。 輸入事件分析對于該系統(tǒng)的輸入事件可能會(huì)包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊，而對于已經(jīng)注冊的用戶在使用系統(tǒng)預(yù)約掛號(hào)時(shí)首先要登錄系統(tǒng)。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進(jìn)行了預(yù)約，然后管理員會(huì)根據(jù)現(xiàn)有的資源（可以預(yù)約的醫(yī)生）對預(yù)約進(jìn)行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預(yù)約的醫(yī)生或合適的時(shí)間，患者的預(yù)約就不成功，患者需要重新選擇醫(yī)生或時(shí)間進(jìn)行預(yù)約?；颊呦Ｍㄟ^完成注冊和登錄后能夠進(jìn)行掛號(hào)預(yù)約，查詢醫(yī)生的出診信息和個(gè)人預(yù)約信息，并且能夠在規(guī)定的時(shí)間內(nèi)完成掛號(hào)預(yù)約或者取消已有的預(yù)約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預(yù)約情況；而管理員希望可以修改出診信息和調(diào)整預(yù)約掛號(hào)。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對系統(tǒng)進(jìn)行需求建模和分析是十分必要的。有意向的雙方可以通過網(wǎng)上面試的方式來進(jìn)行進(jìn)一步的溝通，提高學(xué)生和用人單位接觸頻率，促進(jìn)就業(yè)工作開展。（4）網(wǎng)絡(luò)資源的充分利用。市場前景及經(jīng)濟(jì)效益初步分析這個(gè)系統(tǒng)雖然不是學(xué)院的直接收益產(chǎn)品，但其帶來的間接效益是毋庸置疑。項(xiàng)目產(chǎn)品或服務(wù)的市場預(yù)測（由于這個(gè)系統(tǒng)不是學(xué)院的直接收益產(chǎn)品，這里不做分析。項(xiàng)目的意義和必要性畢業(yè)生就業(yè)信息系統(tǒng)和就業(yè)服務(wù)體系不完善，畢業(yè)生就業(yè)主要由學(xué)校、人才市場舉辦招聘會(huì)等方式獲得信息，與需求方見面，信息渠道比較窄。四、實(shí)驗(yàn)步驟背景介紹隨著internet的迅猛發(fā)展和普及，我國高等院校紛紛建立自己的校園網(wǎng)，使高校的辦公，教學(xué)和管理工作發(fā)生了巨大的變化，并具有了新的特點(diǎn)，對教學(xué)管理工作提出了新的要求，也使得基于網(wǎng)絡(luò)的高校畢業(yè)生就業(yè)招聘成為可能。1．工作表述開發(fā)商將執(zhí)行下面任務(wù)：開發(fā)項(xiàng)目管理軟件。1)高優(yōu)先權(quán)，表明需求必須體現(xiàn)在本階段項(xiàng)目的成果中或這個(gè)產(chǎn)品的版本中。為了避免需求的不可行性，在需求分析階段應(yīng)該有核心技術(shù)人員參與，檢查在技術(shù)上什么能做、什么不能做，哪些需要額外的付出等。編寫優(yōu)秀的項(xiàng)目需求[建議書沒有公式化的方法，需要大量的實(shí)踐經(jīng)驗(yàn)?？蛻籼峁┙o所有競標(biāo)供應(yīng)商的信息都是一樣的，避免了跟各開發(fā)商的重復(fù)溝通，同時(shí)，有需求建議書作為基準(zhǔn)，客戶可以約束各開發(fā)商以一致的格式提交方案建議書，以提高各供應(yīng)商之間的可比性。雖然它不能確?？蛻魮?jù)此就能獲得理想的解決方案，但卻可以幫助客戶發(fā)現(xiàn)那些盡可能接近自身需求的系統(tǒng)準(zhǔn)備。開發(fā)商是否能按照所要求的進(jìn)度完成項(xiàng)目計(jì)劃?(4)成本。例如，要求開發(fā)商在接到需求建議書后多少個(gè)工作口之內(nèi)(如l周之內(nèi)、1個(gè)月之內(nèi)等)提交申請書，或大家一律在某月某日之前提交申請書。一般依項(xiàng)目的性質(zhì)來定付款方式。6．期望的合同類型(1)合同可以按固定價(jià)格訂立。例如，對于自動(dòng)結(jié)賬和收款系統(tǒng)來說，客戶可能要求開發(fā)商提供硬件(計(jì)算機(jī))、軟件(磁盤和一些印刷品)、操作手冊和培訓(xùn)課程。一份好的rfp應(yīng)該包括以下一些內(nèi)容。也就是說，需求建議書是客戶向服務(wù)商發(fā)出的用來說明如何滿足其已識(shí)別需求的建議書，是客戶與服務(wù)商建立正式聯(lián)系的第一份書面文件，又稱招標(biāo)書。（6）希望這個(gè)項(xiàng)目在兩個(gè)月內(nèi)完成，從5月15日到7月15日，所有的可交付成果 必須不遲于7月15日提供給本人。為了在要求的項(xiàng)目完成日期內(nèi)或在此日期之前完成項(xiàng)目，承約商應(yīng)提出進(jìn)度計(jì)劃的詳細(xì)而全面的連續(xù)說明。(7)承包商需列出貴公司的軟件能力成熟度(cmmi)等級(jí)。申請內(nèi)容(1)承約商能清晰理解需求建議書，理解什么是被期望達(dá)到的要求。并且在后期一定時(shí)間內(nèi)提供免費(fèi)維護(hù)。數(shù)據(jù)備份功能。(4)數(shù)據(jù)查詢功能：包括在診室管理中的藥品的模糊查詢，對庫存不足的藥品報(bào)警，內(nèi)部資料管理中的醫(yī)師、患者信息的查詢中包括單項(xiàng)查詢和組合查詢。但這是當(dāng)面調(diào)研的基礎(chǔ)，一定要做，有粗糙疏漏的地方可以再現(xiàn)場調(diào)研時(shí)再細(xì)化。我們在完成大量的需求文檔編寫工作后，在開發(fā)階段有部分文檔沒有做內(nèi)容檢查和及時(shí)更新。我們安排每個(gè)人至少負(fù)責(zé)一個(gè)子系統(tǒng)的需求，但是在調(diào)研時(shí)，只要可能，我們都盡量讓每個(gè)人都參與所有系統(tǒng)的調(diào)研會(huì)議。調(diào)研概要情況：X項(xiàng)目需求調(diào)研開始于2006323結(jié)束于2006615，內(nèi)容包括現(xiàn)場需求調(diào)研4個(gè)人月和分析需求編寫需求文檔6個(gè)人月。多個(gè)需求盡可能拆分開。4）提高自己的速記能力，文字表述能力以及歸納，能迅速的記錄需求調(diào)研核心的問題，總結(jié)歸納形成原始的需求調(diào)研資料。2）做好調(diào)研前使用資料的準(zhǔn)備，如需求調(diào)研模板，需求調(diào)研問題列表等。可以采取的措施是事先編制一個(gè)問卷調(diào)查之類的文檔，詳細(xì)列舉需要客戶回答的問題，以便防止遺漏。e)項(xiàng)目的成熟度受客戶預(yù)算的限制。分析人員或客戶理解有誤 畢竟，不是每個(gè)分析人員都是專業(yè)而合格的，為避免這種情況的發(fā)生，需求分析必須要有審核制度，公司自己內(nèi)部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評(píng)審簽字，確認(rèn)。c)需求報(bào)告的編寫者要能夠?qū)蛻粜枨筮M(jìn)行深入分析，區(qū)別出哪些需求存在日后變更的可能，哪些需求屬于相對固定的，哪些需求能夠?qū)崿F(xiàn)，哪些需求需要變通才能實(shí)現(xiàn)，以便于指導(dǎo)后面的功能設(shè)計(jì)。大部分客戶在項(xiàng)目投入上都是有預(yù)算的，在成本有上限的前提下，項(xiàng)目的功能設(shè)計(jì)(軟件的成熟度)方面必然受一定影響，畢竟功能越多越完善，相應(yīng)的開發(fā)成本就越高。由此出現(xiàn)的問題：a)需求分析過于籠統(tǒng)，只關(guān)注到面上，沒有關(guān)注到點(diǎn)上，開發(fā)出來的東西在具體的細(xì)節(jié)上和客戶的理解有誤差，并且無法嚴(yán)格界定是否屬于需求變更。分析人員或客戶理解有誤畢竟，不是每個(gè)分析人員都是專業(yè)而合格的，為避免這種情況的發(fā)生，需求分析必須要有審核制度，公司自己內(nèi)部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評(píng)審簽字，確認(rèn)。e)項(xiàng)目的成熟度受客戶預(yù)算的限制?？梢圆扇〉拇胧┦鞘孪染幹埔粋€(gè)問卷調(diào)查之類的文檔，詳細(xì)列舉需要客戶回答的問題，以便防止遺漏。需求自身經(jīng)常變動(dòng) 隨著客戶對這個(gè)項(xiàng)目越來越深刻的理解，那么可能他的需求也會(huì)隨之改變，這些變化的可能性越大項(xiàng)目風(fēng)險(xiǎn)就會(huì)越大，我們在需求分析的時(shí)候就要充分考慮到哪些需求是相對固定的需求，哪些可能會(huì)是產(chǎn)生變動(dòng)的需求，考慮到他的可變性，這樣設(shè)計(jì)功能和數(shù)據(jù)庫的時(shí)候不致因?yàn)楹竺娴淖儎?dòng)而影響整個(gè)工程。d)對雙方已經(jīng)確定的需求，實(shí)現(xiàn)以后并不適合客戶使用，需要按照變更手續(xù)執(zhí)行的時(shí)候，客戶可能會(huì)糾纏，提出“你們是專業(yè)人士，你們應(yīng)該事先能提醒我們可能會(huì)出現(xiàn)這種問題”并以此來把責(zé)任推給我們，而我們又不好完全按照變更手續(xù)執(zhí)行，因?yàn)榭赡芗せp方的矛盾，比如508的批量處理功能，因?yàn)閷儆谌耸鹿芾肀容^專業(yè)的細(xì)節(jié)問題，需求分析師開始沒有對客戶業(yè)務(wù)熟悉到如此細(xì)致的地步，而客戶也沒有過多關(guān)注這些細(xì)節(jié)，導(dǎo)致軟件的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導(dǎo)致成本增加、工期延長。對于說不清楚需求的客戶，要善于問關(guān)鍵問題，引導(dǎo)客戶提出自己的需求。第三篇：軟件項(xiàng)目需求調(diào)研總結(jié)軟件項(xiàng)目需求調(diào)研總結(jié)一、需求調(diào)研準(zhǔn)備：在需求調(diào)研過程中，應(yīng)該做好三種準(zhǔn)備，保持兩種心態(tài)，做到五種提高：三種準(zhǔn)備1）調(diào)研前應(yīng)該將所有項(xiàng)目前期資料進(jìn)行匯總，與相關(guān)的前期銷售人員進(jìn)行交流，以便對項(xiàng)目有一個(gè)基本輪廓的認(rèn)識(shí)。3）需求調(diào)研中，學(xué)會(huì)盡量不使用IT行業(yè)的術(shù)語，而采用淺顯易懂的口頭語言來解釋IT行業(yè)中高深莫測的術(shù)語，以便用戶能夠很好的理解，提高自己的溝通交流能力。使用術(shù)語，要保持一致性，并在術(shù)語表或數(shù)據(jù)字典中定義它們需求編寫者還要努力正確地把握粒度。我希望我們能得到一塊“德芙”。這個(gè)項(xiàng)目規(guī)模比較大，根據(jù)業(yè)務(wù)的類型不同，分成了6個(gè)子系統(tǒng)，各個(gè)子系統(tǒng)的業(yè)務(wù)信息互有接口。，在開發(fā)階段也應(yīng)該做檢查和更新，避免文檔錯(cuò)誤對開發(fā)的誤導(dǎo)。需求報(bào)告的質(zhì)量往往和關(guān)鍵用戶的投入多少有較大關(guān)系，經(jīng)常在沒有面對面溝通時(shí)，關(guān)鍵用戶未必能對這份報(bào)告投入很多的時(shí)間和精力。(3)數(shù)據(jù)的修改和刪除功能：其中包括改號(hào)、退號(hào)和內(nèi)部資料管理中的患者、醫(yī)師信息的修改和刪除功能。(9)系統(tǒng)管理功能：其中包括用戶和內(nèi)部人員的修改密碼功能，根據(jù)權(quán)限添加用戶和管理員。（3）在合同預(yù)期內(nèi)，交付我院一個(gè)能夠運(yùn)行正常穩(wěn)定的完整的系統(tǒng)。（9）本院將按照下面的時(shí)間表付款給承約商：當(dāng)項(xiàng)目完成了1/3時(shí)付總額的1/3；當(dāng)項(xiàng)目完成了2/3時(shí)付總額的2/3；當(dāng)本人已經(jīng)滿意于項(xiàng)目的100%，并且承約商已履行了全部契約義務(wù)時(shí)再付出總額的最后1/3。此外，所有直接費(fèi)用逐條列表也必須包括進(jìn)來。d．進(jìn)度計(jì)劃(10%)。（5）當(dāng)裝修工程完成1／2時(shí)付總額的1／2；當(dāng)裝修工程100%完成時(shí)，獲得本人的滿意后，并且承約商已經(jīng)全部履行契約義務(wù)時(shí)再付總額的最后1／2。（8）申請書的評(píng)價(jià)標(biāo)準(zhǔn)1）承約商提出的建設(shè)方案（30%）2）被指定為執(zhí)行此項(xiàng)目主要負(fù)責(zé)人的姓名和聯(lián)系方式，以及類似的工作經(jīng)驗(yàn)（30%）3）承約商申請書所列的固定成本（30%）4）承約商提供的施工計(jì)劃（10%）組員：岳紅 117 王華 213 周燕飛 126 趙涵玉 223 曾志錦 203 篇四：需求建議書需求建議書（request for proposal，rfp）什么是需求建議書[1] 需求建議書是指從客戶角度出發(fā)，全面、詳細(xì)地向服務(wù)商陳述、表達(dá)為了滿足其已識(shí)別需求所應(yīng)做的準(zhǔn)備工作。rfp中包括項(xiàng)目的目標(biāo)，也就是用戶的期望，也包括客戶要求項(xiàng)目的進(jìn)度計(jì)劃；對實(shí)施商申請書的表格和內(nèi)容的規(guī)定；客戶希望潛在的實(shí)施商提交投標(biāo)申請書的最后期限；評(píng)價(jià)申請書的標(biāo)準(zhǔn)等。3．交付物交付物就是開發(fā)商所提供的實(shí)體內(nèi)容，這在需求建議書中應(yīng)該說明。這一點(diǎn)在需求建議書中必須向開發(fā)商說明。7．期望的付款方式付款方式可以分為一次性付款和分階段付款；在開始前付款和結(jié)束后付款。10．提交申請書的最后期限申請書受理的截止日期是必須要交代清楚的。(3)進(jìn)度計(jì)劃。需求建議書是客戶為確保供應(yīng)商理解項(xiàng)目的需求，并在此基礎(chǔ)上提供項(xiàng)目建議書而編制的需求規(guī)范。第二，需求建議書可節(jié)省選型的時(shí)間，并使得對各供應(yīng)商之間的比較變得更容易。編寫項(xiàng)目需求說明的j過程也是項(xiàng)目小組帶領(lǐng)客戶進(jìn)入項(xiàng)目需求啟發(fā)的過程。項(xiàng)目的需求應(yīng)該在有限的資源(已知的能力、有限的系統(tǒng)及其環(huán)境)下是可實(shí)現(xiàn)的。一般優(yōu)先權(quán)有以下三個(gè)級(jí)別。[編輯] 需求建議書例子[2] 例：某企業(yè)項(xiàng)目管理軟件開發(fā)項(xiàng)目需求建議書有關(guān)單位：某企業(yè)(甲方)由于業(yè)務(wù)發(fā)展的需要，