本部门主要从事面向互联网的管理软件的开发。
部门中有一个叫做“需求工程师”的岗位，大概的工作职责就是，根据项目经理或者客户提出的要求，进行软件设计，然后将设计稿交给开发人员开发。
这是个联系用户与技术人员的桥梁，重要性嘛，怎么强调都不过分。
有段时间，我发现他们工作中，最苦恼的事情不是客户漫无边际的要求，不是客户不断的需求变更，也不是研发人员认死理的工作态度，最苦恼的事竟然是，研发人员往往容易把他们的设计要求理解错误，导致开发出来的功能好多根本就不是需求人员想要的，导致需求人员与研发人员经常在办公室中吵吵闹闹，争执不下。这样不但导致项目拖期，还会让大家工作心情非常郁闷。
于是，就下苦功研究，究竟有什么办法可以避免出现这种完全可以避免的麻烦。也许，客户我们无法控制，但是，我深信，我们的内部开发过程是可以控制的，不应该将大量的精力浪费在这种不必要的内部沟通中。
经过一番研究思考，得出的结论是，这是需求表达的问题。
对于需求工程师来说，工作主要包括两方面，一是设计，一是把自己的设计成果表达出来。设计是个思考的过程，综合考虑软件的易用性、易学性、扩展性、健壮性等等，说实话，这功力不是一朝一夕之功，没多年的积累，不可能达到多高的境界。这个不在这篇文章的讨论范围之内，姑且不说它。
另一方面是要把自己的设计思想表达出来。好多做需求分析的人员做不好这件事。其实，在我想来，这件事做不好是非常可惜的。设计功力，需要日积月累，表达好自己的设计思想，却是可以速成的。自己的设计成果，可能是非常好的设计思想，最后却败在没有表达好上面，这真是奇冤啊。而且，还有非常重要的一点，如果没有良好的表达需求的路子，你很难进行比较复杂的设计，越复杂的设计，越不容易让人理解，如果没有好的表达方式，你脑子中想得再好，也无法让人实现好。
于是，为了让需求人员更好地表达需求，也为了让开发人员更好地理解需求，在部门内部进行了一系列的需求规范工作。关于需求表达的问题，总结了一下，大概包括如下这几个方面：
原型界面。
我们使用一款设计原型的工具。需求工程师会根据客户需求设计原型，原型中仔细表达了客户的大部分需求，包括显示方式、按钮摆布、触发事件、页面切换等。如果这个软件够简单，只是一些基本信息的增删改查，一般通过原型就可以表达90%以上的需求了。当然，这种系统很少见，为了表达清楚需求，还需要一份文档，需求规格说明书。
需求规格说明书。
需求规格说明书中，详细描写了原型中每个按钮、链接、快捷方式等用户可以触发的事件背后的逻辑、要求、业务规则等。在撰写这个文档的过程中，要求需求人员自己思考自己原型中的每一个命令，每一次数据流动，对数据的每一次展现，每一次修改，然后写好每个触发事件的规则，以及需要处理的相关数据的数据字典。
原型界面与需求规格说明书是表达需求的两个最重要的内容。但仅仅通过这两个方式，并不容易表达好自己的需求，主要原因是有些需求太过零碎，如果都一字一句写下来，可真要累死人啊，别弄得开发的速度比你写文档的速度还快，可不滑稽死人？于是，另外还有些需求文档作为补充，可以大大减少需求撰写的工作量。
通用需求说明书。
所谓的通用需求，就是如果没有什么特别说明，就以通用需求文档中规定的为准。这个需求是部门级别的，部门中所有的项目都必须遵守这个文档要求。
通用需求中一般包括一些统一操作习惯、显示风格等的内容，例如，日期以什么形式展示，调用什么组件，怎么处理逻辑删除，怎么命名导出文件等等。针对一些需求点，如果项目中有不同的要求，可以在需求规格说明书另外专门描写，也就是说，需求的优先级，需求规格说明书是高于通用需求说明书的。也正是因为有了这个文档，我们才可以自信地说，我们完全可以通过文档把需求表达清楚，不需要多么复杂的中看不中用的工具，word文档就足够了。
试用报告。
项目完成，在试用过程中，会有需求变更的要求提出，我们会要求写试用报告。这份文档，你可以称之为试用报告，体验报告，小需求说明书，需求变更说明书等，总之，叫什么不重要，重要的是，这份文档的作用是对需求变更的表达。
研发人员根据试用报告进行开发，应对需求变更要求，开发完成，需求人员会把变更的要求整理到需求规格说明书中。也就是说，需求规格说明书是需要与软件一起变化的。
自明的需求。
并不是所有的需求都要写下来的，有些需求，我称之为“自明”的需求，就是一个正常人不需要进行培训就可以想得到的需求，如果这种需求弄不明白，那还是别写程序了。例如，原型上面按钮的标题为“删除”，当然是指在数据库中删除记录，这就是自明的需求，只要不痴不傻都知道，你要写成保存数据到数据库就算有病。当然，如果默认是物理删除，你在这里要逻辑删除，就要在需求规格说明书中写明了。
