如何掌控需求变更

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/weixin_37810764/article/details/87813511
                                   **如何尽量减少需求变更**

本人在开展项目管理期间,针对项目管理中遇到的常见问题进行总结和分析。本着与大家进行分享知识的想法,同时也希望大家能够提出自己的建议。详细内容入下:

一、 需求调研

  1. 需求调研时,应首先明确客户提出需求的背景、原因和愿景;
  2. 调研需求应该首先明确系统类型(PC端、移动端和Web端),其次明确系统架构设计,然后明确功能模块分类、功能点,最后明确功能点的详细设计;
  3. 确认功能需求时,对需求功能点进行详细的记录,并明确需求的提出人,方便后续需求的跟踪和跟进;
  4. 需求调研时,应该参考功能内部、竞品或者相似产品的功能进行整体规划和设计,保障需求调研充足,需求设计无死角。
    二、 需求确认
  5. 确认功能界面时,依次采取草稿、简单界面效果图、高精度界面效果图进行确认需求,最大限度的减少需求确认消耗的时间;
  6. 需求确认后,应该由相应的客户或者专家进行签字确认,避免出现需求反复变更但是无人承认的情况;
    三、 需求变更
  7. 需求变更只能无限减少,但是无法真正避免或者消除。面对需求变更应该放平心态;
  8. 需求出现变更时,首先对需求变更内容进行调研,明确需求产生的原因等内容;
  9. 首先自己确认变更后的需求是否具有实用化的必要,区分是否是伪需求。需求变更后的需求是否有其他方式或者其他功能可以用来实现;
  10. 针对变更的需求,需要由项目相关人员进行需求评审,确认需求是否有必要开展以及需求细节;
  11. 针对确认要开展的变更需求,需要签订需求变更确认单,并由相关人员签字确认;
  12. 没有签字确认的需求,不开展。
    四、 工作开展期间
  13. 工作开展之前,与客户和相关需求提出人确认开展;
  14. 功能需求发布之前,与客户端和相关需求提出人确认功能是否满足需求。

以上仅为个人工作中的一些做法,请大家不吝赐教。

展开阅读全文

需求变更

03-28

关于需求变更对软件结构的冲击,我想如果使用面向对象方法效果会好一些。Yourdon在《Object Oriented Analysis》中有一个被人广泛引用的结论。就是对于软件结构言,最容易变化的首先是流程,其次是接口,在次是对象的属性,最后才是对象本身。拿一个单位的人事管理系统来举例子,最容易变的肯定是流程,单位的一道文件就可能改变比如入职,辞职,调动等等流程。接口的易变性要小一点,比如原来的脱机接口变成联机接口,增加一些额外的用户界面,报表生成等等。对象的属性(包括对象之间的关系)其实就很不容易变动了,在现实世界中增加的情况比较多,如果此系统要进行移植,比如从国企到外企,对象属性要进行比较大的变动,但是对象和对象的基本属性是非常稳固的,任何企业,雇主和雇员,上级和下级,工作,报酬等等对象是一定要存在的,对象的状态,对于雇员,入职,离职,请假,生病,这些状态和状态转移关系,是具有一定普遍性的。rn 系统分析员如果能抓住系统中这些稳固的部分,并且加以很好抽象和封装,在应对需求变化的时候,就会从容得多,当然,西谚有云“不要认为递给一个傻瓜一把锤子,他就会成为一个建筑师”,能否构建稳定的系统模型是衡量系统分析员的一个重要的方面。需求的不断变化,是系统分析员永远要面对的挑战,我想,这也是系统分析工作的魅力之所在。rn 论坛

没有更多推荐了,返回首页