Software Requirements
1.通常,需求必須要思考是否可以被驗收 ( ref V Model )
2.當時程上或人力上如果有所限制時,通常會考量需求本身的優先順序,因此,在訂定需求的時候,優先順序就必須要先被定義出來
3.系統分Feature & Nonfeature功能
- Feature 通常是可以很容易被描述且理解成一個操作行為
- NonFeature通常形容的事比較抽象,像是軟體品質,或者是效能,一樣可以被定義甚至檢驗,但是通常可能不一定是個很明確的功能
6.在Process Model之中,人占了最大因素,大致可以分為Users、Customers、Market Analysts、Regulators、Software Engineers 、Stake Holder , 大部分的人都必須要跨領域了解,方便專案的進行。如果在溝通之中,發生了利益衝突的狀況,特別是需求可能影響別的專案或既有系統的,這時,就必需要花額外時間成本去協調或設計相容。
7.專案的過程中,由於時間、人力的限制,這時候就會依據需求的優先順序,進行搓合的過程,協調是否分批上版,抑或者是延緩到第二期開發。通常,影響維運的主流程會優先考量,其次才是附加功能。進一步思考,雖然有些功能會延後到第二期開發,第一期設計的時候往往需要考量延展性,也因此,設計方面還需要考慮為了設計研展性所增加的成本。
8.Process的過程中,可以定義許多的查核點,來檢視這過程是否有改善的空間,包含開發效率、與時程之間的落差、 滿意度調查、軟體測是涵蓋狀況。
9.在構思需求的時候,必須要從本次專案目的、Stake Holder期望、產業的專業知識為出發點、商業邏輯、營運的環境、對於組織的相依姓。但是有些時候,並不是這麼容易被萃取出來,這時候可以透過Interview、Scenarios、Prototypes、Facilitated meetings ( Maybe workshop?)、User Story,將需求從這些活動中收斂出來,接著過濾、篩選,不可被文件化、無法被實作及超出架構範圍,都必須要重新確認,同時,這些是可以進一步被系統化,透過像是UML這樣的語言,協助轉換到實作層級,這過程也可以確認這需求是否可以被驗收、有衡量的指標、可以被預估成本。
10.Prototyping 雖然可以提早發現一些需求狀況,但是這塊的成本通常被忽視。就如同先前的比稿事件,或客戶端的提案簡報,如果需用Protypeing的概念去呈現實作可行性,成本就必需要被思考。但是一般預算的規劃,這塊常被低估或甚至沒含蓋到,客戶端不一定認為這個是專案範圍,而認定這只是能力展現。
User Story from WIKI
V Model
UX SDLC
SDLC