引言
第一次尝试去开发一个软件，需求分析被给予了极高的重要性，我们的大部分时间可谓都给了需求分析上，这个一个不断破而后立的过程，我们不断地否定自己地想法，之后又不断提出新的点子，收获最多的是耐心和换位思考，也感谢团队伙伴的一路陪伴。
软件工程，用户即是上帝，我们一切的设计都是为了更好的交互体验，虽然本着我们的项目是为了科研，但是我们也是为了设计而费劲了心思。
心得
-
更好的体验和技术实现的矛盾
在需求分析中，尤其是一开始的分析中，我们经常会遇到这个问题，这个需求我们能否实现？一方面是真的这个技术可能现在没有成熟的解决方案，另一方面，囿于我们如今的技术水平，有得需求我们可能没有方法应付，
这时就会去不断地权衡，而且因为需求是我们自己提取，如果有的需求虽然重要性不高，但是的确能为软件增色不少，就会陷入万分地两难地境地。
提倡方案：
在做需求分析时，先不要考虑实现地难易程度，只要觉得合理，我们都可以尝试着去写下来，当然如果本来就已经脱离了实际范围地不用考虑，这个好处主要体现在两方面
A：你不用长时间去纠结，因为可以更加专注地去提炼需求文档中的内容，思路更加清晰；
B：虽然在做需求分析时可能看起来有难度的东西，在我们之后的实现中可能通过查阅解决，也就是说我们可以有更多的时间来考虑实现性问题。
-
需求要求和需求过分细化的矛盾
这是矛盾场景之二，我们经常会遇到一个需求只要求实现一个大致的功能，但是分析者又会从主观意愿上去补充需求，添加需求，以他认为的方式去让这个项目更加完美，这也是我们经常会遇到的窘境——我们要不要去添加/
提倡方案：
不要做一个过分的完美主义者，我们的目标应该是首要放在描述中的功能，而对于完善的功能，就算我们有一些想法，我们也应该先记录下来，然后和需求提供方沟通，确认是可以的在添加，因为你所想的很有可能是和用户背离的，哪怕稍微的歪曲也会变成画蛇添足。
-
团队想法如何融合
一个需求文档是由一个团一起去提炼的，1001个读者就有1001个哈姆雷特，团队是思想火花碰撞的地方，所以成员之间的想法也很可能会产生冲突，谁对谁错又会是一个很难权衡的点，或者有因此产生冲突，有时更多会得不偿失。
提倡方案：
对于团队中的不同想法，可先暂且记录而不记录上稿，和平的方式是少数服从多数，最好是再去根据指导老师的意见去修改，但是不可以去遏制别人的想法。