數據庫設計貫通

—需求工程部分數據庫設計專業人員的要求計算機基礎知識軟件工程知識程序設計的方法和技巧數據庫的基本知識數據庫設計技術應用領域的知識數據庫設計的基本步驟需求分析數據和處理概念結構設計概念模型獨立于DBMS邏輯結構設計轉換概念模型到DBMS所支持的數據模型并優化物理結構設計物理結構的選擇（存儲結構和存取方法）數據庫實施建立、編制、調試數據庫運行和維護運行、評價、調整、修正數據庫設計中的角色系統分析人員數據庫設計人員應用開發人員數據庫管理員用戶代表一、需求工程1.概念寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。待開發軟件系統的功能、非功能、外部接口、設計約束和其它要求通過對應用問題及其環境的理解和分析，準確、一致和完全地刻劃用戶需求，形成軟件需求規格說明書(SRS:SoftwareRequirementSpecification)FrederickBrooks在他1986年經典文章“NoSilverBullet”中闡述了需求的重要性：開發軟件系統最困難的部分就是準確說明開發什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統的接口。此工作一旦做錯，將會給系統帶來極大的損害，并且以后對它修改也極為困難。

3.需求工程基本概念把所有與需求直接相關的活動通稱為需求工程需求工程中的活動可分為兩大類，一類屬于需求開發，另一類屬于需求管理3.需求工程基本概念需求工程的結構圖3.需求工程基本概念需求管理過程域

需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。

需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。4.需求開發的主要困難與對策4.1應用領域知識技能問題

4.2需求分析人員的態度問題被動地對待需求開發每當遇到麻煩、挫折時，他們會發牢騷，找用戶毛病能少干則少干，能偷懶則偷懶如果用戶說不清楚需求，或者變更需求，這類問題是用戶產生的，應當由他們自己負責4.3雙方合作關系開發方的角度客戶的角度客戶的想法競標項目解決需求開發之前，雙方協商并明確用戶在需求工程中的權利與義務，以協議的方式確定合作關系開發方最好為用戶舉辦關于需求工程的培訓，這樣的培訓將使用戶明白需求的重要性以及忽視需求的危害性，從而促使他們積極友善地參加需求工程中的各項活動用戶在需求工程中的“義務”

1.以積極友善的態度與開發方人員交流、協作，盡可能地為開發方人員提供工作和生活上的便利。2.樂意接受需求分析員的采訪，在不泄漏機密的前提下盡可能地回答需求分析員的問題。3.在不泄漏機密的前提下，盡可能地向需求分析員提供與需求相關的材料。4.與需求分析員共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿4.需求開發的主要困難與對策4.3用戶說不清楚需求真的不知道需求是什么，或者對需求只有朦朧的感覺，當然說不清楚需求有些用戶雖然心里明白想要什么，但卻說不清楚需求*需求分析員絕不能以用戶說不清楚需求為借口而草率地對待需求開發4.需求開發的主要困難與對策4.4雙方誤解需求不論是復雜的項目還是簡單的項目，需求分析員和用戶都有可能誤解需求。所以需求確認工作（屬于需求管理）必不可少4.需求開發的主要困難與對策4.5開發人員寫不好需求文檔原因需求調查工作不充分，獲取的需求信息少而且混亂*開發人員寫作能力比較差缺乏良好的需求規格說明編寫模板4.需求開發的主要困難與對策4.6用戶經常變更需求需求開發本身的問題-沒有弄清需求或錯誤分析了需求如果由于市場變化而導致產品需求發生變更需求變更控制是需求工程的重要活動5.開展需求調查5.1準備調查起草需求調查問題表確定調查的方式5.2執行調查與用戶交談，向用戶提問題。向用戶群體發調查問卷。參觀用戶的工作流程，觀察用戶的操作。與同行、專家交談，聽取他們的意見。分析已經存在的同類軟件產品，提取需求。從行業標準、規則中提取需求。從Internet上搜查相關資料。6.進行需求分析問答分析方法提問并解答。如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”問答分析最重要的問題是：“是什么”和“為什么”其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現嗎？需求可驗證嗎？需求的優先級確定了嗎？6.進行需求分析建模分析法一圖低千言需求建模就是指用圖形符號和語義來表示、刻畫需求建模分析方法主要有兩大類：“結構化分析法”“面向對象分析法”8.什么是好的需求規格說明書Casestudy：你正在設計系統其中的一個特性，發現了需求的一些問題：你可以用多種不同的方式解釋需求15；需求9的說明正好與需求21相反，你因該相信哪一個？需求24非常含糊，你不明白它的意思；你不得不花上一個小時與2位開發人員討論需求30，只因為你們對其各有各的理解；并且，唯一能夠澄清這些問題的客戶沒有給你們答復；你被迫破解眾多需求的含義，并且你能預料到，如果你錯了，要做大量的重復工作；8.什么是好的需求規格說明書8.1正確

每個需求必須精確描述要交付的功能需求評審時，必須要有用戶（或用戶代表參與）用戶方（發包方）提供一個需求聯絡員，負責為開發方（承包方）提供全程的需求開發支持8.什么是好的需求規格說明書8.2清楚需求的一個讀者應只能從其得到唯一的解釋說明同樣，一個需求的多個讀者也應達成共識自然語言極易導致含糊，要避免使用一些對于SRS作者很清楚但對于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等每項需要都應簡潔，簡單，直觀的采用用戶熟知的語言，不要采用計算機術語檢查需求是否清楚的有效方式根據需求寫測試用例8.什么是好的需求規格說明書8.3無二義性8.4一致8.5必要跟蹤每個需求回溯到出處，如用例，需求的最初描述，其他用戶的意見。如果你不能標識出處，可能需求沒有真正的必須8.什么是好的需求規格說明書8.6完備不應該遺漏要求和必需的信息8.7可實現看你是否能夠做出測試計劃，設計出測試用在需求分析階段應該有一個開發人員參與8.8可驗證8.什么是好的需求規格說明書8.9確定優先級如果所有的需求同等重要，那么在開發中的預算削減，計劃超時或組員離開導致新的需求及變更時，項目經理將不能起到作用例：高優先權：必須體現在下一個產品版本中中優先權：表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中低優先權表明有它很好，但如果沒有充足的時間或資源，它可以被放棄8.什么是好的需求規格說明書8.10闡述“做什么”而不是“怎么做”避免在需求說明書中嵌入設計把軟件劃分成若干模塊給每個模塊分配功能描述模塊間的信息流程或者控制流程選擇數據結構9例例1．“產品應在不少于每60秒的正常周期內提供狀態信息”不完備：狀態信息是什么，如何顯示給用戶不清楚：我們在談論產品的哪部分？二義：是消息間隔不應超過60秒，還是在60秒內提供信息？重寫需求的一種方法：1、狀態信息

1.1后臺任務管理器因該以誤差上下不超過10秒的60秒間隔，在用戶界面的指定位置顯示狀態信息1.2如果后臺進程處理正常，那么應該顯示任務已完成的百分數/比

1.3任務完成時，應顯示相關的信息

1.4后臺任務出錯應該顯示錯誤信息為了分別測試和追蹤，將需求分成了多個需求如果將幾個需求串接在一節中，在構造和測試時就很容易漏掉一個9例例2．“產品應瞬間在顯示和隱藏不可打印字符間切換”“瞬間”是什么樣的時間概念？它的不完備性表現在沒有聲明觸發狀態切換的條件。在文檔中改變顯示的范圍是多大：選中的文本，整個的文檔，或其他的？這也是個不清楚的問題不可打印字符和隱藏字符一樣嗎？或者是一些屬性標志或一些控制字符？問題的后果，就是需求的不可驗證9例重寫需求：“用戶能夠在一個由特定觸發條件激活處于編輯的文檔中在顯示和隱藏所有HTML標記間切換”現在就很清楚，不可打印字符是HTML標記由于沒有定義觸發條件，需求對設計沒有約束力。只有設計人員選定了觸發條件后，才能編寫測試驗證觸發的正確操作9例例3．“HTML分析器可以產生HTML標記錯誤報告，幫助HTML入門者快速解決錯誤”單詞“快速”使其模糊沒有加進錯誤報告的定義也使其不完備怎么驗證這個需求？找一個自稱為HTML的入門者，看看能不能根據錯誤報告快速解決錯誤？9例重寫：“HTML分析器可以產生一個錯誤報告，錯誤報告包含有在被分析文件中出錯的HTML文本和行號以及錯誤的描述。如果沒有錯誤，就不會產生錯誤報告”現在我們知道了，什么會被加到出錯報告中，但是出錯報告是個什么樣子，則留由設計人員決定我們還指定了一個例外：如果沒有發現錯誤，不產生錯誤報告9例例4．“如果可能，主管號碼應通過聯機校驗，而不是通過全體主管號碼列表校驗”什么是“如果可能”：如果技術上可行？如果主全體主管號碼列表可以聯機獲得？例5.該軟件界面友好，操作方便例6.該軟件能防止黑客入侵。如果入侵發生，仍能夠保證數據的安全沒有高質量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么軟件需求說明書的參考模板軟件需求規格說明書的一種參考模板2023/1/1545全部功能需求+四種類型的接口要求+其他需求功能需求外部接口需求性能需求設計約束屬性其他需求2023/1/1546四種接口需求和功能需求放在一起描述+其他需求功能需求1.1功能需求1 1.1.1規格說明

1.1.2外部接口需求1.2功能需求2性能需求設計約束屬性其他需求2023/1/1547功能需求的全部子文檔名稱放在一起首先說明，+其他需求功能需求1.1功能需求1 1.1.1引言

1.1.2輸入

1.1.3加工

1.1.4輸出

1.1.5性能需求

1.1.6設計約束

1.1.7屬性

1.1.8其他需求1.2功能需求2外部接口需求2.1用戶接口2.2硬件接口2.3軟件接口2.4通信接口2023/1/1548接口需求和其余的需求作為每一個功能需求的附屬部分來說明功能需求11.1引言1.2輸入1.3加工1.4輸出1.5外部接口需求1.6性能需求1.7設計約束1.8屬性1.9其他需求功能需求2…10.關于軟件的非功能需求架構性的非功能需求適應性體系結構是否適合于軟件的“功能性需求”和“非功能性需求”穩定性可擴展可擴展性是指軟件擴展新功能的容易程度。可擴展性越好，表示軟件適應“變化”的能力越強可復用復用的有利于提高產品的質量、提高生產率和降低成本10.關于軟件的非功能需求健壯性健壯性有兩層含義：一是容錯能力，二是恢復能力速度安全性10.關于軟件的非功能需求用戶界面易用性的界面原則有8個：用戶界面適合于軟件的功能容易理解風格一致及時反饋信息出錯處理適應各種用戶國際化個性化最短路徑，最少操作(操作的最高效率)高美觀程度的原則有：合理的布局和諧的色彩10.關于軟件的非功能需求并發性可靠性可靠性是指在一定的環境下，給定的時間內系統不發生故障的概率兼容性易用性11.需求管理-確認、跟蹤和變更控制11.1需求確認需求確認是指開發方和客戶方共同對《產品需求規格說明書》進行評審，雙方對需求達成共識后作出承諾需求確認包含兩個重要工作：“需求評審”和“需求承諾”需求評審：各方（用戶，需求分析人員、設計人員、專家）共同參與評審工作需求評審的內容和標準（參見“什么是好的需求說明書”）需求承諾