程序员喜欢什么样的需求文档？
我又要嘲讽了：幼稚的程序员才会执着于需求变更 程序员分很多种，开发人员从前端到后端，从初级到高级，从代码开发到结构设计，众多门类各种层次，就被三个字“程序员”给概括了。 这也许就是一个抖机灵的答案排第一的原因吧。 需求与业务的符合度，需求的明确程度，以及完善的需求管理，这三者都比“不让需求变化”重要得多，也容易控制得多。  需求是什么？我们口中的“需求”，一般指“软件需求规格说明书”、“Software Requirement Specification (SRS)”。下文引自百度百科软件需求说明书 这样一篇文档，由需求工程师们或产品经理们开发，最终交付给开发团队。而我们的“程序员”们，到底看了其中的多少内容呢？你是不是直接跳过背景、目的、范围，跳过业务描述等所有内容，直接找到跟自己相关的功能描述，开始干活呢？ 如果你真的是这样工作的，那就不要怪我，把你归入“幼稚的程序员”这个行列。因为你压根不懂需求规格说明书该怎么使用，这是因为你压根不懂什么是需求，而这是由于你不知道你自己的开发工作与需求是个什么关系。你连自己在干吗都不知道。 与其枯燥的描述，不如讲故事。我来给你讲，我的故事。 我最初是一名垃圾级程序员，不同的是，我做过软件测试。做软件测试的时候，我依照需求规格说明书给别人挑毛病，做垃圾程序员的时候，我被人家挑毛病。这是一个痛苦的地狱，一方没完没了的攻，一方没完没了的受。攻也攻得很辛苦，受也受得很痛苦，而先做攻再做受的更痛苦，生理上痛苦，心理上更痛苦。 软件缺陷中，如果是代码错误，例如if(a=="1")这种，其实没什么好说的，这就是2B了；经常有争议的是这种，我认为需求说的是这样的，而测试人员则认为应当是那样的，这样就争执不休，找到产品负责人，让他定夺。如果是我对需求理解有误，那还好说，怕的是，产品一看，哦，自己写的需求写错了，让我改。 蛋疼啊！你为啥不在一开始就写清楚捏？我浪费这么多时间，用了这么大力气才开发出来的东西，结果全是无用功。这时候我会很自然的问产品，你确定就这样了么？不改了？产品肯定一口咬定，不改了！ 没出一个星期，个狗B就又改口了！再过一个月，没准又改。这样改来改去没完没了，我就此绝望：安得需求最终版，大庇系统功能俱实现，产品测试笑开颜！ 但是在我读过一些书之后，我明白，这是不现实的。 还记得，老罗在一个理想主义者的创业故事2014中说过的话么，一款手机的热度只能持续不到4个月；还记得国内游戏为什么没有完善的测试那个问题下的最佳答案么？因为开发周期非常短。 我所在行业也是一样，产品人员是在分析了一款产品的市场现状和前景以及竞争对手的动态后设计出来的，这个产品具有时效性，它必须尽快上线，以填补市场空白，在与竞争对手的产品竞争中获得先机。你第一个投放市场，用户习惯就以你为准，后面的只能向你兼容。 所以，产品经理注定是无法清晰完整的写出一个完美的需求的，遑论最终版？在开发过程中产品经理并不是就闲在那里等着，而是需要继续调查，推敲业务，寻找最终用户试用并收集反馈等等，需求怎么可能不改？ 接受这个现实吧，需求将永远不停歇的变更，开发过程中变更，系统上线后继续变更，只有一种情况下需求不会变更，就是产品没人用了。   -----------------------------接受了这样的设定后，我觉得天都塌下来了-----------------------------------------------   CMMI为什么强调需求管理？因为我们要控制需求变更，不能让需求变更随意的影响开发过程。 为什么流行敏捷？就是因为要快速响应需求变更啊！ 软件开发方法论上的东西就不在此赘述了，这里重点谈，作为一个成熟的程序员，什么样的需求对你来说，是好需求？ 需求是分层次的。 简单划分，最顶层是行业需求，包括行业规范，文件，法律法规，潜规则等等 然后是业务需求，设计业务以满足行业需求中的各种规定 然后是用户需求，设计人机交互以满足业务需求 最后是系统需求，设计系统间/内交互以满足用户需求 自上而下，上层决定下层，下层必须满足上层的全部要求。上层是下层设计的依据和动机，下层是上层的具体实现。因此，越往下，变化越频繁越剧烈，越往上，变化越缓慢越轻微。 一般人认识的需求规格说明书，包含且仅包含用户需求，用户需求使用功能列表和用户用例来描述。而用户需求作为整个需求体系的第三层次，变化是相当剧烈的。当然，对于程序员最蛋疼的人机界面的变更等等，并不是用户需求的主体，属于用户需求的边角余料。 例如，依据《如何编写有效用例》一书的描述，符合用户需求的用户用例描述应当是： 操作员输入用户名和密码，系统验证用户名和密码的正确性，展示欢迎界面。 至于登录页面什么样，欢迎页面什么样，都应扔进附录里，与用例解耦。 那么，从需求的角度来说，如果你觉得需求变更没完没了，不厌其烦，那么，你应当期望需求规格说明书包括更加高层次的需求，这样，你就能把握用户需求的编制依据，这样，需求中的错误，疏漏，自相矛盾，你就可以第一时间发现；你也可以反思自己的编码是否符合业务目的，唯有符合业务目的的代码才能永存。 所以，在我眼里，一本好的需求，必然也必须包括尽可能完整的业务描述和业务目的描述。好的需求是从背景开始展开的，从行业谈起，到该项业务的设计，到用户需求的设计，层次清晰，条理清楚。这样才能帮助读者把握整个文档的思路和脉络。