前言
不知道有木有同行和我一样,在进行需求分析之前阅读了大量的资料和功课后本以为编写需求分析会行如流水。但真的提笔的时候,却发现自己看了那么多的资料提炼出来的内容却少之又少,而且很空洞。于是越想越不知道如何下笔,甚至有点恐惧。问题到底出在哪呢?
后来在一次会议上,有同事提出了这个问题。当时的产品经理给出了一个方法“硬着头皮去写,哪怕写的不忍直视,要知道所有的需求文档都是在不断修改和优化过程中诞生的”。确实,走出去才是第一步;至于走出去之后我们又该何去何存呢?直到看了“知行思新”的一篇博客,感触颇深。原来,我们不知道如何下笔的问题根源就在于“问题”。在没有任何“动机”的情况下去阅读资料,我们也就失去了方向,失去了思考和总结。所以,一份“问题清单”可以给我们在分析问题的时候一个明确的导向。
列出问题清单: 这个过程我们需求思考,向客户问些什么问题可以帮助我们了解目的目标和范畴。可以从功能、数据需求、数据完整性、安全性和环境进行突破。
一、功能
以下问题主要涉及系统应完成的功能与目标。
- 系统应该做些什么?
- 为什么你想建这个系统?
- 系统看上去应该是怎样的?
- 需要些什么报表?
- 用户需要自己定义新报表吗?
- 系统的操作者会是谁?
二、数据需求
这些问题是为了弄清项目的数据需求。了解需要些什么数据能帮助我们定义数据库表。
- 系统界面上需要展现哪些数据?
- 这些数据应该由谁来提供?
- 这些数据是如何关联的?
- 这些工作现在是如何处理的?
- 数据来自哪里?
三、数据完整性
这些问题能帮助我们在构建数据库时定义完整性约束。
- 哪些数据是必须填写的?(eg: 一条客户记录必须有电话信息吗?)
- 数据的有效域是什么?(eg: 电话号码是否有格式规定?地址数据应有多长?)
- 系统是否需要根据邮编来检验城市的有效性?
- 系统中是否必须在定义了客户之后才能下订单?
- 系统要求多高的可用性等级?(系统需要 7×24 的可用性吗?数据的备份频率要多高?)
四、安全性
这些问题能帮助我们了解客户对权限控制与审计方面的需求。
- 是否每个用户都需要一个不同的密码?
- 是否需要控制不同的用户所能访问的数据?
- 存储在数据库中的数据是否需要加密?
- 谁做了什么操作是否需要记录以便于审计?(eg: 便于在需要时可以追溯操作的原因)
- 系统中的客户分成几个级别?每个级别的客户有多少?
- 是否已有文档记录了用户的工作与权责?
五、环境
这些问题能帮助我们了解当前项目将代替其他什么系统或流程,以及项目将与其他哪些 系统进行交互。
- 当前项目是要代替或升级现有的某系统吗?
- 是否有描述现有系统的文档?
- 现有系统的哪些功能是需要的?哪些是不需要的?
- 现有系统处理些什么数据?这些数据是如何存储的?数据之间是如何关联的?是否有关于现有系统数据的文档?
- 当前项目必须与其他哪些系统交互? 项目与其他系统之间如何交互? 新项目是否需要向现有系统提供数据?如何提供? 新项目是否需要接收现有系统的数据?如何接收?
- 是否有关于其他系统的文档?
- 客户的整个业务流程是怎样的?(了解在整个业务流程中当前项目的作用)
总结
在带着问题清单和动机深入客户了解需求,可以让我们做到事半功倍。当我们能够很好的回答以上的问题,那么在我们的脑海中已经有产品的大概轮廓了。