第3章 结构化需求分析课程.ppt

第3章 结构化需求分析 6学时 引言1 用户描述的可能不是他想要的。 对用户的描述每个人有不同的理解 引言2—开发人员和用户之间的鸿沟 从前有一家汽车厂，想为年轻人设计一款新车型，企划及设计部讨论了许久始终找不到感觉，于是对25-35岁的年轻人进行问券调查，大伙辛苦了三个月，完成了一万份的调查记录。市场部门摘要了调查内容反映给设计部门，重点：省油、外型酷、颜色鲜艳、马力足等。设计部门有了灵感开始设计，半年过去了!设计部门很得意的把雏型车展示给大伙看，这个时候…CEO、市场部、企划部..都傻眼了。 CEO开口说: 为什么这车没有”轮子” 设计部回答: 市场部给的调查报告里，没说要有轮子 市场部回说: 问卷调查中、顾客没有提到要有轮子 企划部生气的说: 你们都是白痴啊,汽车要有轮子是基本常识，你们都不知道吗? 就这样现场吵翻天了! 注：原文地址：/post/572.html 引言3—做需求要很细、很专业、很有经验 男孩反问:“是无声枪么？” 不是 “枪声有多大？” 80~100分贝 “那就是说会震的耳朵疼？”是 “您确定那只鸟真的被打死啦？”确定 “鸟里有没有聋子？”没有 “没有关在笼子里的？”没有 “旁边树上还有其他鸟？”没有 “有残疾或饿的飞不动的鸟？”没有 “算不算怀孕肚子里的小鸟？”都是公的  结论 需求具有主观性、二义性、多变性、模糊性。 需求分析要求很专业、很仔细、很有经验。 需求分析是确定系统应具备的功能，是其他所有工作的基础，因此非常重要。 需求导致整个项目失败占的比例非常大。 第3章 结构化需求分析 1）需求分析的基本概念 2）结构化分析的方法和步骤 3）独立完成小型系统结构化分析 4）数据流程图、数据字典、ER图应用 5）系统流程图的作用。 6）需求分析规格说明书的主要内容 第3章 结构化需求分析 3.1 需求分析的概念 什么叫软件需求？ 软件需求如何分类？ 用户心中有什么疑虑？ 需求调研的流程是什么？ 3.1.1软件需求的定义和分类 定义：软件需求是指用户对软件的功能和性能要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么样的性能。 软件需求可分解为四个层次：业务需求、用户需求、功能需求和非功能需求。 业务需求：是用户高层领导机构决定的，它确定软件的目标、规模和范围。 业务需求一般在需求分析之前就应该确定。 业务需求通常比较简洁，大约三～五页纸就可以描述清楚。 用户需求：是用户使用该软件要完成的任务。 用户需求应该充分调研具体的业务部门，详细了解最终用户的工作过程、所涉及的信息、当前系统的工作情况、与其他系统的接口等等。 用户需求是最重要的需求，也是出现问题最多的。 功能需求：软件开发人员必须实现的软件功能。 软件分析人员在充分理解用户需求的基础上，将用户需求整理成软件功能需求。开发人员根据功能需求进行软件设计和编码。 非功能需求：是对功能需求的补充，可以分为两类： 一类对用户来说可能是很重要的属性，包括有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性。 另一类对开发者来说是很重要的质量属性，包括可维护性、可移植性、可重用性、可测试性。 需求分类例子： 一个字词拼写检查程序的业务需求可能是：“能够有效地检查和纠正文档中的字词拼写错误”。 用户需求可能是这样描述的：“找出文档中的拼写错误，并且对每个错误提供一个更正建议表，更正建议表中列出可以替换的字词”。 功能需求的描述是：“软件提供一个打开的文档对话框；对打开的文档进行字词检查，发现拼写错误并以高亮度提示出错的字词；对错误字词显示更正建议对话框，其中列出可选的字词，以及替换范围选择”。字词拼写检查程序要求允许用户的误操作，设计回退功能，便于用户取消前面的误操作。 非功能需求描述：软件支持Windows、Linux操作系统。 3.1.2 解决用户心中的疑虑 用户往往是应用领域的专家，但不一定是软件专家。他们会有几点疑虑： 软件开发的“过程”似乎不可见，非常神秘。 软件的修改好像很容易，只改几句程序代码。 怎么验收软件，根据什么？ 解惑一： 1．软件开发与其他产品的开发过程一样是分阶段的，每个阶段都有阶段产品。 软件的阶段产品主要是文档。 只有每个阶段的产品符合要求，才有可能生产出最终满足用户需要的产品。 解惑二： 软件修改的代价随着过程的向前推进，越来越高。在需求时如果发现问题，修改的仅仅是需求文档，代价比较低；到编程阶段发现问题，修改的是需求、设计和程序，并且每个环节都要重新审核；因此，一定要告之用户，发现问题的苗头，马上通报。 解惑三： 用户在阶段审查时，首先检查所提交文档的目录，看内容是否全面，审查中如果有困难可以参考《计算机软件工程规范国标汇编》(简称“软件