【需求】有了任务书，还要分析需求范围吗？

有一些组织内的软件项目，软件的用户需求——任务书是由系统方下达的。由于软件任务是由系统方自顶向下分解的，所以系统方下达 的任务书理论上就当能够定义清楚软件应完成的任务，即软件需求范围。

正是由于90%以上的软件开发人员有了这样的认知，他对下属的任务书就不会关注其需求范围定义的是否合理，而只去关注需求描述的一致性、准确性、有无二义性等等。

软件开发人员给任务书提出的问题都是这样式的：

• 不符合任务书模板要求。如，没有给出流程图；某项功能的描述没有给出异常处理等。

• 需求描述不准确。如，没有给出输入/输出数据的值域范围； 没有给出数据处理方式等。

• 需求描述不一致。如，功能描述的执行流程与流程图中表述不一致。

• 需求描述错误。如，对应管脚应为继电器IO口。

但是对于需求范围定义是否合适，是否真正满足系统的需求，软件开发人员都没有去关注。

而需求开发工作的第一要务就是：定义项目的业务需求，也就是明确项目的目标和范围（摘自《软件需求最佳实践》）。软件对于用户来说，是完成某项任务的工具，软件是否满足用户需求，取决于软件在用户完成该任务的过程中提供多少助力。

所以要定义清楚软件的用户需求范围，就应先了解用户要完成的任务，以及完成任务过程中用户遇到的难点和痛点。

虽然任务书是由系统方编写下发的，但并不能保证任务书中中定义的业务需求就是充分的、完整的。如果软件开发人员在与系统方沟通任务书的过程中，也能站在系统方的角度考虑软件应完成的任务，那么，会减少任务书中遗漏的需求项的数量，根据错误发散性原理——早期的问题或错误，会导致后续开发工作中出现十个甚至百个问题或错误，会使得后面开发工作中避免大师的需求变更和Bug的出现。

软件开发，不应仅仅满足于完成用户在任务书中明确表达的需求，还应进一步挖掘出用户没有表达出来的，但对于用户完成自己的工作大有裨益的真正的需求。这样，才是真正完成了用户需求开发的任务。

微信号：IdeaofSE