写出一份有意义的需求文档

重要性

  1. 需求作为软件开发的排头兵,决定了项目发展的方向,方向错误,全局失败
  2. 需求的频繁变动,不仅影响项目的进度,更影响编码人员的工作热情、工作态度(人心散了,队伍就不好带了)

参考:项目设计与代码组织-案例分析

视角

以客户需要为视角

应该以客户的视角来书写文档,以客户实际的需要作为中心。比如:工单管理,应写明客户为什么需要求救工单,客户现实中是如何处理求救工单的,而不是直接将需求具体为:录入工单、回访工单

以软件设计为视角

必须以定量分析来描述文档,而不是概念描述,比如:一般情况下、通常、大概、有时候,这些概念性的内容,计算机乃至程序员是无法理解的,应该将各种不同的情况加以分析,转换为可以判定条件,比如:美女筛选这个业务,1.身高大于170cm 2.体重小于45kg 这些定量的数据,可行,而 3.皮肤白 4.气质佳,这样无法定量的条件,就需要深入思考、妥协,转换为定量的数据,比如:3.白 > #333333 4.智商大于120并且情商大于>130,或者调整业务,增加人工投票的功能。

系统目标

不能是笼统的,走形式的,是真正的目标,有意义的目标,不多,但是必须有,如果根本都想不出来,那就需要先考虑系统存在的必要性

  1. 解决了什么问题
  2. 优化了什么业务
  3. 增加了什么便利
  4. 或者达到了某种目的(圈钱、面子工程等)

根据目的,来确定系统要实现的功能,实现功能的方法。比如:

  1. 面子工程:就不需要搞复杂的业务逻辑,而是展现更多的功能,但不需要每个功能很强大,有就行,而界面要符合某些人的口味。
  2. 便利性:则着重突出UI交互,让用户一看就懂,不学就会用
  3. 优化业务:那就需要把业务流程搞清楚
  4. 解决问题:需要找出本质的问题,而不是表面的问题

没有哪个系统能够满足全世界的需要,强大如iPhone也没有征服全世界,必须有所取舍,找出自己的亮点。

业务分析

以场景演练为出发点

最好能够以实际用户的身份,对现实的业务流程进行操作,熟悉每个业务步骤的原始执行方式,体会操作的实际效果及意义,在没有实际操作条件的情况下,也要尽量在脑海中,将每个业务过程演练多边(要有带入感,就像过电影片段一样),了解现实的操作方法之后,才能抽象出符合客户需要的产品设计方案。

穷尽特殊情况

对于某些复杂的业务运算,应穷尽各种情况,让用户进行解答,从而找出正确的计算方法:

??

明确优先级

  1. 项目功能较多时,应分析出功能点的优先级,指导开发安排进度
  2. 尽量指定各个功能点希望完成的时间点(技术部根据期望的时间点和功能的难易程度,规划进度表)

文档的组织方式

很多需求文档都是对功能的罗列,1、2、3、4、5,仅仅是一个一个的罗列,读起来索然无味,根本无法调动阅读者的积极性,让人读得很勉强,引不起思考。甚至,不谈功能与功能的联系,苍白的义务式的罗列。

功能组织

将能够完成一项特定任务的功能,按照业务逻辑走向,进行分组表述,是一个较好的方法,恰当的功能表述顺序,与内容组织,更容易让人理解作者的本意

而对于那些诸如:参数设置、业务字典、部门管理等等一些无脑功能,基本是固定不变的内容,简单罗列即可

罗列基本、突出重点、详尽难点

长篇累牍,重点不清的文档虽然也能说明问题,但是会增加阅读的难度,容易被程序员抵制,甚至抛弃,即便是强制去读,也不利于理解。

比如:客户管理这个大功能

如果分解为:新增客户、删除客户、修改客户、客户资料查看、客户信息统计,并详尽说明;有多大意义?

较好的分法:

  1. 客户档案管理:新增、修改、删除、查看(一行文字就ok了);然后列出客户档案的字段,针对较复杂的字段,进行特别说明
  2. 针对客户的类别分别描述不同的客户有那种不同的业务处理方式
  3. 针对不同的统计内容,画出对应的统计结果草图,并略微说明统计的意义
  4. 对一些特殊的界面需求,比如:查询条件,做出具体要求,并说明其中的用意
  5. 与客户相关的业务,指明必要的链接

对于一些较复杂的业务逻辑,比如:运营补贴的计算方式(因素很多),要穷尽各种因素的组合,进行详细描述。

用业务实例辅助说明

以实例来描述业务场景,通常更容易理解,比如:老人档案审批


  1. 社区填写老人档案,提交给街道,进行第一次审批
  2. 街道第一次审批
    1. 通过后,提交给区县,进行第二次审批
      1. 区县审批通过,则将老人档案设置为 已审批档案
      2. 区县未审批通过,则将档案退回到街道重新审批
    2. 审批未通过,则退回给社区
      1. xxxxx
      2. xxxxx

备注:

  1. 每次审批,有:通过、未通过两个选项,对于未通过的审批,必须填写审批意见。
  2. 其中街道在审批过程中,可以修改:审批意见、截止日期

  1. 场景中可以使用实际的客户名称,比如:金水区民政局、丰庆路街道办等,增加可阅读性
  2. 对于描述的内容,可增加 斜体、粗体、下划线 等因素,将角色、业务点、业务数据 等内容,着重标出,提高内容质量

文档优化

  1. 使用更形象、合适的语言描述,比如:移动用户的增加,是“新用户入网”,而不是“新增用户”,“新增团队”也没有“创建新团队”更贴切

笔者注

  1. 系统及文档迭代化:系统的第一版不要追求过大过复杂,而应紧抓核心目的,仅完成核心目的必须的内容,随后的功能逐步添加;类似于抛砖引玉
  2. 系统可持续交付:每个功能的完成,系统都是完整的、客户可用的