需求與設計

一直想寫一篇從需求分析過渡到架構設計過程當中的心得體會，無奈學藝不精，借天天寫做訓練的機會，順便複習一下潘加宇老師的課，簡單地對本身的學習作一點總結。

潘加宇老師的《軟件方法》開篇就是4個題目，各個都問到了要點上，今天只說最後一題：

4. 打開開發人員寫的需求文檔，發現用例的名字都是「學生管理」、「題庫管理」、「課程管理」……這背後可能隱藏的最大問題是什麼？

A）用例的名字不是動賓結構，應改成「管理學生」……
B）開發人員直接從需求映射設計
C）開發人員直接從設計映射需求
D）用例粒度太粗，每個應該拆解成四個用例，「新增學生」、「修改學生」……

摘自：《軟件方法（上冊）》 — 潘加宇
在豆瓣閱讀書店查看：[https://read.douban.com/ebook/39648638/?from=book](https://read.douban.com/ebook/39648638/?from=book)
本做品由清華大學出版社受權豆瓣閱讀全球範圍內電子版製做與發行。
© 版權全部，侵權必究。

答案A說的沒錯，但並非最大的問題，最大的問題我以爲應該是C。

我曾經遇到過一個比較極端的例子，就是tech lead要在本來就已經很複雜的幾層通訊協議棧之間加一層 3GPP 的 RLC 協議，目的是爲了優化數據包的包頭。當時項目中除了 tech lead 本人對 3GPP 比較熟之外，沒有其餘人有相應的技術儲備；RLC 代碼量很大，遷移成本比較高；爲了配合 RLC已有的實現，與它對接的上下層通訊協議棧要作大量修改；爲了知足一個優先級不高的非核心功能需求而引入一個重量級協議不只在項目啓動時顯得很不合時宜，也徹底與「下降開發、維護成本」背道而馳。

另外一次是在設計計費功能的時候，用戶在繳費先後看不到本身是否欠費，卻宣稱系統的功能設計完了，須要變更的模塊也都肯定了，甚至像模像樣的排好了開發計劃。

這些極端的例子都是從「作的視角」在替用的人決定需求是什麼，獲得的結果，需求不是需求，設計也不是設計。

那麼，在如今敏捷開發的大環境中，每每得不到完整需求，就要同步進行設計實現，需求分析和設計實現時應該考慮哪些問題？二者應該如何分割和過渡？我以爲應該從兩方面考慮：

1. 時機
2. 成本
   在正確的時間以合適的成本作正確的事。

項目早期應以核心功能爲重點，核心功能缺失，系統跑起來對用戶也沒有價值。
成本過高，產品或項目作出來沒有競爭力，或者還沒作完公司就被熬死了。