|
2·5 评审人员选择项目管理培训
需求评审涉及到各层次人员,在进行评审员选择时,一定要将各层次人员都囊括进来,他们可能有用户、需求分析人员、产品经理、项目经理、架构师、概要设计人员、详细设计人员、编码人员、测试人员、质量保证人员等等。bbs.mypm.net
用户在进行需求评审时,关注点更多在于他们所要求的功能是否在软件需求说明书中都囊括进来了;架构师及概要设计人员更多关注的是在现有的技术条件下,是否能够实现需求中的要求,如果无法实现需求或者代价太大,可能就要需求人员与用户沟通更改需求;编码人员可能更多关注于某些细节,例如界面元素等;测试人员主要关注是否所有的需求都是可测试的;质量保证人员关注点在于输出物是否符合规范。各层次人员充分参与,便于他们理解需求,通过需求评审,达成一致意见,不至于需求在不同环节因理解不同而出现偏差。项目管理者联盟
因为各层次人员的立场不同,对同一个问题的看法是不相同的,有些观点是和系统的目标有关系的,有些是关系不大的,不同的观点可能形成互补的关系。如果漏掉某一层次的人员,可能会漏掉很重要的需求。项目管理者联盟文章
2·6 对评审人员进行培训bbs.mypm.net
常常见到有的项目的需求评审会议在主持人进行需求讲解时,与会人员似懂非懂,没有提出有价值的问题,致使会议没有取得预期的效果,不得不改日重新进行。有的项目的需求评审会议针对某一个细节问题与会人纷纷提出自己的意见,大家争执不下,结果,会议出现了混乱状况,主持人无法控制局面,致使会议大大超出了计划评审时间。因为各层次评审人员关注点不同,评审也需要技巧、把握关键点,因此,应该对各层次评审人员进行有针对性的培训。以便于参与评审的人员能够紧紧围绕评审的目标来进行,能够控制评审活动的节奏,提高评审效率。项目管理者联盟
2·7 给予评审员充足的评审时间项目管理培训
实践证明,需求的异常往往存在于细节方面,评审员理解软件需求又需要一个过程,要想找到这些异常,必须有充足的时间,以便充分理解需求、找出其中的缺陷,提出可行性建议。因此,从需求讲解到非正式评审再到正式评审,需要预留足够的时间。service.mypm.net
如果评审员是项目中的成员,项目负责人需要给项目成员专门下达需求评审的时间,如果评审员只能额外抽时间来研究需求,恐怕只能简单提几条质量不高的异常了事。评审自然也就达不到预期的目的。实践证明,在需求评审上多花一些实践是值得的,所谓“磨刀不误砍柴工”。项目经理博客
2·8把握需求评审的关键点项目经理博客
(1)注意对软件需求说明书的正确性进行评审。需求规格说明的正确性通常可以从如下方面得以体现:项目管理者联盟
①是否有需求与其他需求相互冲突或者重复?项目管理者联盟
②是否清晰、简洁、无二义地表达了每个需求(“清晰”是让人能够读懂;“简洁”是让人愿意去读;“无二义”决定“读”的效果,是让大家对需求描述的理解能够达成一致)?项目经理博客
③是否每个需求都通过了演示、测试、评审,分析是否得到了验证?项目管理者联盟
④是否每个需求都在项目的范围内?项目管理者联盟
⑤是否每个需求都没有内容和语法上的错误?项目管理者联盟
⑥在现有的资源内,是否能实现所有的需求?项目管理者联盟
⑦每一条特定的错误信息,是否都是唯一的和具有含义的?项目管理者联盟
(2)注意对软件需求说明书的实践性进行评审。所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。项目管理者联盟
(3)注意对需求规格说明书的完整性进行评审。可由下面的问题清单来评审需求说明书是否“完整”:项目管理者联盟
①编写的所有需求,其详细程度是否一致和合适?pmp.mypm.net
②需求是否能为设计提供足够的基础?项目经理博客
③所有对其他需求的内部引用是否正确?www.mypm.net
④是否包含了每个需求的实现优先级?项目管理者联盟
⑤是否定义了功能说明的内在算法?转自项目管理者联盟
|
