最初步软件需求说法的简单调查报告

缘起

笔者在这几年工作中，接触了各类需求，不同人员在不同的时间点按照不同表述方式来提供。在沟通交流中，有些时候会因为说法的不同和不同的说法，浪费不少时间，往往会有这样的感觉：唉，原来你说的是这个啊？ 或者是这样：哦，我大概明白你的意思了，你的这个结构逻辑是这样的啊。

所以在4月10日在微博上发起了如下的调查

@张克强-敏捷307

调查-你如何称呼最初步的软件需求？业务需求？客户需求？用户需求？原始需求？@徐锋-需求@PMO之道---蔡德辉@haitao深圳各位朋友随便说说

再补充了条

张克强-敏捷307：有没有使用 概要需求 说法的情况？

澄清调查问题

朋友们首先要澄清问题，对于说法的问题，由于刚开始没有共识，启动讨论第一步是要定位问题

PMO之道---蔡德辉：初步到什么程度？//@张克强-敏捷307:有没有使用 概要需求 说法的情况？

|转发(11)4月10日 09:06

lvxinke：如何定义初步？

我的回答：

张克强-敏捷307：程序员还不能拿来开发

lvxinke：这是结果，还是不够清晰，初步需求的价值或者目的是什么？

张克强-敏捷307：初步而言，最紧要的是收集。//@lvxinke: 这是结果，还是不够清晰，初步需求的价值或者目的是什么？

来自@郑仁华_PZ简明扼要的补充

郑仁华_PZ：用户或者客户意见，提炼后才说需求。//@张克强-敏捷307:程序员还不能拿来开发/

朋友们的精彩点评

PMO之道---蔡德辉：从设想、业务规划、系统需求、软件需求看看是哪个

lvxinke：前两者？@王海鹏Seal(《掌握需求过程》的译者)

王海鹏Seal：最初的时候，有人有一个vision//@lvxinke: 前两者？@王海鹏Seal(《掌握需求过程》的译者

张克强-敏捷307：设想和业务规划更像些，系统需求也许是，有些软硬件一体化开发是先出系统需求，然后分解到软件需求。 软件需求肯定不是初步的了。

agile123：RUP中好像叫Stakeholder Requests（含Customer Needs），代表一开始收集来的各种原始、粗略、未经整理、分析和细化的初始“需求”，因不是正式、经确认的需求，所以不叫Requirements。另：CMMI、UP、SWEBOK...对几十年来常用的软件工程术语作了一些统一和规范，大家平时可以多参考，以免重新发明轮子。

张克强-敏捷307：回复@agile123:赞，谢。其实这不是重新发明轮子的问题，估计是没有统一说法的，只是列举下，看看哪个占比多些

pinxue：是说 initial idea 吧，所谓初心是也。然后 brain storm 建立 vision，不知不觉 feature spreading，然后搞出个不知啥玩意

王海鹏Seal：意识到也许可以搞出更好的东西，解决人们还没意识到的痛苦。比如全球还有2/3的人不能上网，但他们不知道自己的痛苦。//@pinxue: 是说 initial idea 吧

张克强-敏捷307：初心貌似是哲学词汇，让我想起了王阳明，软件领域的话，初步需求应当比初心再多走些，感觉是根据初心做了些延伸思考，然后可得到收集

haitao深圳：系统或项目的需求。。。。叫什么不重要，怎么做需求调研、分析，才是一个项目成败的关键

haitao深圳：先是吐槽现有系统、模式的痛点，吐槽的人、内容多了，就是新系统的必要性

徐锋-需求：我从不纠结这些劳什子名词！对于小型需求、变更需求而言；用户提出的通常是以解决方案形式陈述的Want；需要分析其真正的Need，甚至是内心的win；从而结合开发成本，在解决方案上达成共识。而对于整个系统需求而言，用户会有不同角度的需求片段，需要汇总成体系化的、指导开发的SRS。

张克强-敏捷307：回复@徐锋-需求: 但是为了便于收集最初的素材，总是要有个说法的，当然也许“需求素材”也是个不错的说法。

黄勇TonyWong：业务需求层面我喜欢用“需求愿景”，提醒领导与决策层不要过多或者过早侵入用户需求：用户需求层面的我喜欢用“需求素材”，这样会让提供者明白他们不是在做设计，也会增加需求分析人员的责任感和使命感。

火星人陈勇：赞成业务需求，道出了本质。如果客户懂业务直接提出技术需求，其他几个名称就崩溃了。

小结

调查进行时间不长，短短的4天就收集到了以上精彩观点。但也确实可以看到这软件需求前期阶段存在不同说法。

试图小结下，首先罗列下形容最初步需求的所有说法

1，业务需求

2，客户需求

3，用户需求

4，原始需求

5，用户意见

6，客户意见

7，设想

8，业务规划

9，系统需求

10，Stakeholder Requests 干系人要求

11，Customer Needs 客户需要

12，initial idea 初心

13，需求素材

14，需求愿景

（朋友们，如果你还有有不同的说法，请告诉我，或者你已经说了，但是我漏了）

这些不同的说法其实说明了如下的一点：在正式需求表述之前，是值得处理正式需求表述前的信息。

所谓的正式需求表述是指可供各方作为下一步工作开展的基础，常见的有SRS-软件需求规格说明，Use Case Analysis-用例分析

在敏捷开发中，常见是User Story-用户故事。

这部分的说法 我建议 沿用软件需求规格说明作为统称，传统SRS当然是SRS，采用Use Case或者User Stroy也同样是软件规格说明。

在最新的SWEBOK V3.0中就是采用了SRS这个说法。

更关键的问题

在SRS之前如何做？要不要分几个阶段做？出什么样的产物，叫什么名称？

在最新的SWEBOK V3.0中，用的是 Requirements Elicitation 作为标题，强调了从Requirements Sources收集

Requirements elicitation is concerned with the

origins of software requirements and how the

software engineer can collect them. It is the first

stage in building an understanding of the problem

the software is required to solve.

It is variously termed “requirements capture,”

“requirements discovery,” and “requirements

acquisition.”

Requirements have many sources in typical software, and it is essential that all potential sources

be identified and evaluated.

而在CMMI for DEV V1.3中，对应是如下结构

SG 1 Develop Customer Requirements

SP 1.1 Elicit Needs

SP 1.2 Transform Stakeholder Needs into Customer Requirements

SG 2 Develop Product Requirements

SP 2.1 Establish Product and Product Component Requirements

SP 2.2 Allocate Product Component Requirements

SP 2.3 Identify Interface Requirements

传统的SRS是面向软件业界人员的，不便于让客户理解，所以CMMI区分了客户需求和产品需求、产品组件需求，而Use Case和User Story的可读性都很好，是直接可以给客户看的。所以采用Use Case或者User Story的一份需求规格说明是可以同时满足CMMI 上述两个目标。

推荐的实践

SRS前在需求方面最紧要的事务是收集，而不是分析，所以我推荐采用“原始需求”（英文：Original Requirements, 或者origins of requirements)的说法，这个说法最有利于收集。无论宏观展望，还是微观鸡毛蒜皮，无论总经理董事长，还是一些操作员，无论业务规划、初心，还是要个醒目提示符，这些在原始需求下统统可以处理。

SRS前如果再划分阶段的话，就显得稍显沉重了，一般的，SRS前没有必要再分阶段了。但是如果企业出于产品整体考虑，在集成产品开发下，为把握市场机会，投资回报，需要整理产品级需求文档，常见的文档名称有市场机会分析、产品需求说明

结语

最后我想说的是在Scrum中只用单列表的Backlog是不够用的。从backlog的字面意思上，直接的意思貌似是待办项的单个列表，按照Scrum要求带有优先级。

进入Sprint之后的 spring backlog中条目的颗粒度要能够在sprint中实现。而Sprint之前的backlog中条目是难以限制颗粒度的，要紧的是采集，珍视市场机会，珍视客户诉求。多列表+关联或者树形分解结构的backlog才能应对SRS前后不同颗粒度不同形态的需求。

另外需求的生命不是在上线后就结束了，后期还有更长时间的维护修改升级等等。如果只是一个提供定制化交钥匙工程的乙方，不负责后续运维升级，那么确实完成的user story可以不管了，但对于甲方或者是业主方，Backlog上做完的条目不是可以扔掉的。那么对照Backlog的字面意思，做完的需求继续维护在Backlog中，是不是有点尴尬？ 如果说后续的修改按新的用户故事来处理，那么随着时间推移，老用户故事、新用户故事、新新用户故事，新新新.......用户故事都在，那是个什么景象？

真正实用的Backlog不是看上去那么简单，也不只是待办！

Backlog的字面意思与其实际使用存在差异，也许这就是PMO之道---蔡德辉所说的敏捷带来的“软件工程的乱像”之一。

BTW： 本调查和本报告是受PMO之道---蔡德辉微博影响所发。

感谢参与讨论的所有朋友。