项目集成时需求与其他项目过程的沟通方法
本文来源:未知 发布日期:2014-11-19
需求是软件项目成功的核心所在,它为其他许多技术、管理活动奠定了基础。变更你的需求开发和管理方法将对其他项目过程产生影响.
1) 制定项目计划需求是制定项目计划的基础。因为开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。通常,项目计划指出所有希望的特性不可能在允许的资源和时间内完成,因此,需要缩小项目范围或采用版本计划对功能特性进行选择。
2) 项目跟踪和控制监控每项需求的状态,以便项目管理者能发现设计和验证是否达到预期的要求。如果没有达到,管理者通常请求变更控制过程来进行范围的缩减。
3) 变更控制在需求编写成文档并制定基线以后,所有接下来的变更都应通过确定的变更控制过程来进行。变更控制过程能确保:
变更的影响是可以接受的。
受到变更影响的所有人都接到通知并明白这一点。
由合适的人选来作出接受变更的正式决定。
资源按需进行调整。
保持需求文档是最新版本并是准确的更新文档。
4) 系统测试用户需求和功能需求是系统测试的重要参考。如果未说明清楚产品在多种多样条件下的期望行为,系统测试者将很难明确正确的测试内容。反过来说,系统测试是一种方法,可以验证计划中所列的功能是否按预期要求实现了。同时,也验证了用户任务是否能正确地执行。
5) 用户编制文档我曾在一个办公室里工作,办公室里有为商业产品准备用户文档的技术写作人员。我咨询其中一位写作人员为什么他们要工作那么长时间。“我们是食物链的终结者”她回答道,“我们要编写出用户显示界面及性能的最终变更版本”。产品的需求是编写文档的重要参考,低质量和拖延的需求会给编写用户文档带来极大的困难。
6) 构造软件项目主要产品是交付可执行软件,而不是需求说明文档。但需求文档是所有设计、实现工作的基础。要根据功能要求来确定设计模块,而模块又要作为编写代码的依据。采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和是否满足了相关的需求。跟踪每项需求与相应的设计和软件代码。
1) 制定项目计划需求是制定项目计划的基础。因为开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。通常,项目计划指出所有希望的特性不可能在允许的资源和时间内完成,因此,需要缩小项目范围或采用版本计划对功能特性进行选择。
2) 项目跟踪和控制监控每项需求的状态,以便项目管理者能发现设计和验证是否达到预期的要求。如果没有达到,管理者通常请求变更控制过程来进行范围的缩减。
3) 变更控制在需求编写成文档并制定基线以后,所有接下来的变更都应通过确定的变更控制过程来进行。变更控制过程能确保:
变更的影响是可以接受的。
受到变更影响的所有人都接到通知并明白这一点。
由合适的人选来作出接受变更的正式决定。
资源按需进行调整。
保持需求文档是最新版本并是准确的更新文档。
4) 系统测试用户需求和功能需求是系统测试的重要参考。如果未说明清楚产品在多种多样条件下的期望行为,系统测试者将很难明确正确的测试内容。反过来说,系统测试是一种方法,可以验证计划中所列的功能是否按预期要求实现了。同时,也验证了用户任务是否能正确地执行。
5) 用户编制文档我曾在一个办公室里工作,办公室里有为商业产品准备用户文档的技术写作人员。我咨询其中一位写作人员为什么他们要工作那么长时间。“我们是食物链的终结者”她回答道,“我们要编写出用户显示界面及性能的最终变更版本”。产品的需求是编写文档的重要参考,低质量和拖延的需求会给编写用户文档带来极大的困难。
6) 构造软件项目主要产品是交付可执行软件,而不是需求说明文档。但需求文档是所有设计、实现工作的基础。要根据功能要求来确定设计模块,而模块又要作为编写代码的依据。采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和是否满足了相关的需求。跟踪每项需求与相应的设计和软件代码。