1樓:匿名使用者
是二級access上的題 謝謝作答人先啦 結構化方法。面向過程而非物件導向。
系統流程圖是放在可行性研究還是需求分析裡
2樓:匿名使用者
是這樣的。
可行性分析。在現實中其實沒那麼學術性。如果你按專照書本理論弄的話,你會屬發現現實中根本就是行不通。或者多此一舉。
很簡單,如果讓你寫可行性報告的一方真正的意圖是希望這個軟體做起來,那你就想盡一切辦法說這個事應該做、有好處、完全可行。反之,則千方百計的否定它。就是這麼回事。
至於寫法,寫哪些,無外乎就是需求、客觀現實、影響性、技術成熟度、投資情況、可用情況、維護性等一系列方面。
如何做需求分析
3樓:匿名使用者
一、 我們應當如何做需求分析
需求分析不是一蹴而就的,它應當貫穿整個開發周期,不斷的分析確認的過程。這就是敏捷開發倡導的需求反饋。敏捷開發認為,需求分析階段不可能解決所有的需求問題,因此在設計、開發、測試,直到最終交付客戶,這整個過程都應當不停地用開發的成果與客戶交流,及時獲得反饋。
只有這樣才能及時糾正需求理解的偏差,保證專案的成功。
二、我們應當怎樣做需求調研
1.初識。
我們對客戶提出的需求進行深入理解以後,運用我們專業知識,提出比客戶的原始需求更加合理、可操作的解決方案,讓客戶感覺你說的正是他們想要的。如果能夠這樣,客戶不僅能夠欣然接收你提出的方案,而且會感覺你非常專業,你在客戶心目中的形象也會無形中提高,使你有更多的機會提出有利於開發的可行方案,降低開發的風險。這毫無疑問會形成乙個良性迴圈,但要做到這一點並不容易,毫無疑問,在與客戶接觸初期的表現起到了極其關鍵的作用。
(1)高層領導關心的是巨集觀的目標,因此軟體研發目標、巨集觀統計報表、決策支援功能,我們應該怎樣做需求分析,應當與高層領導談。
(2)中層領導關心的是具體的效益,即軟體給各個部門資訊化管理方面帶來的效益,因此,中層領導是各項業務流程、功能模組的需求決策者。他們關心功能的定義、業務流轉的銜接、查詢報表的設計,但不太關心一些具體的操作,以及一些具體業務流程的細節。
(3)基層人員是每一項業務流程的操作者,也是軟體今後真正的使用者。他們是真正了解你所要開發的軟體的業務需求的領域專家,是你進行需求調研的重點物件。但是,基層人員往往受到自身視野的侷限,可能只清楚自己工作涉及的十分狹小的乙個範圍,因此我們需要努力尋找那些業務涉及面廣,經驗豐富,又有一定大局觀的真正的專家。
另外 ,他們就是軟體今後真正的使用者,讓他們參加,會讓他們成為今後軟體推行的忠實支持者,對其他操作人員的指導者,益處多多。而他們關心的則是每項操作的細節。
俗話說:萬事開頭難。如果你在專案開始的時候總感覺千頭萬緒不知如何著手,在這裡我給大家的三點建議:
1)樹立良好的職業威信;
2)進行詳細角色分析,將與會各方代表對號入座;
3)從巨集觀上制訂目標與方案。隨後的工作,就是與各方**建立聯絡,逐一拜訪他們,將需求調研工作一步一步進行下去。
2.拜訪。
需求調研不是一蹴而就的事情,是一件持續數月甚至數年的工作(假如專案還有後期維護) 。在這漫長的時間裡,我們需要依靠客戶這個群體的幫助,一步一步掌握真實可靠的業務需求 。不僅如此,技術這東西總有不如意甚至實現不了的地方,我們需要客戶的理解與包容,這都需要有良好的客戶關係。
儘管如此,我們也不能總是期望客戶中的所有人都能與我們合作,很多專案都不可避免地存在阻礙專案開展的人。
3.研討會。
(1)由於業務人員自身的侷限 ,不可能對所有業務領域的細節全面掌握,往往總是有自己熟悉的部分,也有自己不熟悉的部
分。劃分業務組,可以讓業務人員分別在自己最熟悉的業務範圍內參與討論,可以有效提高業務討論的質量;
(2)集中式的業務研討形式和分布式的業務研討形式;
(3)有效抑制個性化差異、分模組組織專項研討會。
4.業務研討
在需求分析過程中,客戶存在的最大問題就是提不出正確的需求,這表現為幾種形式:
(1)由於對軟體不了解,客戶提不出需求,不知道軟體最終會做成什麼樣子。這類客戶在需求討論過程中,往往只能描述目前自己手工管理的方式是怎樣的,不知道計算機會怎樣管理。
(2)能提出一些業務需求,但當軟體做出來擺在自己面前時,需求就變了。這類客戶,他們能熟練使用電腦,對資訊化管理是清楚的。他們提出的業務需求從整體上應當是**不離十的 。
但是,由於沒有實物,在軟體中的一些具體操作並沒有完全想清楚。
(3)能非常詳細地提出業務需求,甚至有時候該怎麼做的提出來了。這類客戶,參與過很多軟體資訊化建設,甚至有些還是軟體開發的半專業人士。但是他們提出的業務需求過於具體 ,甚至怎樣實現都說出來了,但這些有時候不是最佳設計方案、可能在技術上難於實現,甚至有些就是過於理想化而不可實現。
解決辦法:
業務領域分析:客戶現有的業務流程是什麼樣的,都有些什麼操作?客戶在業務中都有些什麼事物,什麼專用名詞,都是怎樣定義的,相互之間的關係是什麼?
客戶在每一項操作中的目的是什麼,為什麼要這樣做,他們製作的手工報表都說明了什麼問
題?(1)我們做需求分析,眼界不能僅僅停留在軟體本身,應當更開闊一些,應當擴充套件到跟這個業務有關的那些領域知識中。
(2)在客戶提出的所有原始需求中那些與業務實現有關的需求都是無效的需求,它們僅僅只能作為我們的乙個參考。
(3)還有一些是技術難於實現或者根本就無法實現的需求,我們應當耐心地說服和引導客戶,並給他提出乙個更加合理的方案。
(4)需求分析不是一種簡單的你說我記的收集活動,而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發,才能保證需求的正確與變更的可控。
5.迭代
在第一次的需求分析階段,我們在一段時期內需要與客戶進行反覆地討論,這個過程往往是這樣乙個反覆迴圈的過程:需求捕獲->需求整理->需求驗證->再需求捕獲······
(1)需求捕獲:就是我們與客戶在一起開研討會,討論需求的活動,客戶可能會描述他們的業務流程,這時我們在紙上繪製簡單的流程草圖,及時地記錄下來;客戶在描述業務的同時,可能會反覆提到一些業務名詞,詳細詢問這些名詞的含義,以及它們與其它名詞的關係,用類圖或者物件圖繪製簡單的草圖;客戶在描述業務的同時,還會提出今後的軟體希望實現的功能,如能夠展示某個報表、能夠匯出檔案,以需求列表的形式記錄下來。乙個功能,在需求列表中會有多個需求,而每個需求應當能夠用 1、2 句話,在 20 個字以內就可以描述清楚 。
需求列表是客戶提出的最最原始的需求,他不摻雜任何分析設計,是我們的每項功能必須實現的內容。
(2)需求整理:就是在需求研討會後,需求分析人員對研討內容的分析和整理的過程。首先,需求分析人員應當通過用例模型,劃分整個系統的功能模組,以及各個模組的業務流程。
用例模型分析是乙個由粗到細的過程,這樣乙個過程也是符合人類認識世界的思維習慣的乙個過程。最先,我們應當對整個系統繪製用例圖,設計用例場景,並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然,在整體用例分析的同時,我們還應當進行乙個整體的角色分析,繪製乙個角色分析圖,進行乙個流程分析,繪製乙個流程分析圖(可以是傳統的流程圖、uml 中的行**,甚至乙個簡單的示意圖,等等),再在整體用例圖的基礎上,依次對每個用例繪製用例圖。
每個用例圖中,會更細緻地劃分出多個用例,並依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化,直到我們認為需求已經描述清楚為止。
(3)領域模型 :是對使用者業務領域中相關事物、相互關係、相互行為操作的描述,它是以物件圖和類圖的形式表達的。需求人員對領域模型的分析,對業務理解的深度,對日後軟體的設計,以及軟體的功能擴充套件、公升級演化,都起到了至關重要的作用。
(4)需求驗證:需求驗證工作應當貫穿整個研發週期,並且在不同時期表現出不同的形式。首先,在需求分析階段,需求驗證工作表現為對需求理解是否正確的資訊反饋。
需求分析人員與客戶再次坐在一起,一項一項描述我們對需求的整理和理解,客戶則時不時地對一些問題進行糾正,或者更加深入地加以描述。我們則認真地記錄,回來整理,並等待下一次的驗證。在需求分析後期,我們還可以製作一些簡單的原型,更加形象地描述我們對需求的理解,會使我們與客戶的溝通更加順暢。
隨後的設計開發階段,我
們則應當以迭代開發的形式進行。每開發完乙個迭代週期,將開發的成果與客戶反饋。這樣做的結果是,客戶可以及時地提出我們對需求理解的偏差,或者及時提出對我們設計不滿意的地方,使我們存在的問題得到及時地發現與解決。
問題及時的解決,使我們修復問題的代價得以降至最小。
6.需求捕獲
經過深入分析我們會發現,從客戶嘴中說出來的需求,只是整個軟體需求中的冰山一角,還有兩類需求需要我們自己去挖掘:客戶嘴中沒有說出來的需求 ,和客戶壓根兒就沒有想到的需求
(1)什麼是客戶嘴中沒有說出來的需求:並不是客戶故意賣弄官子不願說出來,而是在客戶所在業務領域已經約定俗稱,在他們看來已經是天經地義,根本就不用說出來的業務規則。然而 ,作為剛剛涉足該領域的需求人員,他們是不了解這些規則的。
如果採用被動的方式去僅僅記錄客戶說出來的需求,毫無疑問會遺失這部分需求,這就是為什麼直到專案後期,軟體被研發出來即將交付使用,客戶才提出說這不是我想要的軟體,並提出大量變更需求的原因。要求我們在需求分析的整個過程,不斷進行業務領域知識的學習。在我做需求訪談的初期,我往往不是跟客戶談需求,而是先跟客戶談業務。
你們是怎樣操作的?都經過些什麼流程?誰來完成這些操作的?
為什麼這樣操作?注意,在所有這些問題中,最後乙個問題是最重要的。客戶業務領域中的所有操作、所有流程都是有它存在的意義的,它體現了其內部的原因與作用。
多問為什麼,可以讓我們深入地理解這些領域知識 。站在客戶的視角去思考問題,進而深入地理解客戶為什麼要提出他們的那些業務需求
(2)另一種就是客戶壓根兒沒有想到的需求:在需求分析階段,雖然客戶壓根兒沒有想到,但需求分析人員是軟體研發領域的專業人員,他們應當在深入理解業務領域與需求的基礎上,通過分析提前發現這些需求。作為需求分析人員,他們應當站在客戶的角度去思考,我們的軟體應當設計成什麼樣子,每個需求的真實意圖是什麼。
站在這個基礎上,再運用專業知識去整理、分析與設計。我前面談到,客戶描述的最原始的需求是編寫在需求列表中的,而經過需求分析人員的整理、分析與設計,經過用例分析、領域建模,最終形成產品需求說明書(或稱為產品規格說明書)。先在一些非正式的場合單獨跟客戶聊,產生第一手資料,最後將這些需求在比較正式的場合,如各部門參加的業務討論會、有使用者代表參加的
為什麼做培訓需求調查如何進行培訓需求分析？
因為有針對性的培訓才是最有效的，而培訓需求調查可以幫助你更好的找準培訓的方向 為了確定培訓的目的，培訓要達到的效果。必須在培訓之前進行需求調查。分享 有效需求的七個問題 1.組織要實現怎樣的發展？包括組織戰略目標 人員整體素質分析 2.組織目前是怎麼樣的？如組織資源分析 環境分析 人員整體素質分析 ...
如何做招聘需求分析企業如何進行員工招聘需求分析
招聘需求分析包括三個方面 崗位分析，任職資格分析和招聘有效性的分析 崗位分析主要是通過對崗位的職責，崗位的工作環境，崗位文化環境進行分析，以崗位為基礎確定需要那些人。崗位文化分析 指的是崗位的價值觀，工作風格，工作面貌等 招聘有效性的分析包括 培養成本分析，易於培養的，不考察或者不做重點考察。不易於...
裡做的流程圖怎樣更改文字，word裡做的流程圖，怎樣更改文字？
直接在流程圖的文字框裡修改文字即可。是自選圖形的話直接右鍵，有新增文字的選項，文字框的話直接改，要是人家是 形式改變的，那你只能把 另存後改 建議可以 在office中的baivisio中du畫流程圖zhi 然後複製到word中 即使在word中發現錯誤dao 也可以雙擊流回程圖 進入visio自由...