项目管理7-软件需求管理

1、软件需求管理周周 立立 新新 博士博士北京大学软件与微电子学院北京大学软件与微电子学院业务需求业务需求用户需求用户需求系统需求系统需求功能需求功能需求质量属性质量属性其他非功能需求其他非功能需求约束条件约束条件项目视图与范围文档项目视图与范围文档使用实例文档使用实例文档软件需求规格说明软件需求规格说明用户能有效的纠正文档中的拼写错误用户能有效的纠正文档中的拼写错误找出文档中的拼写错误并通过一个提供找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。的替换项列表来供选择替换拼错的词。找到并高亮度提示错词；找到并高亮度提示错词；显示提供替换词的对话框以及显示提供替换词的对话框以及实

2、现整个文档范围的替换。实现整个文档范围的替换。需求工程需求工程需求工程需求管理需求开发编写规格说明分析问题获取验证包括包括软件类产品软件类产品中需求收集、评中需求收集、评价、编写文档等价、编写文档等所有活动所有活动 建立并维护在软建立并维护在软件工程中同客户件工程中同客户达成的契约达成的契约 l确定产品所期望的用户类。确定产品所期望的用户类。l获取每个用户类的需求。获取每个用户类的需求。l了解实际用户任务和目标以及这些任了解实际用户任务和目标以及这些任务所支持的业务需求。务所支持的业务需求。l分析源于用户的信息以区别用户任务分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属需求、

3、功能需求、业务规则、质量属性、建议解决方法和附加信息。性、建议解决方法和附加信息。l将系统级的需求分为几个子系统，并将将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。需求中的一部份分配给软件组件。l了解相关质量属性的重要性。了解相关质量属性的重要性。l商讨实施优先级的划分。商讨实施优先级的划分。l将所收集的用户需求编写成规格说明和将所收集的用户需求编写成规格说明和模型。模型。l评审需求规格说明，确保对用户需求达评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。组接受说明之前将问题都弄清楚。 定义需

4、求基线（迅速制定需求文档定义需求基线（迅速制定需求文档的主体）。的主体）。 评审提出的需求变更、评估每项变评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。更的可能影响从而决定是否实施它。 以一种可控制的方式将需求变更融以一种可控制的方式将需求变更融入到项目中。入到项目中。 使当前的项目计划与需求一致。使当前的项目计划与需求一致。 估计变更需求所产生影响并在此基估计变更需求所产生影响并在此基础上协商新的承诺（约定）。础上协商新的承诺（约定）。 让每项需求都能与其对应的设计、让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现源代码和测试用例联系起来以实现跟踪。跟踪。 在整个

5、项目过程中跟踪需求状态及在整个项目过程中跟踪需求状态及其变更情况。其变更情况。基准需求说明基准需求说明分析分析编写文档编写文档评审、商议评审、商议需求变更过程需求变更过程市场市场需求需求客户客户管理管理市场市场客户客户管理管理项目环境项目环境当前基线当前基线需求开发需求开发需求管理需求管理修正后基线修正后基线需求变更需求变更项目变更项目变更需求开发与需求管理之间的界限需求开发与需求管理之间的界限需求开发与需求开发与管理之间的管理之间的界线界线1. 需求管理活动需求管理活动CMMI中需求管理的流程图中需求管理的流程图 结束结束开始开始制定需求管理计划制定需求管理计划求求得得对对需需求求的的理理解

6、解求求得得对对需需求求的的承承诺诺维护对需求的双向追踪性维护对需求的双向追踪性 组织的总体方针组织的总体方针需求管理模板需求管理模板管理需求变更管理需求变更识别项目工作与需求之间的不一致性识别项目工作与需求之间的不一致性1.1 版本控制版本控制l需求文档的每一个版本必须被统一确定。需求文档的每一个版本必须被统一确定。l组内每个成员必须能够得到需求的当前版组内每个成员必须能够得到需求的当前版本。本。l必须清楚地将变更写成文档，并及时通知必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。到项目开发所涉及的人员。l为了尽量减少困惑、冲突、误传，应仅允为了尽量减少困惑、冲突、误传，应仅允许指

7、定的人来更新需求。许指定的人来更新需求。 需求的属性需求的属性l创建需求的时间创建需求的时间l需求的版本号需求的版本号l创建需求的作者创建需求的作者l负责认可该需求的人员负责认可该需求的人员l需求状态需求状态l需求的原因或根据（或信息的出处）需求的原因或根据（或信息的出处）l需求涉及的子系统需求涉及的子系统l需求涉及的产品版本号需求涉及的产品版本号l使用的验证方法或接受的测试标准使用的验证方法或接受的测试标准l产品的优先级或重要程度（例如高、中、低或）产品的优先级或重要程度（例如高、中、低或）l需求的稳定性（在将来需求可能变更的指示器，不稳定的需求的稳定性（在将来需求可能变更的指示器，不稳定的

8、需求意味你应给予较多的关注，因为你将面临不定的、混需求意味你应给予较多的关注，因为你将面临不定的、混沌的、或不能重复的业务过程。）沌的、或不能重复的业务过程。）建议的需求状态表建议的需求状态表 状态值状态值 定定 义义 已建议已建议该需求已被有权提出需求的人建议该需求已被有权提出需求的人建议已批准已批准该需求已被分析，估计了其对项目余下部分的影响（包括成该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现或创建编号分配到相关的基线中，软件开

9、发团队已同意实现该项需求该项需求已实现已实现已实现需求代码的设计、编写和单元测试已实现需求代码的设计、编写和单元测试已验证已验证使用所选择的方法已验证了实现的需求，例如测试和检测，使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成审查该需求跟踪与测试用例相符。该需求现在被认为完成已删除已删除计划的需求已从基线中删除，但包括一个原因说明和做出删计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员除决定的人员 已拒绝已拒绝状态跟踪示例状态跟踪示例1.2 需求变更管理需求变更管理 l应仔细评估已建议的变更应仔细评估已建议的变更 。l挑选

10、合适的人选对变更做出决定。挑选合适的人选对变更做出决定。l变更应及时通知所有涉及的人员。变更应及时通知所有涉及的人员。l项目要按一定的程序来采纳需求变更。项目要按一定的程序来采纳需求变更。控制项目范围的扩展控制项目范围的扩展 l扩展需求是指在软件需求基线已经确定后扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。又要增添新的功能或进行较大改动。l问题不仅仅是需求变更本身，而是迟到的问题不仅仅是需求变更本身，而是迟到的需求变更会对已进行的工作有较大的影响。需求变更会对已进行的工作有较大的影响。l要是每个建议的需求都被采纳，对于项目要是每个建议的需求都被采纳，对于项目出资者（出资

11、者（sponsor）、参与者与客户来说）、参与者与客户来说项目将永远也不会完成项目将永远也不会完成事实上，这是不事实上，这是不可能的。可能的。 控制项目范围的扩展控制项目范围的扩展l对许多项目来说，一些需求的改进是合理的且不对许多项目来说，一些需求的改进是合理的且不可避免。可避免。l业务过程、市场机会、竞争性的产品和软件技术业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的，管理部门也会决在开发系统期间是可以变更的，管理部门也会决定对项目做出一些调整。定对项目做出一些调整。l在你的项目进度表中应该对必要的需求改动留有在你的项目进度表中应该对必要的需求改动留有余地。余地。l若不

12、控制范围的扩展将使我们持续不断地采纳新若不控制范围的扩展将使我们持续不断地采纳新的功能，而且要不断地调整资源、进度、或质量的功能，而且要不断地调整资源、进度、或质量目标，这样做极其有害。目标，这样做极其有害。 管理范围扩展管理范围扩展l管理范围扩展的第一步就是把新系统的视图、范管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分。围、限制文档化并作为业务需求的一部分。l评估每一项建议的需求和特性，将它与项目的视评估每一项建议的需求和特性，将它与项目的视图和范围相比较决定是否应该采纳它。图和范围相比较决定是否应该采纳它。l强调客户参与的有效的需求获取方法能够减少遗强调客

13、户参与的有效的需求获取方法能够减少遗漏需求的数量，只在做出提交承诺和分配资源后漏需求的数量，只在做出提交承诺和分配资源后才采纳该需求。才采纳该需求。l控制需求扩展的另一个有效的技术是原型法，这控制需求扩展的另一个有效的技术是原型法，这个方法能够给用户提供预览所有可能的实现，以个方法能够给用户提供预览所有可能的实现，以帮助用户与开发者沟通从而准确把握用户的真实帮助用户与开发者沟通从而准确把握用户的真实需求。需求。要敢于说要敢于说“不不”。 变更控制策略变更控制策略 l所有需求变更必须遵循的过程，按照此过程，如果一所有需求变更必须遵循的过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以

14、考虑。个变更需求未被采纳，则其后过程不再予以考虑。l对于未获批准的变更，除可行性论证之外，不应再做对于未获批准的变更，除可行性论证之外，不应再做其它设计和实现工作。其它设计和实现工作。l简单请求一个变更不能保证能实现变更，要由项目变简单请求一个变更不能保证能实现变更，要由项目变更控制委员会（更控制委员会（ C C B）决定实现哪些变更。）决定实现哪些变更。l项目风险承担者应该能够了解变更数据库的内容。项目风险承担者应该能够了解变更数据库的内容。l绝不能从数据库中删除或修改变更请求的原始文档。绝不能从数据库中删除或修改变更请求的原始文档。l每一个集成的需求变更必须能跟踪到一个经核准的变每一个集成

15、的需求变更必须能跟踪到一个经核准的变更请求。更请求。 简单变更控制步骤模板简单变更控制步骤模板 l绪论绪论l目的目的l范围范围l定义定义l角色和责任角色和责任l变更请求状态变更请求状态l开始条件开始条件l任务任务l产生变更请求产生变更请求l评估变更请求评估变更请求l作出决策作出决策l通知变更人员通知变更人员l验证验证l结束条件结束条件变更管理活动中可能的项目角色变更管理活动中可能的项目角色 角角 色色描述及责任描述及责任 变更控制委员会变更控制委员会主席主席变更控制委员会的主席，在变更控制委员会的主席，在C C BC C B意见不一致情况下可意见不一致情况下可以独自做出决定以独自做出决定CCB

16、决定采纳或拒绝针对某项目所建议的变更请求的团体决定采纳或拒绝针对某项目所建议的变更请求的团体评估者评估者应项目管理者要求分析所建议的变更带来影响的人员应项目管理者要求分析所建议的变更带来影响的人员修改者修改者负责实现已经被认可的请求变更，按时更新变更状态负责实现已经被认可的请求变更，按时更新变更状态的人员的人员建议者建议者提交新变更请求的人提交新变更请求的人项目管理者项目管理者负责指定评估者和修改者的人员负责指定评估者和修改者的人员请求接受者请求接受者接受提交变更请求的人接受提交变更请求的人验证者验证者负责决定变更是否正确执行的人负责决定变更是否正确执行的人 变更控制委员会的组成变更控制委员会

17、的组成 l产品或计划管理部门。产品或计划管理部门。l项目管理部门。项目管理部门。l开发部门。开发部门。l测试或质量保证部门。测试或质量保证部门。l市场部或客户代表。市场部或客户代表。l制作用户文档的部门。制作用户文档的部门。l技术支持部门。技术支持部门。l帮助桌面或用户支持热线部门。帮助桌面或用户支持热线部门。l配置管理部门。配置管理部门。 常见变更请求数据项常见变更请求数据项 变更需求状态转换图 测量变更活动测量变更活动 l接收、未作决定、结束处理的变更请求的接收、未作决定、结束处理的变更请求的数量。数量。l已实现需求变更（包括增、删、改）的合已实现需求变更（包括增、删、改）的合计数量（也可

18、以用在基线上占需求总数的计数量（也可以用在基线上占需求总数的百分比来表示）。百分比来表示）。l每个方面发出的变更请求的数量。每个方面发出的变更请求的数量。l每一个已应用的需求（是指已划过基线）每一个已应用的需求（是指已划过基线）建议变更和实现变更的数量。建议变更和实现变更的数量。l投入处理变更的人力、物力。投入处理变更的人力、物力。 工作量工作量（劳动时数）（劳动时数） 任务任务_ _ 更新软件需求规格说明书或需求数据库更新软件需求规格说明书或需求数据库_ _ 开发并评估原型开发并评估原型_ _ 创建新的设计部件创建新的设计部件_ _ 修改已有的设计部件修改已有的设计部件_ _ 开发新的用户界

19、面部件开发新的用户界面部件_ _ 修改已有的用户界面部件修改已有的用户界面部件_ _ 开发新的用户文档和帮助文件开发新的用户文档和帮助文件_ _ 修改已有的用户文档和帮助文件修改已有的用户文档和帮助文件_ _ 开发新的源代码开发新的源代码_ _ 修改已有的源代码修改已有的源代码_ _ 购买和集成第三方软件购买和集成第三方软件_ _ 修改构造文件修改构造文件_ _ 开发新单元测试和综合测试开发新单元测试和综合测试_ _ 进行单元测试和综合测试进行单元测试和综合测试_ _ 写新的系统测试实例写新的系统测试实例_ _ 修改已有的系统测试实例修改已有的系统测试实例_ _ 修改自动测试驱动程序修改自动测

20、试驱动程序_ _ 进行回归测试进行回归测试_ _ 开发新报告开发新报告_ _ 修改已有的报告修改已有的报告_ _ 开发新的数据库元素开发新的数据库元素_ _ 修改已有的数据库元素修改已有的数据库元素_ _ 开发新的数据文件开发新的数据文件_ _ 修改已有的数据文件修改已有的数据文件_ _ 修改各种项目计划修改各种项目计划_ _ 更新别的文档更新别的文档_ _ 更新需求跟踪能力矩阵更新需求跟踪能力矩阵_ _ 检查工作产品检查工作产品_ _ 根据测试和检查情况返工根据测试和检查情况返工_ _ 总计劳动时数总计劳动时数影响分析报告模板影响分析报告模板 变更请求变更请求I D_I D_标题标题_描述描

21、述_分析者分析者_日期日期_优先权评估：优先权评估：相关收益相关收益_（1 - 91 - 9）相关代价相关代价_（1 - 91 - 9）相关成本相关成本_（1 - 91 - 9）相关风险相关风险_（1 - 91 - 9）最终优先级最终优先级_预计总耗时预计总耗时_劳动时数劳动时数预计损时预计损时_劳动时数劳动时数预计对进度的影响预计对进度的影响_天数天数额外的成本影响额外的成本影响_金额金额质量影响质量影响_被影响的其他需求被影响的其他需求_被影响的其他任务被影响的其他任务_要更新的计划要更新的计划_综合的事项综合的事项_生存期成本事项生存期成本事项_可能的变更所需检查的其他部件可能的变更所需检查的其他部件_1.3 需求跟踪需求跟踪 客户需要客户需要需求需求下游工作产品下游工作产品从需求从需求回溯回溯从需求从需求追溯追溯回溯到回溯到需求需求追溯到追溯到需求需求一一些些可可能能的的需需求求跟跟踪踪能能力力联联系系链链 业务需求业务需求变更请求变更请求规格说明规格说明系统需求，用例，业务规系统需求，用例，业务规则及外部接口需求则及外部接口需求软件功能需求软件功能需求依 赖 另依 赖 另一个一个系统测试系统测试项目计划项目计划任务任务体系结构，用户接口体系结构，