我只是要颗星星，你却想给我整个宇宙

再说我不务正业，绝交！...





这周，我们的软件工程老师布置了一个小组作业：工时填报系统。

并且给出了下图的具体要求



在简单的组队后，我负责第一部分的需求分析，其中包括业务流程、数据分析、数据流分析和原型设计。

老师给我们的信息少之又少，只是让我们做个工时填报系统，以便计算工资和薪酬，而其他信息则几乎没有。这十足让我感觉头大，就好比在实际的项目中，一个客户让你做一个xx管理系统，但是却不进一步描述项目背景和实际业务流程，并且也不和你进行需求验证。

在这样的背景下，结果就出现了很多戏剧性的讨论。比如：签到系统、请假系统、数据分析系统等。这些系统好不好呢？当然好呀。不过我们再回头看具体的要求时，就会发现这些系统几乎没有任何卵用。

每一个项目都是有固定的经费和开发周期的，随意的添加需求，只会让项目延期，经费超支。

我的建议是，围绕客户提出的系统，先实现他所需要的那部分需求。比如工时填报系统，业务逻辑上就是填写某个员工参加某个项目的工时，然后再根据项目工资计算薪酬（我的理解是这样的，实际中需要确认）。有过技术背景的同学，应该知道这个是简单得不能再简单了。

确定了这个需求后，我们再思考和这个需求密不可分的其他需求。与工时填报系统相关的有员工和项目，自然可以想到需要录入员工和录入项目的信息。这时候，我们的需求，则从最初的一个需求，拓展成了三个需求：录入员工信息、录入项目信息、工时填报。

再想下我们为什么要做这个工时填报系统？计算薪酬。对比上面的三个需求，我们的系统显然无法完成客户的目标，因为我们需要再添加一个“统计薪酬”的需求。至此，基本上完成了客户需要我们完成的系统，你可能会说，如果员工离职了，他想修改员工信息，或者工时填写错了，想快速查找具体项目员工，筛选列表该怎么办。这些可能发生么，当然可能，不过客户只需要能够进行工时填报，然后算钱就够了，这是我们的根本目的。而其他功能则要看钱说话~

    关注 后台君