需求与设计

一直想写一篇从需求分析过渡到架构设计过程中的心得体会，无奈学艺不精，借每天写作训练的机会，顺便复习一下潘加宇老师的课，简单地对自己的学习做一点总结。

潘加宇老师的《软件方法》开篇就是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. 成本
   在正确的时间以合适的成本做正确的事。

项目早期应以核心功能为重点，核心功能缺失，系统跑起来对用户也没有价值。
成本太高，产品或项目做出来没有竞争力，或者还没做完公司就被熬死了。

转载于:https://blog.51cto.com/13093181/2354696