当前位置:   article > 正文

软件开发中需求的先决条件_软件功能用例 先决条件是什么

软件功能用例 先决条件是什么

“需求”详细描述软件系统应该做什么,这是达成解决方案的第一步。“需求活动”也称为“需求开发”、“需求分析”、“分析”、“需求定义”、“软件需求”、“规格书”、“功能规格书”等。

一:为什么要有正式的需求

要求一套明确的需求,这点很重要,理由如下:

1、明确的需求有助于确保用户(而不是程序员)驾驭系统的功能。如果需求明确,那么用户就可以自行评审,并进行核准。否则,程序员就常常会在编程期间自行决定需求。明确的需求免得你去猜测用户想要的是什么。

2、明确的需求还有助于避免冲突。在卡是编程之前,先把系统的范围(scope)确定下来。如果你和另外的一个程序员对于“程序应该做什么”意见不一致,你们可以查看书面的需求,以解决分歧。

3、重视需求有助于减少开始编程开发以后的系统变更情况。如果你在编程过程中发现了一个代码的错误,你只需要修改几行的代码,然后就可以继续工作。但是如果你在编码的过程中发现了一个需求错误,那你就得改变设计,使之符合更改后的需求。你可能需要扔掉部分旧的设计,并且因为要与已经写好的代码相适应,可能导致新的设计,与在项目之初进行同样的设计相比,话费更长的时间。此外,还需要废弃那些受此需求变更影响的代码和测试用例,还需要编写新的代码和测试用例。

充分详尽地描述需求,是项目成功的关键,它甚至很可能比有效的构建技术更重要,关于如何清除低描述需求,已经有了很多优秀书籍。因此我们这里不作过多的讲解。


二:稳定需求的神话

稳定需求在软件开发中基本上是很难遇到的情况。一旦需求稳定,项目就能以有序的、可预测的、平稳的方式,完成从架构到设计到编码到测试等一系列工作。这是软件的天堂!你能预测开支,而且根本无需担心实现某项特性的开销增大为原先计划的100倍--因为在你完成调试以前,用户根本没有想到这项特性。

“一旦客户接受了一份需求文档,就再也不做更改”是一个美好的愿望。然而,对一个典型的项目来说,在编码之前,客户无法可靠地描述他们想要的是什么。问题并不在于客户是低级生物。就如同你做这个项目的时间越长,对这个项目的理解也就越深入一样,客户参与项目的时间越长,他们对项目的理解也就越来越深入。开发过程能够帮助客户更好的理解自己的需求,这是需求变更的主要来源。计划严格依照需求行事,实际上就是计划不对客户的要求作出回应。

三:在构建期间处理需求变更

1、使用需求核对表来评估你的需求质量

如果你的需求不够好,那就停止工作,退回去,先把他做好,再继续前进。当然,因为在此期间你会停止编码,所以感觉进度似乎会落后。如果没有对准正确的方向,那要停下来检查一下路线。

2、确保每一个人都知道需求变更的代价

假如你的组织对于“先做需求分析”的重要性并不敏感,那你就指出在需求阶段进行修改,要比之后进行修改的代价低得多。

3、建立一套变更控制程序

建立一个正式的变更控制委员会,评审提交上来的更改方案。客户改变他们的想法,认识到他们需要更多的功能这不是坏事。问题是如果他们提出的更改方案太频繁了,让你跟不上进度。如果有一套固定的变更控制程序,那么大家都会很愉快--你知道自己只需在特定时候处理变更。

4、使用能适应变更的开发方法

某些开发方法能让你“对需求变更作出响应”的能力最大化。演进交付是一种分阶段交付系统的方法。你可以建造一小块、从用户获得一些反馈、调整一点设计、做少量改动,在多建造一小块。关键在于缩短开发周期,以便更快的响应用户的要求。

5、放弃这个项目

如果需求特别糟糕,或者极不稳定,而上面的建议没有一条能奏效,那就取消这个项目。

6、注意项目的商业案例

在提到实施这个项目的商业理由的时候,许多需求事项就会从你眼前消失。有些需求作为特色功能来看是不错的想法,但是当你评估“增加的商业价值”时就会觉得它是一个糟透了的注意。那些记得“考虑自己的决定所带来的商业影响”的程序员的身价与黄金相当--不过我更乐意为此建议获得现金报酬。



声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/63898
推荐阅读
相关标签
  

闽ICP备14008679号