一、软件需求分析与设计的边界是什么？
三年前，曾有同事问我，需求分析与设计的边界是什么？
负责需求的这位同事属于另一部门，他将需求报告传递给我部门的开发团队，由开发团队完成开发。
在团队完成开发提交给需求的同事——PO后，PO发现有些在他看来是显而易见的问题，开发都不考虑。例如：两个日期的校验关系，某些字段明显的是应该下拉选择输入的。
但开发人员人员说，你的需求上没写啊。
而我彼时开始推敏捷开发，对我们的开发人员说，PO需要对需求进行描述，定义验收标准，凡是验收标准上没有的开发都可以不做。
该PO问我这个问题，我感到难以回答。回想自己做需求，做开发，某些需求确实是不言自明的东西
二、同样的问题再次出现
今天找我们的一个测试人员交流。他所在的团队同样出现了上面这个问题。在讨论需求的时候，PO对开发说，你们按照需求文档开发就行了。这份文档是几个月前写成的。另外还有份原型。原型和文档并不一致。于是PO说，看哪个材料里面的字段多，就按哪个材料开发。
3个月前完成了一版提交，一直搁置，现在用户开始试用，提出来比较多的问题，其中有些就是“显而易见”的问题，如一些单据编号缺少规则、两个日期缺少关系校验、“是/否”这样的都没有下拉选项，等等。
测试人员测试时提出了“建议”，但开发人员认为需求文档上没写，于是不做处理。来回两次，测试人员也没有兴趣再提这样的问题。
还有些需求文档上写的内容看起来不合理，但开发坚持就按需求文档开发。
三、我理解的边界
这几天，看了《超越需求》，看了《软件需求》，加上之前看的CMMI2.0、GJB5000B中关于需求分析与管理的内容，很坚信一个结论：
需求与设计没有明确的边界。
需求和设计之间的区别并不总是那么清晰。同样的技术被用来需求获取，建模和分析这两者。需求会产生设计，这反过来可能推动发现并分析更多需求。两者之间的转换往往是微妙的。——《超越需求》p19
三种典型的需求类型：
1.客户或业务需求 2.解决方案需求 3.接口或连接需求
。。。。。。
客户需求进一步细化为解决方案和接口或连接需求。除了来自客户需求之外，解决方案和接口或连接需求都来自所选的设计解决方案。
在整个项目过程中持续识别和细化需求。让利益相关方参与需求开发和分析活动，让他们看到需求的演变。分析设计决策、随后的纠正措施以及反馈对需求的影响。分析可以用来理解、定义和选择需求。
。。。。。。
反复进行分析，直到有足够的细节来开发解决方案或解决方案的一部分。分析需求和操作概念及场景，可能会导致识别出更多需求。
——《CMMI 2.0》需求开发和管理
需求分为业务需求、用户需求、软件需求（或功能需求）。
业务需求是业务愿景，希望通过上马某个项目/系统/产品，达到何种目的。这是由发起者提出来的。
用户需求是满足业务场景的要求。
软件需求是具体的功能上的需求。
需求分析是个渐进的过程。需求分析与设计应该频繁交互。
在设计中，还存在架构设计，架构设计里还有功能架构设计。功能架构设计本身就是用户需求的分析过程。
从用户需求到软件需求，本身体现的就是一种设计过程。而传统的软件需求规格说明书，就是由设计与开发人员编写的。因此开发人员不能只是负责编写代码。
开发人员不能逃避功能设计。如果所有的功能设计都需要由他人完成，自己只是负责实现，那这样的开发人员只能是“码农”了。
工程师的五个等级（吴军 《浪潮之巅》）
仿照朗道的方法我也将工程师分为了五个等级。对于其专业的人士也可以依次分类，分类的原则大致如下，第五级：能独立解决问题，完成工程工作。
第四级：能指导和带领其他人一同完成更有影响力的工作。
第三级：能独立设计和实现产品并且在市场上获得成功。第二级：能设计和实现别人不能做出的产品，也就是说他的作用很难取代。
第一级：开创一个产业。
以计算机行业为例，一个人毕业之后，经过一段时间锻炼，能够熟练的运用工程的知识和技能解决问题，独立完成所分配的工作。而不需要他人的指导，这就算一个合格的五级工程师。再具体一点，比如说这个人在京东公司任职，老板让他做一个工具，找出那些不断帮助男女朋友买书的读者，他自己知道在公司内找谁去要数据，如何确认两个人可能是男女朋友，而且经常买书，也知道自己在京东公司的环境里应该使用什么样的开发工具，以及为了方便客户使用这个工具应该有什么样的基本功能。如果还做不到这件事情那就算不上是一位合格的工程师。
在过去工程师和科学家是可以并列的头衔，今天在法国和德国依然如此，那里的工程师会有一个特殊的资格证书，就如同医生和律师有特殊的资格证书一样，但是在中国，很多人从工科大学一毕业，公司的就会在他的名片上印上工程师，然后就似乎已经成为工程师了，很多人有这个头衔，但并不具有工程师所应该具有的基本的技能。在IT行业很多人被称为码农，虽然这个名字不太好听，但是仔细想一想，似乎也是对天天简单的重复低层次的IT工作的人的一个形象的写照。
