|
4.3 工作量项目管理者联盟
由开发团队设置，用于管理广度和确定开发优先级。由于有些特征比其他特征要求更多的时间和资源，因此对各特征采用团队数量或人周、代码行、功能点等等进行评估将是预测复杂度的最好办法，从而可对在给定时间范围内能完成什么不能完成什么有一个预期。项目管理者联盟
4.4 风险项目管理者联盟
由开发团队设置，设置的依据是项目经历意外事件的可能性，如成本过高、进度延迟甚至项目被撤消等。许多项目经理发现，把风险分为高、中、低就已经足够了，尽管还可以再细一些。风险通常可以通过度量项目团队进度预测的不确定性（范围）进行间接地评估。项目管理者联盟
4.5 稳定性项目管理者联盟
由分析人员和开发团队设置，设置的依据是特征变更的可能性或团对变更特征的理解。这个信息有助于建立开发优先级或确定下一步中哪些附加启发是适当的。项目管理者联盟
4.6 目标当布项目管理者联盟
记录特征将首先出现在哪一个产品版本中。这个域可用于把特征分配到特定的基线版本中。当把目标版本与状态域结合起来时，团队可以建议、记录和讨论该版本的各个特征，而不必把它们提交给开发。只有一些状态被设置为“收编的”特征并且其目标版本被定义的特征才能实现。在发生广度管理时，目标版本的版本号会不断增加，于是该项仍然存在于前景文档中，但被安排到以后的版本中去。项目管理者联盟
4.7 分配给项目管理者联盟
在许多项目中，把特征分配给“特征团队”，负责进一步启发、书写软件需求和实现。这个简单清单将帮助所有项目团队成员更好地了解自己的职责。项目管理者联盟
4.8 原因club.mypm.net
这一文本域用来跟踪所要求特征的来源。特征的存在有很多特定的理由。这个域记录了特征的解释或对解释的引用。例如，引用可以是产品需求规格说明的页号和行号，或是重要客户面谈录像带上的一个分钟标志。项目经理圈子
5. 产品特征项目管理者联盟
这一部分记录产品特征。特征提供了给用户带来利益所需要的系统能力，每个特征都提供了一个满足用户需要的服务。例如，问题跟踪系统的一个特征可能是“提供走势报告”的能力，趋势报告可能继续支持一个“更好理解项目状态”的需要。bbs.mypm.net
因为前景文档是由许多涉及人员审核的而且是达成共识的基础。所以特征应该用用肪的自然语言描述。特征描述应该简短、精练，通常是1-2个句子。项目管理者联盟
为了有效管理应用的复杂度，我们建议：对于任何新系统或在原有系统上加强的系统，把能力抽象到较高层次产生大约25-99个特征。这些特征是产品定义、广度管理和项目管理的基本基础。每个特征都可以在后面的规格说明中被更详细地说明。项目管理者联盟
在整个这一部分中，每一个特征都应该是用户、操作者或其他外部系统可以感知的。项目管理者联盟文章
5.1 特征＃1项目管理者联盟
5.2 特征＃2PgMp.mypm.net
6. 关键用例club.mypm.net
描述一些关键用例，可以是对体系结构有意义或最方便帮助读者理解系统如何使用的用例。项目管理者联盟
7. 其他产品需求项目管理者联盟
7.1 可应用标准项目管理者联盟
列出产品必须符合的标准，如法律和规章（FDA、FCC）、通信标准（TCP/IP、ISDN）、平台兼容标准（Windows、UNIX）以及质量和安全标准（UL、ISO、CMM）。项目管理者联盟
7.2 系统需求项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
