【正文】 HTML文本和行號以及錯誤的描述 。 單詞 “ 快速 ” 使其模糊 ， 沒有加進錯誤報告的定義也是不完整的 。 只有設計人員選定了觸發(fā)條件后 ， 你才能編寫測試驗證觸發(fā)的正確操作 。 現(xiàn)在就很清楚 ， 不可打印字符是 HTML標記 。 不可打印字符和隱藏字符一樣嗎 ？ 或者是一些屬性標志或一些控制字符 ？ 問題的后果 ， 就是需求的不可證實 。 它的不完整性表現(xiàn)在沒有聲明觸發(fā)狀態(tài)切換的條件 。 使在構造和測試時 ， 被易于分別執(zhí)行 。 問題的后果 ， 就是需求的不可證實 。 這個需求有幾處含糊 。 如果在調查 、 定義需求時想好了 “ 怎么做 ” ， 當然應該寫下來 ， 否則豈不浪費 ！ 關鍵是不要將 “ 怎么做 ” 寫到需求規(guī)格說明書里面 ， 記錄在其它文檔里就行了 。 ? 國內的很多軟件公司里 ， 開發(fā)人員常常身兼數(shù)職 ， 可能把需求開發(fā) 、 系統(tǒng)設計 、 編程等工作從頭做到尾 。 10 闡述 “ 做什么 ” 而不是 “ 怎么做 ” ? 《 產品需求規(guī)格說明書 》 的重點是闡述 “ 做什么 ” ， 而不是闡述 “ 怎么做 ” 。 ? 需求的優(yōu)先級其實就是需求 “ 輕重緩急 ” 的分級表述，例如劃分為 “ 高、中、低 ”三級。在項目剛開始的時候，開發(fā)方和客戶比較樂觀，什么都要做，可是做著做著，人們常常會面臨 “ 進度延誤、費用超支、人員不足 ”等問題，這時就亂套了。 . 什么是好的需求規(guī)格說明書 .9 確定優(yōu)先級 ? 為什么要確定需求的 “ 優(yōu)先級 ” ？ – 理論上講，軟件的所有需求都應當被實現(xiàn)。 如果需求是不可驗證的 ， 那么用戶就無法驗收軟件 ， 可能會發(fā)生商業(yè)糾紛 。 ? 對于合同項目，如果開發(fā)方不能確信某些需求是否可實現(xiàn)，則應事先與用戶協(xié)商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。吹牛皮雖然不犯法，但是 《 產品需求規(guī)格說明書 》 可是白紙黑字啊。 ? “ 可實現(xiàn) ” 意味著在技術上是可行的，并且滿足時間、費用、質量等約束。 ? 不完備的 《 產品需求規(guī)格說明書 》 將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。 .6 完備 ? “ 完備 ” （ Complete）是指 《 產品需求規(guī)格說明書 》 中沒有遺漏一些必要的需求。 開發(fā)者應當集中精力先完成必要的需求 ， 如果條件允許則再做 “ 錦上添花 ” 的需求 。 所以要盡量剔除需求規(guī)格說明書中 “ 畫蛇添足 ” 的那些需求 。 “ 必要 ” 往前一步 ， 要么是 “ 畫蛇添足 ” 要么是 “ 錦上添花 ” 。 .5 必要 ? 《 產品需求規(guī)格說明書 》 中的各項需求對用戶而言應當都是必要的 。 什么是好的需求規(guī)格說明書 .4 一致 ? “ 一致 ” （ Consistent）是指 《 產品需求規(guī)格說明書 》 中各個需求之間不會發(fā)生矛盾。如果需求存在二義性，將會導致人們誤解需求而開發(fā)出偏離需求的產品。 你可以采用反問的方式來判斷需求文檔是否清楚： – 文檔的結構 、 段落是否亂七八糟 ？ 上下文是否不連貫 ？ – 文檔的語句是否含糊其詞 、 羅里羅嗦 ？ – 看了半天是否還不明白需求究竟是什么 ？ .3 無二義性 ? “ 無二義性 ” 是指每個需求只有唯一的含義。 .2 清楚 ? 清楚的需求讓人易讀易懂 。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟 “ 想要什么 ”和 “ 不要什么 ” 。 需求確認 如何保證需求規(guī)格說明書的質量？ ? 正確性 ? 完備性 ? 易理解性 ? 一致性 ? 可行性 ? 健壯性 ? 易修改性 ? 易測試性和可修改性 ? 易追溯性 ? 兼容性 . 什么是好的需求規(guī)格說明書 .1 正確 ? 需求規(guī)格說明書應當正確地反映用戶的真實意圖， “ 正確 ” 是 《 產品需求規(guī)格說明書 》 最重要的屬性。毫不妥協(xié)或者輕易妥協(xié)都不是好辦法。然而當爭議變?yōu)闋幊硶r就壞事了， 爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。 ? 開評審會議時經常會發(fā)生爭議。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。 ? 需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。 需求評審的確乏味 ， 也比較費腦子 。 2. 產品面向的用戶群體 提示： (1) 描述本產品面向的用戶 (客戶、最終 用戶 )的特征； (2) 說明本產品將給他們帶來什么好處？特們選擇本產品的 可能 性有多大？ 3. 產品應當遵循的標準或規(guī)范 提示：闡述本產品應當遵循什么標準、規(guī)范或業(yè)務規(guī)則。 ? 前景文檔是用一般的語言定義系統(tǒng)特征的文檔 ? 軟件需求規(guī)格說明書是用更專業(yè)的術語定義系統(tǒng)特征的文檔。 ? 轉專業(yè)手續(xù)應在每學年開學前辦理 。 ? 學生轉專業(yè)由本人向所在系提出申請 ， 教務處審批 。 獲取數(shù)據 分析、處理 目標系統(tǒng)模型 需求獲取 系統(tǒng)分析員 從數(shù)據流和數(shù)據結構出發(fā)，找出系統(tǒng)各元素之間的聯(lián)系、接口特征及設計限制、能否滿足功能需求 需求獲取概述 需求獲取是通過各種途徑獲取用戶的需求信息（原始材料），產生 《 用戶需求說明書 》 。所以需求變更控制是需求工程的重要活動。 正因為市場在變化，才會產生更多商機，聰明的開發(fā)商才會有活干，有錢賺。 ?如果由于市場變化而導致產品需求發(fā)生變更，開發(fā)商大可不必為此煩惱，應當高興才對。毫無疑問，這種需求變更將使項目付出額外的代價。 4. 需求開發(fā)的主要困難與對策 用戶經常變更需求 ?需求變更通常會對項目的進度、人力資源、經費產生很大的影響，這是開發(fā)商非常畏懼的問題。 – 提高開發(fā)人員寫作能力的根本辦法就是讓他們多練習寫文檔，熟能生巧。 ? 開發(fā)人員寫作能力比較差，雖然在調查過程中已經獲得了不少需求信息，卻寫不出好的需求文檔來。其夫人甚為不解，問： “ 相公，你寫文章比我生小孩還難嗎？ ”書生長嘆一聲： “ 娘子你哪里知道我的難處??！你生小孩時肚子里有東西，可我寫文章時肚子里沒東西啊。 4. 需求開發(fā)的主要困難與對策 開發(fā)人員寫不好需求文檔 ? 需求調查工作不充分，獲取的需求信息太少或者太亂，以至于寫不成需求文檔?！? ? 不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。嗓門極大，在夜里雙眼能射出強光。這類錯誤連高智商的外星人都不能避免： – 有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。如果需求分析員誤解了需求，那會導致后續(xù)的不少開發(fā)人員將錯就錯、白干活。請您決定廣告牌的尺寸和放在哪條高速公路上，我立即派人去做。 ? 有時用戶會把開發(fā)人員的建議或答復給想歪了： – 有一個軟件開發(fā)人員滔滔不絕地向用戶講解在“信息高速公路上做廣告”的種種好處，用戶聽得津津有味。 ? 無論是什么原因導致用戶說不清楚需求，需求分析員必須設法搞清楚用戶真正的需求，這是需求分析員的職責，也是職業(yè)的挑戰(zhàn)。通常拿鞋子去試，試穿時感覺到舒服才會買鞋。 – 比如說買鞋子。這些機構的領導和辦公人員大多數(shù)不清楚網絡干什么用，就讓開發(fā)人員替他們設想需求吧，反正是花公家的錢。 – 例如開發(fā)方的營銷人員水平比較高，他能夠在用戶不清楚自己要什么的情況下引導用戶 “ 消費 ” 。 4. 需求開發(fā)的主要困難與對策 用戶說不清楚需求 ? 用戶說不清楚需求是普遍現(xiàn)象，這是讓開發(fā)人員頭痛的大問題。 – 3. 在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關的材料。 ? 用戶在需求工程中的 “ 義務 ” – 1. 以積極友善的態(tài)度與開發(fā)方人員交流、協(xié)作，盡可能地為開發(fā)方人員提供工作和生活上的便利。如果認為需求文檔不能準確地反映用戶真實的意愿，可以拒絕在需求文檔上簽字。 – 2. 有權要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。 如果條件允許的話 ， 開發(fā)方最好為用戶舉辦關于需求工程的培訓 ， 這樣的培訓將 使用戶明白需求的重要性以及忽視需求的危害性 ， 從而促使他們積極友善地參加需求工程中的各項活動 。 ? 開發(fā)方和用戶方在開展需求開發(fā)之前 ， 雙方協(xié)商并撰寫 “ 用戶在需求工程中的權利與義務 ” ， 即以協(xié)議的方式確定合作關系 。 ? 開發(fā)方與用戶的合作關系對需求開發(fā)而言是至關重要的 。 ? 需求分析員不是銷售人員 ， 他們不可能象銷售人員那樣通過某些手段籠絡住用戶就能成功 。 ? 對于一些競標項目 ， 在合同未簽訂之前的需求開發(fā)工作尤為困難 。我們付錢給你們，難道還要我伺候你們不成？我還要干自己的事情，別打擾我了。 ? 倘若用戶不能很好地配合需求分析員 ，