Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1040765
  • 博文数量: 46
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1701
  • 用 户 组: 普通用户
  • 注册时间: 2013-07-24 10:06
文章分类
文章存档

2014年(19)

2013年(27)

分类: WINDOWS

2013-09-12 11:52:12

作为开发人员,参见一些需求开发的培训还是有益处的,参加了一次需求开发技巧培训,结合自己的体会写写需求开发的一些事。


 1.影响软件项目失败的因素(需求方面)

》过少的信息输入:用户方对项目缺乏认识,开发方缺乏规划

》不完整需求:行业领域知识匮乏,需求开发人员经验不足,前期准备不充分

》需求变更:目标定位不清晰,行业标准不清晰

  软件项目在开发过程中一定的需求变更是正常的,开发人员和设计人员自然要考虑到这些可以预知的必然因素,作为开发人员在实现功能模块遵照单一职责的准则下,也不能抛弃模块之间必然的耦合关系,开发过程中自然要有良好的编码,既做到高内聚,低耦合,也做到灵活的可扩展。

》技术缺乏

  关于技术缺乏的理由很可能作为推卸责任的说辞。

  技术缺乏个人理解有两个含义:

  第一,开发团队中确实缺少对应项目涉及到的关键性技术;

  第二:开发团队中的技术没能正确,合适的应用到项目开发。

  技术缺乏这一个因素中也包含有需求开发的技术。

》人力缺乏

  人力缺乏和技术缺乏有着同样的推卸责任的功能,而且人力缺乏一直是个不可弥补的缺口。

  团队的资源配置中:技术配置,人力配置的最佳,有效才有可能避免人力匮乏,当然这两点不是那么轻而易举的就做到,毕竟操作的是人,而对于事情来讲最终的操控者还是人,当人在其中起到了核心位置的时候,事情就由简至繁了。

》其他种种因素

 2.需求开发

》三个面向

  面向高层次的软件目标:业务需求

  面向使用系统的用户:用户需求

  面向开发人员:需求规格

》需求开发技术

  访谈,焦点小组会议,引导式探讨会(跨职能会议),群体创新技术。

  群体创新技术:头脑风暴,名义小组技术,德尔菲技术(主观意识,匿名信息,保持独立);概念与思维导图。

》需求调用范围

  不同的项目需求的调研范围有不同之处,下面列出一些方面作为参考。

      功能需求:关注业务,量化功能指标,用户,约束

      UI需求: 行业色调,感观,用户体验

      交互性需求:交互性越来越成为一个产品或者系统受欢迎的重要因素。

      易用性:在视觉,操作,理解,业务上都应保持方便,便捷,尊重习惯。

      并发需求:考虑的系统的服务能力,架构设计,服务器组建(成本和利润的权衡)

      可靠性需求:单位时间内的故障率

  需求调用的范围可能很广,但核心去很确定,为下一步系统的开发产出可靠的,清晰的,完整的需求规格说明书。

3.特别体会

》并发需求开发技巧:

  A=系统用户数,B=系统同时在线用户数,C=并发用户数

  一次培训的一位需求开发人员给出的经验数据:

B=A*20%;           C=B*30%;         C=A*6%

》交互需求开发技巧

  周鸿祎提出一个叫“微创新”的概念,最近反复在思考这个概念,自己用过不少互联网产品,无论是移动设备,还是PC上的,喜欢的,习惯的那么些公司的产品似乎都能找到极其相似甚至相同的地方,却又有微妙中的不同。我想很多朋友也有这样的体会吧。

  正所谓在模仿中创新。

  关于交互需求列出几点:

      交互与UI的关联。使用现有的UI风格,遵循行业风格,注重系统使用场景,注意使用者的群体特征。良好的UI是人们愿意花时间与系统产生交互的基础。

      参考已有产品,有针对性的参考。

      减少界面跳转,有友好的界面提示

      交互要遵循已有的标准,或者既成事实的标准。

  例如: [1.png] 收藏图标;按键F1帮助; [2.png] 返回页面顶部;Ctrl+S(*)系列的快捷键操作;

移动平台上: [1.png] WIFI图标 [2.png] 浏览器类型图标。

       交互是需求开发中的重要组成部分,应该有专业的交互设计师来和需求开发人员完成。


  俗话讲,万事开头来,需求开发作为一个项目的开始,其在整个项目进程中扮演开拓者的角色,同时对于项目的进展,这一环节至关重要,可以说是项目的生命起源,护好源头才能持久清澈。


阅读(1576) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~