软件需求工程04.ppt
《软件需求工程04.ppt》由会员分享,可在线阅读,更多相关《软件需求工程04.ppt(25页珍藏版)》请在文库网上搜索。
1、软件需求工程软件需求工程Software Requirements Engineering 第四章改进需求过程第3章介绍了几十种需求工程中的好方法,你应当考虑在实践中应用它们。把理论方法付诸实践是改进软件过程(process)的核心所在。从根本上说,改进过程包括使用更多有效的方法避免使用过去使用过的令人头痛的方法。然而,改进之路却是从失败、错误开始,还要历经诸如受人为抵制的影响及因任务的时间紧迫导致改进被搁置这样的挫折。软件开发过程的改进有以下两个目标1、解决在以前项目或目前项目中遇到的问题2、防止和避免你可能在将来的项目中遇到的问题把理论方法付诸实践是改进软件过程(p r o c e s s
2、)的核心所在。避免使用过去使用过的令人头痛的方法。改进之路是从失败、错误开始,还要历经诸如受人为抵制的影响及因任务的时间紧迫导致改进被搁置这样的挫折。需求与其他主要项目过程和风险承担者之间的关系1.需求与其他项目过程的关系需求与其他项目过程的关系1)制定项目计划需求是制定项目计划的基础。因为开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。通常,项目计划指出所有希望的特性不可能在允许的资源和时间内完成,因此,需要缩小项目范围或采用版本计划对功能特性进行选择。2)项目跟踪和控制监控每项需求的状态,以便项目管理者能发现设计和验证是否达到预期的要求。如果没有达到,管理者通常请求变更控制过程
3、来进行范围的缩减。需求与其他项目过程的关系3)变更控制在需求编写成文档并制定基线以后,所有接下来的变更都应通过确定的变更控制过程来进行。变更控制过程能确保:*变更的影响是可以接受的。*受到变更影响的所有人都接到通知并明白这一点。*由合适的人选来作出接受变更的正式决定。*资源按需进行调整。*保持需求文档是最新版本并是准确的更新文档。需求与其他项目过程的关系4)系统测试用户需求和功能需求是系统测试的重要参考。系统测试可以验证计划中所列的功能是否按预期要求实现了。同时,也验证了用户任务是否能正确地执行。5)用户编制文档产品的需求是编写文档的重要参考低质量和拖延的需求会给编写用户文档带来极大的困难。需
4、求与其他项目过程的关系6)构造软件项目主要产品是交付可执行软件,而不是需求说明文档。需求文档是所有设计、实现工作的基础。要根据功能要求来确定设计模块,而模块又要作为编写代码的依据。采用设计评审的方法来确保设计正确地反映了所有的需求。而代码的单元测试能确定是否满足了设计规格说明和是否满足了相关的需求。跟踪每项需求与相应的设计和软件代码。2.软件需求对其他项目风险承担者影响当软件开发队伍改变需求过程时,与其他项目风险承担者沟通的接口也会发生变化。图4-2说明了一些外部组织功能,这些功能是通过一定的接口与软件开发队伍联系的,这些接口对项目需求活动起着重要作用。软件需求对其他项目风险承担者影响 为能顺
5、利进行这些接口操作,要与其他领域的合作者多交流,让他们知道你的改进想法和调整计划。要向他们说明改进后的新过程会带来什么好处。如在改进过程中需要获得合作时,可以从这样的谈话开始:“这些是我们曾经经历过的问题,而我们认为进行这些变更将会有助于问题的解决。向各个功能领域的人说明你从他们那里所需要获取的信息和帮助,从而有助于成功地开发整个产品。在开发过程中要遵从开发组与其他功能领域之间重要交流接口的规范和内容,如系统需求规格说明文档或市场需求文档。询问其他组织需要从开发队伍中获取什么以有助于他们的工作。技术可行性方面哪些能帮助市场部更好地完成产品计划?什么样的需求状态报告能使管理者更充分地看清楚项目的
6、进展情况?与系统工程部之间怎样合作才能确保系统需求在软、硬件间的分配合理?努力在开发组和其他需求过程风险承担者之间建立合作关系以便所有人都能更有效地促进项目成功。软件需求对其他项目风险承担者影响许多反对是由于不了解情况而引起的恐惧所造成的,因此一开始就要给他们说清楚为什么要作这些变更,变更后他们将受到怎样的影响,将会带来什么好处以及为什么你在过程改进一开始就需要他们的参与等等。下面是一些你可能遇到抵制的情况:需求变更控制过程被看成很难进行而被丢弃。要确保变更过程真正能起作用。如果新的过程不能带来更好的结果,那大家将会“绕道而行”了。开发人员把编写和审查需求文档看作是浪费时间的官僚做法,妨碍他们
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 工程 04