给开发看的需求说明书以“易懂”为主要标准,其中如果有特殊名词或专有名词或需要特别注意的名词,需要在名词解释章节中进行说明。
在平安证券做了为期两个多月的需求调研,本文以开发对平安证券需求问题为切入点,说明在写需求说明书的时候应该注意的事项。
一、 名词解释
以平安证券需求为例,开发提出以下需要定义名词的问题: 定期”与自然日的对照,例如,如何定义“月初、月末”等自然日(与工作日的关系等)?‘最新主体评级’的主体是指交易对手吗?‘外部主体评级’是指最新外部主体评级吗?提示日期与归属日期有什么区别?如何区分债券投资业务?规模指什么规模?授信主体是指谁的授信主体?……因此,在需求说明书中如果有特殊名词或专有名词或需要特别注意的名词可以在名词解释章节中进行说明。
1.1 日期
需求说明书中涉及日期的,如T日、工作日、自然日等日期需要进行名词解释。
1.2 口径
包括业务口径、规模口径、评级取数口径。
1.3 对象
包括资产、主体、交易对手、客户等说明。
二、 数据
以平安证券需求为例,开发提出以下数据相关的问题: 相关业务数据需要在本系统中落地?若期权的风险敞口值取不到,就不取?数据来源是数据集市吗?监管层面的‘预警阈值’==‘预警值’吗?‘阈值’==‘限额值’吗?数据同步问题,数据改变后本系统数据是否同步更新折算后计提金额,怎么计算?有计算公式吗?台账信息的字段有哪些?管控要求:“管控要求”是什么?持仓规模的单位是什么?万元吗?发行人是指“证券名称“的发行人吗?在需求说明书中描述数据包含以下:
2.1 数据来源
业务功能最小单位是字段,需要明确说明每个字段的数据来源。也就是哪些数据可以从外部系统获取?从哪个系统获取?哪些数据是本系统产生?从哪个模块产生?(涉及到计算需要说明计算公式)
2.2 数据落地
数据是否需要落地到表中。
2.3 数据同步
涉及到外部取数的时候,需要考虑数据同步问题,即外部数据变化是否会影响到本系统的数据,是否会同步更新。
2.4 数据字段
包括字段的含义、数据来源、数据类型、单位、是否手工输入、是否必填。
三、 处理逻辑
以平安证券需求为例,开发提出以下处理逻辑的问题: 部门/产品有多个,怎么显示?全部显示还是显示1个?《业务规模》较上日变化、资金来源、风险情况需要合计吗?《业务规模》出表金额怎么区分出来?如何判断是与持仓有关的?邮件发送时多笔和一起的时候邮件标题怎么设置?正文内容是?黑灰名单是全量更新吗?还是增量更新?系统自有的黑灰名单与外部对接获取的黑灰名单有不一致的情况,怎么判断入池?派驻审批不通过,退回业务人员?业务人员需要重新提交吗?资产分级按资产还是按每笔业务?资产分级手工调整和确认是否可以再修改?需求中功能,特别是关键功能,要在脑中模拟真实的业务场景、技术等环境,进行验证。每一个步骤、环节、关联限制等控制逻辑都要进行验证,并在站在全系统的角度,考虑关联影响。如,以操作员的角度,在脑中模拟操作该功能;以技术人员的角度,模拟操作人员每个动作,验证相关处理逻辑以及前、后置条件是否完备。要基于当前需求,多想(正常、异常、例外),多验证。
四、 数据展现
以平安证券需求为例,开发提出以下数据展现的问题: 有项目资料的查询信息的查询页面?舆情分类:怎么进行分类?有分类的设置页面吗?业务、派驻、风控看到的状态是不一样的,梳理出界面、查询条件、状态需要用AXURE等原型工具画出界面展示图。
知己知彼,百战百胜,知道开发关注的点,以后写需求说明书的时候注意下,让开发看需求说明书的时候易懂。
#专栏作家#
Vi-Vi-Fu,微信公众号:vivifu12,人人都是产品经理专栏作家。杭州某不知名公司需求分析师。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
|