-
2007-12-12
编写软件系统需求 - [工作学习]
版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
1,确定范围:产品定位,此次需求调研的所有范围。 2,掌握几个原则: 从大功能到细节:这似乎符合中国人的习惯,老米们似乎喜欢从细节到抽象的东东。虽然有些限制我们的思维,但能够让我们能够集中思维在一些重要要点上。 从已有功能到已知缺陷:能够平滑升级,并能不断完善已有产品,让用户感受到产品的不断提升。 从用户反馈到竞争对手的信息:用户反馈的基本都是他们平时最关心的问题,一个脱离用户的需求分析报告毫无意义。同时,国内外竞争友商的同类产品也是我们必须考虑的,因为这会让我们不落入另类一族,同时要密切注意国际标准组织制定的一些规范,让自己的产品能按照国际规范来做,比如TMF、ITIL等。 用户体验与技术可行性并重:差劲的用户体验会被用户抛弃,为了实现好的用户体验和特性但是技术上不成熟则会导致你无法短期内提供合格的产品,这样就会错失占领市场的良机。 需求也要分步走:不断完善,逐步迭代,不断推出新特性,这样才能在市场上占领先机。 全民动员:团队里面不可能每个人都去做需求,但不能只让一个人去做需求,应该尽量让更多的人参与进来,每个人可以提点子,每个人参与需求的讨论、评审,这样才能找出需求中不明白的地方和漏洞。但不要所有问题都通过讨论解决,讨论前一定是讨论召集者先拿出一个方案来,否则需求讨论就漫无目标。 需求系统化:需求必须是有系统的,切忌零碎,不要想到一点就写入到文档,最终一定要系统化。 需求文档化:需求文档必须使用统一的格式,建议正式的文档只适用word,必须有明确的修改历史记录。建议提供如下文档:需求范围说明书,需求规格说明书(功能性与非功能性需求),功能点矩阵(excel,方便做开发计划和发布计划)。。。 3,需求分析的几个工具: wiki,blog:需求前期整理的好工具,而且每个人都可以看到。 freemind:整理思路,需求的好东东。 照相机:能够及时将一些思路画在白板上,并拍照下来,作为编写需求和需求讨论的依据。
http://jimsu.yourblog.org/logs/626427.html
随机文章:
java事务处理 2007-08-11新版本终于交付了,一点感受 2007-03-27关于SAN、FC的一些了解 2006-01-20提高性能:cpu与体系架构 2005-11-25程序的可移植性:window,linux,aix,solaris下程序移植体会 2005-05-30
收藏到:Del.icio.us





