[答疑]從欄位列表談"意念式"和"意淫式"需求

jeri 2019-6-6 9:55

在欄位列表裡定義這種格式，是不是把設計環節提前引入了？

UMLChina潘加宇

把自己設想的資料庫設計往需求里一扔。這種問題很常見。我歸納為"意念式"和"意淫式"需求。

不放這樣一個東西到需求里，會怎麼樣？

哎呀，不行啊，不寫這些的話，

（1）如果外部系統輸入的資訊格式不對，目標系統照單全收，系統里的數據不就亂了嗎？

（2）如果不這樣提醒後面的設計人員，他水平太差不會設計資料庫怎麼辦？

（1）屬於"意念式"。

如果需要防止（1）發生，像念咒語一樣扔一個這個也是無法生效的，需要有行動。

行動方案A：

要求外部系統保證資訊格式合法，如果出現不合法的情況，槍斃外部系統相關的涉眾。槍斃人數多了，合法的概率會大大提高。

行動方案A和目標系統沒有關係，需求規約里不需要上面圖片的內容。

行動方案B：

目標系統需要在這個用例中（注意這個前提）驗證以保證資訊格式合法，那麼，就要在這個用例的用例規約里說清楚：在哪一步做的驗證（步驟），驗證的規則是什麼（業務規則），同樣不能念咒語。

（2）屬於"意淫式"。

只要系統能滿足用例規約里寫的各種內容就可以，不需要去"意淫"設計人員會怎麼做。

不管設計人員選擇存儲數據方案時使用文本文件、關係資料庫還是非關係資料庫，都不會影響系統的需求。

即使周圍沒有人會做這個系統，也不會影響系統的需求。系統的需求只和涉眾利益有關。

一個水平很差的設計人員會因為沒有掌握設計技能而搞砸很多東西，但這和這個用例甚至這個系統沒有特定關係。

可以用《軟體方法》中的"投幣法"（"團滅法"），在業務建模和需求工作流，讓所有的分析設計人員冬眠，所有分析設計工具封存，誰想系統內部怎麼構成誰遭雷劈。有這樣的決心，才能得到高品質的需求