需求管理通常都會一開始就很快地踏入到資料面的細節部分，過早得面臨細節性的複雜，反而不容易的進行有組織的管理，而軟體本身是一個多變的管理與開發過程，所以若是以過去常見的以表單為主的開發模式，會讓人很難以全盤掌握住整個環節。
需求分類：(其實去年我就已經讀過&考過SCEA XD) - 一般會考慮使用已需求列表的方式來陳述
- 功能性 ( functional)- 通常都會是專注在問題領域內 , and skills ( ex: uml)，我們期望能有一個有效管理需求來源的方法，來順利的引導到後面的開發設計部分,隨著專案範疇越來越為廣大的時候，若還是用傳統的表單方式分類需求，會是個無窮的災難的開始。
- 非功能性( non-functional) - 多屬於系統層次的議題 ，ex: 效能、安全、穩定...
在HSDC所闡述分享的觀念中，比較傾向於先前討論過的I&I方式進行，採以looping角度不斷的走入SA, SD,Coding進行整個運作。
功能性需求的部分，一定都需要將企業需求給完整納入( Business Rules ) / User Interface / Features
在繪製Use Case時，系統範圍Boundary是由Architect 所定義而來的。
在討論系統需求時，以下這些項目要先搞清楚一下：
- 系統 - provides the services --> provides the API
- 模組 - Logical業務分類
- 資料庫 - Data Storage
- 表單 - Using for the presentation
其實在 系統或者資料庫都能寫一些程式來提供服務，但是在系統上寫的(oop ), 跟在資料庫上用store procedure( scripting)對於維護上有很大的差異，若能採用以OOP的角度來處理高度複雜的商務需求，則可以提高更好的維護產出。SP也因為可攜性不高，所以轉移時也有一定的困難度存在。
Use Case的分類角度，是從使用者的角度來開始進行，並用使用者的期望來做需求功能的分類，也許我們可以這麼說 UC 就是為了滿足"使用者的期望"而存在，舉例一下，假設我去柏克萊書局買書，我會經過 找書、放入購物籃、結帳的幾個過程，但是我們可能無法把這幾個過程單獨的當成獨立的UC，因為單一的過程無法完成"滿足使用者的期望"。
// 架構師要涵蓋三大類 需求 結構 實作 的技術面的掌握 //
再切分UC時，要能掌握一個原則，盡可能地將各個UC能平行切離，讓他們可以平行的被進行開發，也就是不牽涉到需求面"共用"的部分。
Use Case 的命名方式 - 動詞+名詞+編號
現今系統常見的登入需求，其實建議不需要把登入這件事納入UC，把這部分的資訊當成一些前置檢查條件即可。
在use case的陳述過程中，如果有很多個case 是很有可能是有其流程關係的，那不要把流程性的資訊寫在use case裡面，反而是將它留在activity diagram裡面再來整個納入。
做UC規劃時，往往都要先以交易為主的優先進行，當然有另一種的是以維護型的為主，而到底該怎麼挑選哪一種優先? 端看你的客戶stakeHolder所最關注的是哪個面向就從哪個先開始。
在設計UC的時候，可能會遇到重複的狀況，但先別急著把他們都給並再一起，對於這樣有可能衝突的東西的時候，先把它保留，等到後續實作設計階段再來排除這樣的問題。
ex: 訂購商品包含了商查詢商品資訊，而結帳商品也包含了查詢商品資訊，看起來名稱相同，但是可能查詢的細節內容不太一樣，所以可以先寫，後面在整合階段時在抽整結構分析, 實作階段 進行 extracting & refactoring 。
強烈建議，不要在一開始需求訪談階段就把共用性(這就是結構性)的議題放進來，這樣會讓你一開始就踏入了泥淖，很難快速處理你的商務需求。
表達系統內部結構的圖
- 靜態結構: 常見會描述field , members，也有點像是寫劇本，設定人物等等。(看整體 - Whole) (Class Diagram)
- 動態結構: 每一次的任務(use case)都不一樣，不同的任務就有不同的長相，也可以想像是戲劇的分鏡表。(看分項 - part) (Sequence , Comunication)
Class Diagram當中，基本上我們分為兩類，一個是強相關，一個是弱相關
怎麼區分強弱? 其實就是說當你有個物件需要另一個物件提供服務，而其實幾乎有8~9成的物件生命週期中都會需要他服務，這種我們可以簡單稱為強相關，反之則為弱相關。
強相關 : 只要是實線關聯的 都是強相關 ( assocation )
弱相關 : 虛線類型的都可以稱為是弱相關 ( dependency )
若有whole-part 的 association / aggregation ，在實際運作時，client 面對的都是從whole 去操作part ，所以part 的部分並非是個單獨獨立可提供服務的存在實體。
在畫class diagram時，若在association的線條上有方向性的話( navigation) , 是表示僅有一方可知另一方的細節，反之則不能取得細節，所以在繪製時一般會建議如果不肯定的話就只先提供 undirectional line
Q1 : 類別圖繪製產出的時間點在?
A1 : 在訪談初步完成時就該先產出了，越早暴露出Class Diagram 對軟體開發是越有保障的
Q2 : 循序圖什麼時候該畫，還有為何要畫循序圖?
A2 : 目的是要描述物件之間的互動行為與關係，同時也是要拿來merge Use Case & Class Diagram，每個SD都會對應到一個UC，
以及闡明描述其所使用的靜態結構 Class Diagram，但不要畫到太仔細，這個目的只是要驗證說我的Class Diagram能支援符合
應用整個UC。同時，SD基本上是個物件的合作圖，所以裡面的Element每個都是物件。 ( instanceName : className)
發送訊息端能發送訊息，是因為後繼的物件本身有提供那個功能才能發送訊息，譬如: 人填寫請假資訊，是因為 class 請假資訊有
method 填寫請假資訊() 這個api。
而訊息傳遞時，通常都匯給個名字，很正常，但是若有遇到看到像這樣的 " //送審 "，則是表示這是還不確定到底是不是真的叫做
送審，所以就先用//來暫時標記其為可變動的訊息名稱。
同時也建議使用註解區塊，把它放進SD裡面，這註解區塊放的就是Use Case narrative。
繪製SD的時候就要特別檢查一下Class Diagram的關係描述 是否跟你畫出來的SD內容是否一致，藉此能夠來檢視其正確性。
電子化採購管理系統案例
對於一個iteration 的查核點應該盡量訂在一周內完成一次的iteration，若遇到一周做不完哩? 沒關係，起碼我們可以知道只是延宕了一周，並且我們可以會知道到底在SA , SD , PG , Testing 階段到底是哪個環節出了問題。
來看看怎麼樣進行 RA ( Request Acquisition) - 需求獲得 !
至於需求來源到底該怎麼蒐集? 如果是產品類的消費性產品的，那需求就必須是被歸類在 function feature裡面，統計歸納使用者群希望我們可以提供那些功能。而另一種則是專案類型性質的看法，需求來源其實就是源自於企業流程，要能服務客戶一連串企業內部的活動。
使用案例原則上是可以分層級的，從企業層級到資訊系統層級兩層面，本次課程主要著重於資訊系統層級面。
ex: 客戶租片，是屬於企業層級，而櫃員登陸租片資訊則為資訊系統層級。
基於這樣的因素，推薦使用 Erikson-Penker 企業擴充模型火箭圖方式來描述，以目標來切分process進行討論，同時目標也必須是實質上具有業務意義的目標。
補充說明一下：圖形解釋
- 平行四邊形 - 一般資訊
- 四方型 - Object instance
- 缺角四邊形 - 事件
- 被包起來的參與者 - business worker
在進行需求蒐集時，我們會需要紀錄整個需求流程，但依定會有很多branch decision的出現，這樣很容易把必要的關鍵核心給忽略，重心都偏掉了，建議在需求蒐整時期，先以核心主力部分先進行，再找其他時間點去補上branching decision。
需求彙整這裡有個很重要的分水嶺，分別是企業流程以及使用者需求，我們通常都必須先了解了企業流程以後，才能再去往使用需求往下發展，比較建議的進行方式，就是先從火箭圖來彙整企業目標流程，並將每個目標所需要進行的流程用Activity來進行描繪，一旦當這樣的環節都清楚了，那我們才會往下往使用需求往下走，這兩大類的差異，其實也就是在需求訪談過程中，我們所說的兩大類User 所關切的 -- StakeHolder & Operator。
沒有留言:
張貼留言