[理学]第2章可行性研究和需求分析.ppt

软 件 工 程 第2章 可行性研究和需求分析 2.1 软件的可行性研究 2.2 需求分析 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 实体-联系图(E-R图) 2.7 需求分析其他图形工具 2.8 验证软件需求 §2.1 软件的可行性研究 一、 问题定义的内容 首先明确：问题的背景、开发系统的现状； 开发的理由和条件、开发系统的问题要求； 总体要求、问题的性质、类型范围； 要实现的目标、功能规模、实现目标的方案 开发的条件、环境要求等等。 然后写出：问题定义报告（或称系统定义报告），以供可行性分析阶段使用。 二、 问题定义的步骤 在问题定义阶段，系统分析员要深入现场，阅读用户写的书面报告、听取用户对开发系统的要求、调查开发系统的背景理由。还要与用户负责人反复讨论，以澄清模糊的地方、改正不正确的地方。最后写出双方都满意的问题定义报告，并确定双方是否可继续合作的意向。 三、可行性研究的任务 可行性研究的任务是用最小的代价、在尽可能短的时间内确定问题是否能够解决。在澄清了问题定义之后，分析员首先应该导出系统的逻辑模型，然后从系统逻辑模型出发，探索出若干种可供选择的主要解法（即系统实现方案）。最后仔细研究每种解法的可行性。 研究可行性应该从下述几方面进行： （1）技术可行性：指使用现有的技术能否完成这个项目。 （2）经济可行性：指通过对软件开发项目进行成本/效益估计，以确定软件系统可能带来的经济效益能否超过研制和维护此系统所需的费用。 （3）操作可行性：系统的操作方式在这个用户组织内行得通吗? （4）社会因素的考虑：软件开发是否会侵犯他人、集体或国家的利益，是否违反国家的法律并可能由此而承担法律责任。 四、可行性研究的期限与成本 期限：可行性研究需要的时间长短取决于工程的规模。 成本：一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。 五、可行性研究过程 （1）复查系统规模和目标（2）研究目前正在使用的系统（3）导出新系统的高层逻辑模型（4）重新定义问题（5）导出和评价供选择的方案（6）推荐方案和行动方针（7）草拟开发计划（8）书写文档、提交审查 §2.2 需求分析 §2.2.1 需求分析的重要性 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题，而不是“怎样实现”。 【分析结果】：系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 【掌握内容】：对一个软件系统来说，数据是稳定的，事务处理可能是变化的。 需求分析的原则： (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能域，这条准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 系统分析员在软件开发中的作用 在系统分析过程中，系统分析员除了起用户和设计人员的接口作用以外，还应充分代表用户的利益，在整个开发过程中起着关键作用。 §2.2.2 需求分析的任务 一、确定对系统的综合要求 功能需求 性能需求 可靠性和可用性需求 出错处理 接口需求 约束与环境需求 逆向需求 将来可能提出的要求 1、功能需求 系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？ 3、可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 4、出错处理需求 有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。 5、接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。例如： 6、约束与环境需求 描述在设计或实现应用系统时应遵守的限制条件，是用户或环境强加给项目的限制条件。常见的约束有：精度；开发工具和语言约束；设计约束；数据库约束；应该使用的标准；应该使用的硬件平台及现场环境等。 7、逆向需求 逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求，且可消除可能发生的误解的那些逆向需求。 8、将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是分析将来很可能会提出来的要求。 目的：在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。 9、用户或人的因素 10、文档需求 12、资源需求 14、安全保密要求