DDD领域驱动设计批评文集>>
《软件方法》各章合集>>
《软件方法》自测题之前没有给出答案，需要扫码自测，做到全对才知道答案。
这样做的原因，参见“《软件方法》自测题为什么不直接给出答案？”一文。
从现在开始，将逐题给出《软件方法》当前版本自测题的答案和解析。
以后，《软件方法》出版新版本时，将在书的最后给出前一版本所出自测题的答案和解析，同时新增一批自测题。新增的题目依旧是不给出答案，需要扫码自测。
第1章自测题 Part1
1. [单选]软件开发中需求工作的目的是____。
A) 让系统更加好卖
B) 更好地指导设计
C) 对系统做概要的描述
D) 满足软件工程需求规范
答案和解析：
A) 正确选项。
B) 错误选项。这个选项很容易被误选。
需求是为了“更好地指导设计”，这样说听起来很体贴，但思考的方向不对。
需求要考虑的是，在当前竞争形势下，系统至少要提供什么样的功能和性能，才能够被目标组织所接受。至于这个系统本公司人员现在会不会做，打算怎么做，还是外包给其他公司帮忙做，还是找猫、狗、外星人来做，是不需要考虑的。
如果把“指导设计”带进来，就会出现需求为了迎合设计人员的能力而变化的情况，许多奇葩的需求规约就这样冒出来了：
因为担心程序员编码的能力不过关，有的需求规约里写上了编码规范；
因为担心程序员数据库建模能力不足，有的需求规约直接规定了数据库的各个表和字段；
因为担心程序员界面设计能力不行，有的需求规约里详细给出了界面设计图；
甚至有的需求规约连伪代码都写上了，生怕如果不这样手把手教，程序员不会做。
要是程序员没上过中学，是不是需求规约还要把中学课本也放进去。
******
缺少什么能力就去提高什么能力。这些能力适用于很多系统，跟当前所研究系统、当前所研究的用例并没有特定关系。
不过，有的人恰好就喜欢这样做，可以假装在“做需求”，同时还可以废话刷工作量。书中截图：
开发系统的团队的能力会不会影响需求呢？会，但这个影响是系统有和无的问题，而不是系统需求的具体内容，可参见“屌丝可以接受土坑酸菜面吗-架构可以影响需求吗”一文。
C) 错误选项。
需求是系统作为一个整体的表现，有概要也有详细。
以ATM机为例，系统可以“取款”（相当于用例，概要），系统还要“验密码”（相当于步骤，详细），“验密码”有规则（相当于补充约束，更详细），这些不管概要还是详细，都是系统的需求，因为都是在说系统作为一个整体什么什么。
但如果说“系统分为界面部分、业务部分……”（概要）、“系统的界面部分有一个提交按钮”（详细）、“系统的业务部分有一个验密码组件”（详细），那就不是需求了，因为已经提到了系统的结构，不管是概要还是详细。
D) 错误选项。
本选项的说法颠倒了因果关系。应该是正确理解需求背后的道理之后，制定规范来协助执行。
现实中，有的开发团队领导在推行建模方法学时，就是啪一下定个规范，出一堆模板（所以，经常会有人找我要模板，让做题却不做），然后就要求大家往里面塞东西。这样做的效果可想而知。
还有的同学说“哎呀，我们团队真的需要引进UML来规范一下啊”，其实更多是道理不清楚的问题，不是规范问题。"规范"很容易被当成替罪羊。正如书中所说：
建议的改进策略是，把建模方法学看做一个工具箱，各个岗位结合自己的工作挑最需要的工具来帮助改进，改进好了一点再改进一点，等有了一定的共识，规范自然就浮出水面。
