答: 按照科薩爾的模型, 需求確定分為5個層次, 第一部分是內部/外部刺激. 類似信息系統的來源--問題, 機會和命令. 通常只會影響到第二部分的商業目標.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     19.什么情況下, PIECES模型比需求模型更為實用?
     答: 在擁有精確完整的商業模型, 任務陳述或者目的陳述的時候科薩爾模型占有優勢, 反之PIECES模型占優勢.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     20.說出并簡述科德對問題域需求的搜集和建模的面向對象方法的四大活動
     答: 是
         1) 確定信息系統的目的和特點
         2) 確定對象和模式
         3) 建立對象責任
         4) 設計系統的動態場景

     → → → → → → → → → → → → → → → → → → → → → → → → 
     21.說出并簡述科德對問題域需求的搜集和建模的面向對象方法的四大組成部分
     答: 是
         1) 問題域
         2) 人機交互
         3) 數據管理
         4) 系統交互

     → → → → → → → → → → → → → → → → → → → → → → → → 
     22.搜集需求的全局, 個人和團體方法各是什么? 這些方法存在的問題是什么?
     答: 具體方法描述如下:
         1) 全局
            從歷史和橫向觀點進行調查的過程: 檢查現有及以前的文檔, 調查其他公司的類似工作, 參觀類似系統
         2) 個人
            從微觀角度的調查過程: 使用采訪, 觀察, 問卷/調查, 原型測試等方法進行
         3) 團體
            使用群件手段 -- 原型設計, 快速分析, 聯合開發(JAD), 頭腦風暴, 電子聯合開發(EJAD)等團隊討論手段

         這些方法存在地問題如下:
         1) 全局
            有利于系統分析員熟悉新系統的情況, 了解最起碼的系統需求. 問題在于需求確定過程不但是一個認知的過程也是一個創造性過程, 同時同類系統的需求也不是一成不變得, 而且不能單方面只顧及系統分析員一方而忽略了和用戶及其開發小組成員的交流; 同時也要考慮到諸如認識程度等其他因素的干擾.
         2) 個人
            有利于確定用戶的真正需求. 問題在于著重點的時候不能忽視面. 而且耗時過長.
         3) 團隊
            有利于提高效率, 增強凝聚力, 改善和用戶的關系, 是綜合討論結果的自然方法; 對于不善于交流, 無法解決沖突, 包含無關人員的項目團隊是一場災難. 同時, 系統分析員需要檢查討論清單的可行性, 并且根據用戶可見性和技術可行性把清單上的條目分為必要的和有用的兩類. 任何改動都應該及時反饋給用戶, 因為團隊討論的結果是用戶希望的基礎

         上述三個方法的基本特點在于:
         1) 必須向用戶反饋求得確認
         2) 需要上下文無關的背景內容
         3) 需要良好的溝通技巧

     → → → → → → → → → → → → → → → → → → → → → → → → 
     23.在需求確定過程中最應該牢記得是什么?
     答: 我認為應該是溝通, 不管使用何種方法, 最終必須求得用戶認同, 同時需要隨時反饋修改狀況, 使得用戶沒有感覺自己在設計開發階段是遠離系統的.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     24. 什么是建立原型? 在需求確定過程中有什么作用?
     答: 建立原型就是由個人或者團體完成一個代表預測基本功能的模擬系統, 來考察系統情況, 收集用戶反映. 作用在于, "用戶知道看到不想要的東西, 才知道自己需要什么". 所以在需求確定階段建立原型的價值就是消除系統不受歡迎的功能, 確定系統需要的功能.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     25. 其他團隊層次的技巧是什么? 怎樣運用這些技巧改善系統?
     答: 包括快速分析技巧和JAD, 團隊頭腦風暴, EJAD和團隊系統軟件 ==> 群件. 
         集中起來就是兩大主流:
         1) 團隊討論
            發揮每一個人的主觀能動性, 搜集盡可能多的想法, 甚至是上下文無關的背景內容; 通過綜合分析得到必要以及非必要的需求
         2) 原型設計
            原型根據其形象性和可操作性的特點, 可以以"實戰"的角度審視整個系統, 便于用戶確認需求和發現潛在的系統問題.
     

     → → → → → → → → → → → → → → → → → → → → → → → → 
     26. 舉例說明需求確定階段團隊層次的交互怎樣可能導致失敗?
     答: 首先我們審視團隊方式的優勢:
         1) 增強凝聚力
         2) 改善用戶交流
         3) 集中處理個人意見

         由此可見, 這是事物的正面, 這些都是基于交流順暢的前提, 否則就會走向事物的反面:
         1) 如果不能很好的協調團隊, 調整團隊對于不同見解的統一認識, 反而會降低團結性
         2) 如果不能很好的同用戶交流, 用戶反而無法將自己的需求正確反映到系統分析團隊
         3) 如果無法正確分析不同意見, 就無法保證用戶可見性和技術可行性

     → → → → → → → → → → → → → → → → → → → → → → → → 
     27. 描述需求確定階段團隊討論的步驟?
     答: 其實這是一個反復過程, 就是從討論開始, 結合原型設計進行逐步什么和有目標的討論; 以無法得到進一步想法為限.

     → → → → → → → → → → → → → → → → → → → → → → → → 
     28. 不管采用何種搜集方法, 需求確定最核心的三個一般因素是什么?
     答: 用戶認同, 背景輔助內容, 良好的溝通

     → → → → → → → → → → → → → → → → → → → → → → → → 
     29. 需求確定的主要目的是什么?
     答: 確定信息系統的真正需求和功能描述

     → → → → → → → → → → → → → → → → → → → → → → → → 
     30. 討論導致需求二義性的問題, 怎樣減輕這些問題?
     答: 主要有三個來源:
         1) 遺漏的需求
            減少一些必要因素的考慮
         2) 模棱兩可的措辭
            要求用詞明確
         3) 新加入的成分
            不要擅自添加功能而不向用戶反饋

     → → → → → → → → → → → → → → → → → → → → → → → → 
     31. 在需求確定過程中, 為什么改正錯誤和缺陷很重要?
     答: 因為發現越早, 投入的財力和物力相對越少.