编码前的思考


项目需求背景

PM针对于一个项目产品提出了数据报表平台的需求,而你作为RD要对这个数据报表平台进行开发。

作为一个RD,在编码之前,你应该首先有如下的思考:

确认需求内容

定义系统的输入输出

在这个例子中,应该是报表数据的来源是哪些,已有的数据是否已经满足所有的需求内容。 输出就应该是满足所有数据统计报表需要的统计信息。

定义接口

接口是跟前端页面交互的API。接口风格可以是restful,也可以是rpc。 接口的测试用例需要经过评审。

从用户角度去思考这个需求应该满足的条件,包含不限于:交互流程、响应时间

不仅仅是完成功能,还要站在用户的角度去思考已经做完的功能是否可用、是否好用、是否愿意用。

是否定义了时间问题,比如处理时间,系统吞吐能力

这是上一条问题的延伸,需要考虑系统未来会达到的规模,已经对应这个规模系统应该有的吞吐能力。

明确保密级别

充分考虑数据权限,不能出现数据泄露的问题。

明确系统健壮性相关设计

系统不应该只考虑正常的输入、输出。还应该考虑到常见的异常情况,以及对这些异常情况的应对方法。

明确硬件资源使用量

要对自己设计的系统的资源使用量有充分的认识和理解,要找到一个系统资源和QPS之间的最优解。

对系统的可维护性是否做出了约定

可维护性是当前软件工程里最重要的一个指标之一。设计出来的系统应该有足够完善的文档,让团队的新人也能快速上手来维护这套系统。

应该考虑到的降级方案

需要对可预期的风险做出预案以及对应的降级方案。

确认需求的完善性

需求定义是否足够清晰

充分思考需求,保证PM的需求你已经充分理解了。

在开发开始前暂时得不到的信息有哪些?是否跟相关人员确认了这些风险?

明确需求需要的输入信息有哪些,是否已经都拿到或者可以拿到。不能等到需求做了一半的时候才发现有些数据缺失导致需求无法实现。 发现这些异常之后需要向相关人员确认,之后一起讨论需求的安排,是应该删掉需求还是继续开发。

需求中有哪一些让你感到疑惑,有没有可能根本无法实现?

站在用户的角度去思考需求,提出自己的疑惑。

关于需求的质量

* 需求是否是用用户的语言制定的?用户也这样认为吗?
    * 需求中是否每一条之间都尽量避免冲突?
    * 需求中是否注意了避免规定设计工作?
    * 需求在详细程度方面是否保持了一致性;有没有应该更详细些的需求?有没有应该更简略些的?
    * 需求是否明确得可以分为一些独立的可执行部分,而每一部分又都很明了?
    * 是否每一条都与问题和答案相关?是否每一条都可以追溯到产生它的环境中?
    * 是否每一条需求都可以作为测试依据?是否可以针对每一条进行独立测试以确定是否满足需求?
    * 是否对可能的改动作出了规定?包括每一改动的可能性?