software work-3th_.pptVIP

软件工程导论 需求是根本 以下是需求过程不科学的典型例子： ·开发人员在用户处呆了两三天就埋头开发；  ·用户告诉开发人员我要开发一个XX系统，但是我很忙，你先开发一个让我看看； 3.1 需求分析的任务 需求分析和规格说明阶段（分析阶段） 目的： 澄清用户的需求 基本任务：用户和软件人员双方一起来充分 地理解用户的要求，并把双方共 同的理解明确地表达成一份书面 文档---需求说明书 需求说明书的三个作用 作为用户和软件人员之间的合同，为双方相互了解提供基础 反映出问题的结构，可以作为软件人员进行设计和编写的基础 作为验收的依据，即作为选取测试用例和进行形式验证的依据 完整：再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。 一致：简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。  明确：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。　　除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。 　　打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。 可测试：需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。 什么是可测试呢？ 我们要用新的系统完成报表自动化处理，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。 需求过程 的工作流 需求工作流程的工作目的 1.和客户在系统的工作内容方面达成并保持一致。 2.使系统开发人员能够更清楚地了解系统需求。 3.定义系统边界（限定）。 4.为计划迭代的技术内容提供基础。 5.为估算开发系统所需成本和时间提供基础。 6.定义系统的用户界面，重点是用户的需要和目标 软件需求各组成部分之间的关系 需求分析的具体任务包括： （1）确定软件系统的综合需求 （2）分析系统的数据需求（3）导出软件系统的逻辑模型（4）修正系统开发计划（5）开发原型系统（6）验证软件需求分析的正确性（7）编写软件需求规格说明书 3.2 需求分析的过程 需求分析阶段可分为四个过程：调查研究、分析与综合、书写需求分析的文档和评审。 （1）调查研究 系统分析员协同程序员向用户做需求调查，阅软件计划中的可行性报告和项目开发计划报告，访问系统现场，并由此确定当前系统必须做什么，并获得当前系统的具体模型，用数据流图或IPO图表示出来。 需求获取技术 获取用户需求的主要方法是调查研究。 (1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。 (2) 市场调查。了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统。如果有，在功能上、性能上、价格上情况如何。 (3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析；访问用户领域的专家所得到的信息将有助于对用户需求的理解。 (4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。 3.2 需求分析的过程 （2）分析与综合 分析员需从数据流和数据结构出发，逐步细化所有的软件功能，找出系统中各元素之间的联系、接口特征和设计上的限制，分析它们能否满足功能要求，是否合理。依据功能需求、性能需求、运行环境需求等，剔除其中不合理的部分，增