从需求分析看软件开发的挑战

软件工程：2.从需求分析看软件开发的挑战

1. 背景：

从第一节课带着本科时对软件工程的三脚猫功夫，选题：基于家庭工厂的订单协作系统，随缘的组队，到现在课程过半，我们让自己较为满意的完成了需求分析。我们已经走过了软件工程的前两个步骤，领域分析和需求分析。在此将过程中的感悟和收获梳理总结。

2. 心路历程：

2.1. 选择题目：

基于家庭工厂的订单协作系统：典型的生活日用品制造业往往由一组家庭式工厂协同配合，共同生产和组装，完成最终订单。系统有几个关键功能：下单(接单)、订单分解、订单分配、订单进度追踪、订单完成风险评估、订单完成效果分析等。要求实现基于网页或手机端的系统。

最初我选择这个题目的初心：选择一个相对简单的项目，能够利用课上所学，从分析到实现，能全过程走完，对真实开发场景下的全流程有基本认识就算成功。现在应该还没有偏离路线。

2.2 领域分析：

当我们选定后题目后，先针对系统是什么进行了讨论。这里主要借助老师提供的模版，让我们有较为明确的思考和讨论方向。

第一次讨论时，我们大致对我们的系统是什么有了基础的认识，但没有记录并同一术语，这为后来的讨论以及分工协作的合成埋下了隐患，增加了我们讨论的成本，过程中的记录是尤为关键的，对关键的讨论结果要有记录，回顾起来，在每次会议前，应该明确会议的议程，需要的关键产出和讨论结果，并且轮流担任记录的方式，这样可能会使合作更加高效。

最初对系统的理解，包括在头几次讨论时，还局限在我们作为一个提供软件解决方案的公司，根据客户需求为他们定制这样一个系统，所有讨论也完全是从需求和功能出发，而忽视了系统的核心价值。

这和真实场景可能类似，一家公司想做这个系统，找我们来做，已经有了一些构想和关键功能的要求，从服务商的角度出发，很容易陷入【完成用户提出的需求即可，而不在乎是否帮用户实现了价值】，这在一开始顺着客户的思路走可能较为简单，易于开展工作，但实际我们发现，用户提出的需求可能并不能很好的满足其核心价值，因此这样的需求易于变动，因此在领域分析时，应当充分思考对于这个领域，我所设计的系统的核心价值在哪里。

除此之外，在实际生产中，为了确保我自己的利益，我是否需要充分为客户着想，还是满足其要求即可，也是软件开发的挑战。这也涉及到我们对系统的定价，在上周的课程中，也进行了讨论。

理想情况下，我们应当充分从客户角度出发，分析出系统的核心价值，为客户最大化利益，从而实现我系统的价值，赚取最大的利润，但这未必能在真实生产中的复杂博弈下开展。

2.3 需求分析：

在认识到我们系统的价值后，核心的用例就是需求拆解和体现，我们首先通过用例图明确了核心用例，对于关键用例，我们采用集体讨论而非分工，从用例和核心业务流程出发，通过状态图梳理并用例规约梳理出业务主流程，此时术语的不规范，让我们沟通多次出现问题，导致理解的偏差，使得有些部分反复讨论在最终明确。

在类图的设计上，可谓绞尽脑汁，一方面是经验不足，另一方面一些用例的具体细节在未讨论清楚之前，类图是不知道怎么设计的。我们在这一部分投入了相当多的时间，大家齐心协力，才最终统一并得到了一个符合直觉和逻辑的设计。

这里我发现核心的困难在于随着细节的进入，使所有人同步变得异常困难，这需要严格的术语规范，并且合理的会议管理，否则一旦走神，很可能会使后续工作出现偏差。

另外，相对于我们这个小项目尚且如此，对于庞大的系统，每个人需要从哪个粒度清晰理解系统也是关键，让所有人对设计的全部内容充分理解并形成统一是不现实的，这一点我们还没有找到合适的解决方法，直觉上，这对工作的划分有很高的要求。

2.4 后续工作

后面进入设计阶段，我们有了一些经验后，采用了前后端分离scram的开发模式，明确了分工，我负责一部分前端工作，统一了技术栈，然后开始设计接口。这个阶段又是全新的挑战。

3. 感想

确实很不容易，坚持听课、听懂再实践需要很强的意志力。据我观察，我们组可能是唯一一个每次课都能全员到场并听课的组吧。当然这也不是评判工作的很好标准，课下投入的时间还是最关键的因素。

非常幸运的遇到我的队友们，很感动，我们互为动力，走到了这个阶段，我也要继续加油呀。