需求分析心得

引言

  第一次尝试去开发一个软件,需求分析被给予了极高的重要性,我们的大部分时间可谓都给了需求分析上,这个一个不断破而后立的过程,我们不断地否定自己地想法,之后又不断提出新的点子,收获最多的是耐心和换位思考,也感谢团队伙伴的一路陪伴。

  软件工程,用户即是上帝,我们一切的设计都是为了更好的交互体验,虽然本着我们的项目是为了科研,但是我们也是为了设计而费劲了心思。

心得

  • 更好的体验和技术实现的矛盾

    在需求分析中,尤其是一开始的分析中,我们经常会遇到这个问题,这个需求我们能否实现?一方面是真的这个技术可能现在没有成熟的解决方案,另一方面,囿于我们如今的技术水平,有得需求我们可能没有方法应付,

这时就会去不断地权衡,而且因为需求是我们自己提取,如果有的需求虽然重要性不高,但是的确能为软件增色不少,就会陷入万分地两难地境地。

    提倡方案:

    在做需求分析时,先不要考虑实现地难易程度,只要觉得合理,我们都可以尝试着去写下来,当然如果本来就已经脱离了实际范围地不用考虑,这个好处主要体现在两方面 

      A:你不用长时间去纠结,因为可以更加专注地去提炼需求文档中的内容,思路更加清晰;

      B:虽然在做需求分析时可能看起来有难度的东西,在我们之后的实现中可能通过查阅解决,也就是说我们可以有更多的时间来考虑实现性问题。

  • 需求要求和需求过分细化的矛盾

    这是矛盾场景之二,我们经常会遇到一个需求只要求实现一个大致的功能,但是分析者又会从主观意愿上去补充需求,添加需求,以他认为的方式去让这个项目更加完美,这也是我们经常会遇到的窘境——我们要不要去添加/

    提倡方案:

    不要做一个过分的完美主义者,我们的目标应该是首要放在描述中的功能,而对于完善的功能,就算我们有一些想法,我们也应该先记录下来,然后和需求提供方沟通,确认是可以的在添加,因为你所想的很有可能是和用户背离的,哪怕稍微的歪曲也会变成画蛇添足。

  • 团队想法如何融合

    一个需求文档是由一个团一起去提炼的,1001个读者就有1001个哈姆雷特,团队是思想火花碰撞的地方,所以成员之间的想法也很可能会产生冲突,谁对谁错又会是一个很难权衡的点,或者有因此产生冲突,有时更多会得不偿失。

    提倡方案:

    对于团队中的不同想法,可先暂且记录而不记录上稿,和平的方式是少数服从多数,最好是再去根据指导老师的意见去修改,但是不可以去遏制别人的想法。

 

posted @ 2018-11-23 09:55  顾杰伟  阅读(399)  评论(0编辑  收藏  举报