|
⑥是否包含了所有已知的客户需求或系统需求?项目管理者联盟
⑦是否遗漏了必要的信息?⑧是否对所有预期的错误条件所产生的系统行为都编制了文档?项目管理者联盟
需求说明的完整性主要体现在需求说明的详细程度上,怎样判断该需求的描述是否详细呢?笔者认为需求需要精化,而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应等。项目管理者联盟
(4)注意对需求方案的可行性和成本预算进行评审。项目管理者联盟
(5)注意对需求的质量属性进行评审。评审需求规格需要说明是否合理地确定了所有的性能目标,是否合理地确定了安全性方面要考虑到的问题。项目管理者联盟
(6)注意对需求的可实施性进行评审:talent.mypm.net
①是否对每个需求都设置了唯一性并且可以正确地识别它?项目管理者联盟
②是否每个功能需求都可以跟踪到高层需求?项目管理者联盟
需求必须可以测试,每个需求在特定的输入条件下应当能给出已知的输出结果,同时,需求应当层次分明,需要把单个需求下面的相关需求综合在一起形成一组需求功能。需求的可实施性除了可跟踪性还包括可测试性,事实上,分析人员和测试人员在编写代码以前把需求模型,分析模型和测试用例综合起来通盘考虑,检查出遗漏的、错误的和不必要的需求,软件需求在概念上的测试是一种很必要的技术,它可以在项目早期阶段发现需求的歧义和错误。项目管理者联盟
(7)注意对需求包含的用例文档进行评审。用例是参与者对系统和参与者的交互过程所达成的一种契约。需求说明书基于用例的分析方法是也是当前较为流行的需求开发方式。用例文档作为需求重要的成果性文档也是需求评审主体之所在。项目管理者联盟
需求评审确认的重点是对关键用户的最常用和最重要的用例进行深入和细致的评审,首先要通过测试用例的主干过程。而是否撰写有效的用例则要从以下方面着手评审:用例的目标或价值度量是否明确?用例是否是独立的分散任务?项目管理者联盟
是否明确说明可用用例会给哪些参与者带来用处?编写用例的详细程度是否恰当?是否有不必要的设计和实现细节?所有预期的分支过程是否都编写了文档说明?所有预估的异常过程是否都编写了文档说明?是否存在一些普通的动作序列可以分解成独立的用例?blog.mypm.net
每个路径的步骤是否都清晰明了,无歧义而且完整?用例中的每个参与者和步骤是否都与所执行的任务有关?用例中定义的每个可选路径是否都可行和可验证?用例的前置条件和后置条件是否合理?分析师必须确认用例的前置条件和后置条件准确界定了用例的边界范围,区分了用例和用例之间的界限。项目管理者联盟
2·9建立评审流程www.mypm.net
对正规的需求评审会需要建立正规的需求评审流程,按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。项目管理者联盟文章
2·10建立评审制度项目管理者联盟
有效的需求评审,相关的评审制度必不可少,主要有以下方面:项目管理培训
①限制项目内评审员提交有效异常的数量,并纳入考核,必须达到一定数量才算合格;项目管理者联盟
②制定评审的准入准出条件,限制随意通过评审;③质量保证人员参与评审,监督评审进行;④质量保证人员对评审流程进行全程监控。项目管理者联盟文章
2·11的跟踪工作PgMp.mypm.net
在需求评审后,需要根据评审人员提出的问题进行评价,以确定哪些问题是必须纠正的,哪些可以不纠正,并给出充分的客观的理由与证据。项目管理者联盟
当确定需要纠正的问题后,要形成书面的需求变更的申请,进入需求变更的管理流程,并确保变更的执行,在变更完成后,要进行复审。切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。项目管理者联盟 项目管理者联盟
|
