第3章-需求分析(结构化方法)

第三章需求分析需求分析问题定义可行性研究可行否？否是需求分析终止项目......定义时期定义时期开发时期引言1用户描述的可能不是他想要的。对用户的描述每个人有不同的理解软件名称：职员系统Stuff使用用户：A公司人力资源部Mary开发者：John问题：Mary在使用Stuff时，想把名字Mary改为MarySparkle，而系统不允许。以下是Mary和John的对话：John：她嫁给了姓Sparkle的人了吗？Mary：没有，而仅仅是要改名，好像我只能在婚姻状况改变后，才能改名字。John：当然是这样，我从未想过谁会莫名奇妙的改名，你也没告诉我系统需要处理这样的事。Mary：但不管怎样，我希望下周五之前解决这个问题，否则不会支付开发费。引言2—需求不明确（1）John：这并不是我的错，我现在正忙着做另一个项目，我只能在月底前修改好，很抱歉，一周内不行。下次若有类似的问题，请早一点告诉我，并把它们写下来。Mary：对不起，那只能完成后再付款了。John：Mary你要明白，这不是我的错。如果你开始就告诉我，需要随意修改姓名，问题就不会发生了，你不能因为我没猜出你的意思，就不付款。Mary：好吧，我只能怪计算机了，我先付80%，等你修改好了，马上电话告诉我。客户：很烦恼一个不能进行基本操作的软件。开发者：很烦恼系统交付后，用户再提出对功能进一步的要求。原因：由于收集、编写、协商、修改产品过程中的手续和做法失误。Mary和John的问题：非正式信息收集，未确定和不明明确的功能，未发现或未经交流的假设，不完善的需求文档，以及突发的需求变更过程。引言2—需求不明确（1）引言3—需求不明确（2）从前有一家汽车厂，想为年轻人设计一款新车型，企划及设计部讨论了许久始终找不到感觉，于是对25-35岁的年轻人进行问卷调查，大伙辛苦了三个月，完成了一万份的调查记录。市场部门摘要了调查内容反映给设计部门，重点：省油、外型酷、颜色鲜艳、马力足等。设计部门有了灵感开始设计，半年过去了!设计部门很得意的把雏型车展示给大伙看，这个时候…CEO、市场部、企划部..都傻眼了。CEO开口说:为什么这车没有”轮子”设计部回答:市场部给的调查报告里，没说要有轮子市场部回说:问卷调查中、顾客没有提到要有轮子企划部生气的说:你们都是白痴啊,汽车要有轮子是基本常识，你们都不知道吗?就这样现场吵翻天了!引言4—做需求要很细、很专业、很有经验男孩反问:“是无声枪么？”不是“枪声有多大？”80~100分贝“那就是说会震的耳朵疼？”是“您确定那只鸟真的被打死啦？”确定“鸟里有没有聋子？”没有“没有关在笼子里的？”没有“旁边树上还有其他鸟？”没有“有残疾或饿的飞不动的鸟？”没有“算不算怀孕肚子里的小鸟？”都是公的“有没有傻的不怕死的？”都怕死“会不会一枪打死两只以上？”不会“所有的鸟都可以自由活动么？”完全可以“它们受到惊吓时不会互相撞上？”不会学生满怀信心的回答，“打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。”某日老师在课堂上想考考学生们的智商，就问一个男孩:“树上有十只鸟，开枪打死一只，还剩几只？结论⚫需求具有主观性、二义性、多变性、模糊性。⚫需求分析要求很专业、很仔细、很有经验。⚫需求分析是确定系统应具备的功能，是其他所有工作的基础，因此非常重要。⚫需求导致整个项目失败占的比例非常大。软件需求分析软件需求分析是软件开发早期的一个重要阶段。它在问题定义和可行性研究阶段之后进行。需求分析的基本任务是软件人员和用户一起完全弄清用户对系统的确切要求。这是关系到软件开发成败的关键步骤，也是整个系统开发的基础。软件需求分析阶段要求用需求规格说明书（SRS）来表达用户对系统的要求。规格说明书可用文字方式表示，也可用图形表示。本章将介绍需求分析的任务、步骤、需求分析方法(面向数据流图分析方法、面向对象的分析方法）。主要内容需求分析的任务、步骤123小结4获取需求的方法需求分析方法学习目标➢掌握需求分析的任务及步骤；➢掌握获取需求的方法；➢掌握需求分析的方法-——结构化方法和面向对象的方法➢掌握E-R图，数据流图、数据字典等的绘制3.1需求分析的任务、步骤与可行性分析的区别【可行性研究】◼粗略了解用户的需求。◼用较少的成本，在较短的时间内确定是否存在一些可行的解法。◼许多细节被忽略了。【需求分析】◼准确地回答“系统必须做什么？”这个问题。3.1需求分析的任务、步骤【依据】◼《可行性研究报告》【任务】◼⑴建立目标系统的逻辑模型调查分析用户的确切需求，认真搞清、并细化到底“系统必须做什么”？◼反复与用户交流；◼建立原型系统；确定目标系统的功能、性能、运行◼⑵形成《软件需求规格说明书》SoftwareRequirementSpecification3.1需求分析的任务、步骤⑴分析系统的要求⑵目标系统的逻辑模型⑶修正开发计划⑷构造原型系统⑸复审、验证《软件需求规格说明书》必须处理的信息和应该产生的信息数据流图、数据字典、加工处理用户了解目标系统的功能、概况开发者快速、准确、完整把握需求一、确定目标系统的具体要求1、确定系统的运行环境要求2、系统的性能要求3、系统功能➢系统所需的存储容量、安全性、可靠性、期望的响应时间要求，也就是从终端输入数据到系统后，系统在多长时间内可以有反映等。➢确定目标系统具备的所有功能3.1需求分析的任务、步骤➢硬件环境和软件环境校内门诊、校外门诊、住院费、子女医疗费案例数据库中存放的是职工的某学校医疗费用管理系统所属部门、职工号、姓名职工报销时应填写：所属部门、职工号、姓名、日期医疗费分类：该校规定，每年每个职工的医疗费有一个限额（如80元），限额在年初确定，其限额规则如下：1、每个职工一年内报销的医疗费不超过限额时，全部报销2、超额，则超出部分只可报销90%，其余10%由职工个人负担3、职工子女的医疗费也有限额（如40元）1、医疗费管理系统每天记录当天报销的若干职工或职工子女的医疗费的类别、金额。2、在当天下班前让系统自动结帐、统计当天报销的医疗费总额，供出纳员核对。3、每笔帐要保存备查，每天所报销的费用要和各个职工已报销的金额累计起来，以便检查哪些职工已超额。4、系统还要配有适当的查询功能。5、年终结算后，下一年度开始时要对数据库文件进行初始化。6、当职工调离本单位，职工内部调动，如本单位或在本单位内部门间调动，数据库文件应能及时得到修改。请完成对上述系统的需求分析用户对系统的要求案例某学校医疗费用管理系统该系统规模不太大，可以和用户单位的其他管理系统使用相同的计算机硬件设备、相同的操作系统和相同的关系数据库管理系统。如果使用汉化了的数据库管理系统，但在建立数据库结构时，凡是用英文名称来代表字段名时，则必须在数据字典中予以说明。1、确定系统的环境要求一、确定目标系统的具体要求案例某学校医疗费用管理系统2、系统的功能（1）具有表格形式屏幕的输入格式（2）具有重复录入数据的功能（3）具有查询和统计汇总的功能（4）职工的调入和调出以及对数据库的初始化一、确定目标系统的具体要求3、系统性能要求1）数据不能随意更改2）保证数据的准确性由于医疗费管理系统涉及到会计经费问题，数据不能随意更改，但数据输入又难免会出错。因而在每输入一个职工的医疗费后，屏幕提示“数据有误吗？”。若是在核对时有误，可及时更改，避免输入错误。一天报销结束时，在数据存档前，再让出纳员核对一下经费总额，若出纳员支出的金额总数有误时，应让计算机显示每笔帐目，供一一仔细核对，此时再允许修改一次。当正式登帐后，数据就绝对不允许在修改了，由此保证财务制度的严格性，保证数据的安全性。一、确定目标系统的具体要求二、建立目标系统的逻辑模型通常软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中。它是软件实现的基础。但是目标系统的物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻辑模型忽视机制和细节，只描述系统要完成的功能和要处理的数据。为此，该阶段的主要任务是，借助于当前系统的逻辑模型导出目标系统的逻辑模型，也就是解决目标系统“做什么”的问题。逻辑模型就是为了理解事务而对事务做出的一种抽象，是对事务的一种无歧义的书面描述。模型由一组符号，和使用这些符号的规则组成。在构造好逻辑模型后，要验证模型是否满足用户需求，并在设计中逐步把和实现有关的细节加进模型中，直至最终用程序实现模型。二、建立目标系统的逻辑模型需求分析三种逻辑模型(1)数据模型：描述数据对象及数据对象之间的关系。(2)功能模型：指明系统变换数据的功能(3)行为模型：指明了作为外部事件结果的系统行为。二、建立目标系统的逻辑模型例：结构化分析方法建立的需求模型结构化分析（StructuredAnalysis,SA）是面向数据流进行分析的方法，主要建立以下几种模型：⚫实体关系图(Entity-RelationshipDiagram,E-R图)来创建数据模型，描述系统中所有重要的数据对象；⚫数据流图（DataFlowDiagram,DFD）：用来创建功能模型，描述了信息流和数据转换。⚫状态转换图（State-TransitionDiagram,STD）用来创建行为模型，描述系统状态如何响应外部事件，而进行转换。例：面向对象分祈方法（OOA）所建立的模型对象模型(Objectmodel)：定义实体，描述系统的静态结构，定义“对谁做”动态模型(Dynamicmodel):描述对象之间的交互过程，规定“何时做”功能模型(Functionalmodel)：描述内部数据的处理，指明系统应“做什么”----学生购买教材的具体模型举例请建立计算机售书系统的逻辑模型张秘书学生购书王会计发票李出纳领书赵保管单证明书高等学校学生的教材，一般由学校教材科供应。设某校教材科目前的售书手续是：1.每班推代表一人，填写集体购书单.2.由各系教学秘书审购书单，去掉不属该班本学期使用的教材，并确认数量与学生人数，之后发给学生购书证.3.再由教材科确认购书单中没有已经买过的教材后，为学生开购书发票并同时开领书单4.学生凭购书单到书库领书----学生购买教材的具体模型举例请建立计算机售书系统的逻辑模型张秘书学生购书王会计发票李出纳领书赵保管单证明书去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型----学生购买教材的逻辑模型审查有效性学生有效开发票发票开领书单领书单发书购书单书----学生购买教材的逻辑模型审查并开发票学生发票各班学生用书表教材存量表无效书单开领书单领书单学生完善目标系统并补充细节，得出目标系统的正式逻辑模型举例请建立计算机售书系统的逻辑模型3.1需求分析的任务、步骤⑴分析系统的要求⑵目标系统的逻辑模型⑶修正开发计划⑷构造原型系统⑸复审、验证《软件需求规格说明书》用户了解目标系统的功能、概况开发者快速、准确、完整把握需求根据对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。由专家、分析人员、开发人员、用户组成评审组，对需求分析所得的结果进行评审。⑴正确性⑵完整性⑶一致性⑷无歧义性⑸可验证性⑹可理解性⑺可追踪性(8)可修改性需求验证(1)正确性需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。(2)完整性需求规格说明书不能遗漏任何用户需求(3)一致性需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为方面的冲突，以及时序方面的前后不一致。需求验证(4)无歧义性需求规格说明书中使用标准化术语，用户、分析人员、设计人员和测试人员对需求规格说明书中的任何语法单位只能有唯一的语义解释。(5)可验证性需求规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。(6)可理解性不宜在说明书中使用太多的专业化词汇。需求验证(7)可追踪性需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引