经过这一段时间的需求分析及确定过程，我们终于明白关于需求的一句话——变化是永远不变的。
在一段时间的摸索后，我们才明白了这个实践项目最重要的一点——满足课程需求。在完成这个项目需求的确定过程中，在小班讨论课以及和各个PM的了解下，发现了一个重要的问题：
如何在保证工作量
在和老师进行两次讨论过后，我们能够确立了本项目所需要做的内容——一个*承办的满足能将二手房进行挂牌，并且能够搜索到已经挂牌的二手房信息的平台，对用户来说可以将房子信息挂牌，并且附加详细信息。个人可以对已挂牌的房子进行搜索，收藏，对房子信息进行提问。需求是清楚的，但这只是项目知道老师给我们的需求，但对本次实践课程来说需求可能略显单薄，也就是“工作量不够”。
这个时候，我们开始面临一个问题——如何增加需求。我们一开始想了两个比较大的方面：中介监管以及交易流程，也就是网签。
但是对网签流程来说，一是我们对整个二手房网签流程不太熟悉，二是整个过程牵涉到的机构比较多，随之而来的就是需要许多的确认以及核验的过程，对我们来说业务流程不太熟悉，同时可能做出来之后不太符合实际情况，也没有真实的接口给我们调用，所以这个业务被我们否决了。
既然不做交易流程，同时是一个*主办的网站，自然而然存在中介监管这一部分的内容。我们上网搜索参考了相关的二手房交易监管网站。在看到了杭州的二手房交易监管网站之后，发现可以加以借鉴。他的功能主要是除了以上用户功能外，新增了*后台对已注册中介进行管理，包括资格审核、人员公示、管理公式、红黑名单等。用户还可以对自己签约的中介进行评价。用一句话来讲，这一部分就是自己给自己加需求，让自己的项目满足课程要求，同时我们还要评估我们增加的需求我们自己到底可不可以完成，还要符合真实情况，这着实有些让人头疼。
所以本次项目经历的过程就是：第一次讨论后定下个人、中介、*监管+交易三个模块功能——》第二次和老师交流后删减只剩下个人——》发现工作量太少再重新变为个人、中介、*三方，将比较难实现且交易流程不熟悉的交易模块删去。
经过漫长的一段时间，我们小组的需求终于确定下来了。附用例图一张
这样的需求确认的过程也能模拟一定的真实情况吧，也就是需求不断变动的情况，因此更加凸显了确认需求的重要性。
同时在这个过程中另一个非常重要的部分就是分工。让每个人都明白自己在这个小组中都要干什么，这样到后面编码的时候才不会出现理解上的偏差，才不会出现没人干活的情况。