需求分析基础教学PPT.ppt

第4章 需求分析基础,4.1 软件需求分析的目标和过程,需求是用户所需要并能触发一个程序或系统开发工作的说明； 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等； 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。,4.1.1 需求分析的目标 软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。,通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。,4.1.2 需求分析的过程,需求分析阶段的工作，可以分成以下四个方面： (1)问题识别 系统分析人员要确定对目标系统的综合要求，即软件的需求。并提出这些需求实现条件以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。如针对采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的需求。,数据库中存放的是职工的,某学校医疗费管理系统,所属部门、职工号、姓名,职工报销时应填写：,所属部门、职工号、姓名、日期,校内门诊、校外门诊、住院费、子女医疗费,医疗费分类：,该校规定，每年每个职工的医疗费有一个限额（如80元），限 额在年初确定，其限额规则如下：,1、每个职工一年内报销的医疗费不超过限额时，全部报销 2、超额，则超出部分只可报销90%，其余10%由职工个人负担 3、职工子女的医疗费也有限额（如40元）,1、医疗费管理系统每天记录当天报销的若干职工或职工子女的医 疗费的类别、金额。 2、在当天下班前让系统自动结帐、统计当天报销的医疗费总额， 供出纳员核对。 3、每笔帐要保存备查，每天所报销的费用要和各个职工已报销的 金额累计起来，以便检查哪些职工已超额。 4、系统还要配有适当的查询功能。 5、年终结算后，下一年度开始时要对数据库文件进行初始化。 6、当职工调离本单位，职工调入本单位或在本单位内部门间调动， 数据库文件应能及时得到修改。,用户对系统的要求,该系统规模不太大，可以和用户单位的其他管理系统 使用相同的计算机硬件设备、相同的操作系统和相同的关 系数据库管理系统。 如果，可以使用汉化了的数据库管理系统，但在建立 数据库结构时，凡是用英文名称来代表字段名时，则必须 在数据字典中予以说明。,i、确定系统的环境要求,ii、系统性能要求,（1）数据不能随意更改 （2）保证数据的准确性 由于医疗费管理系统涉及到会计经费问题，数据不能 随意更改但数据输入又难免会出错。因而在每输入一个职 工的医疗费后，屏幕提示“数据有误吗？”。若是在核对时 有误，可及时更改，避免输入错误。一天报销结束时，在 数据存档前，再让出纳员核对一下经费总额，若出纳员支 出的金额总数有误时，应让计算机显示每笔帐目，供一一 仔细核对，此时再允许修改一次。当正式登帐后，数据就 绝对不允许再修改了，由此保证财务制度的严格性，保证 数据的安全性。,iii、系统的功能,（1）具有表格形式屏幕的输入格式 （2）具有重复录入数据的功能 （3）具有查询和统计汇总的功能 （4）职工的调入和调出以及对数据库的初始化,(2)分析与综合 分析员必须从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，判断是否存在因片面性或短期行为而导致的不合理的用户要求，是否有用户尚未提出的真正有价值的潜在要求。剔除其不合理的部分，增加其需要部分。,(3)编制需求分析阶段的文档 软件需求说明书、数据要求说明书、用户手册 (4)需求分析评审,4.2 需求获取技术,获取用户需求的主要方法是调查研究，包括以下几个方面： 了解系统的需求。 市场调查。 访问用户和用户领域的专家。 考察现场。,在做调查研究时，可以采取如下的调查方式： 制定调查提纲，向不同层次的用户发调查表； 按用户的不同层次，分别召开调查会，了解用户对待开发系统的想法和建议； 向用户领域的专家或在关键岗位上工作的人个别咨询； 实地考察，跟踪现场业务流程； 查阅与待开发系统有关的资料； 使用各种调查工具，如数据流图、任务分解图、网络图等。,4.3 需求分析和描述技术,4.3.1 需求建模 通常，分析人员选定一些图形记号分别表示信息流、处理功能及系统行为，并利用受限的自然语言给出用户需求的描述。此外，为了处理大型问题，模型的表示机制还应具备良好的结构化能力。,4.3.2 问题抽象、问题分解与多视点分析 4.3.3 用于支持需求分析的快速原型化方法,4.3.4 需求管理的内容,需求变更应该实现以下要求： (1)应仔细评估已建议的变更； (2)挑选合适的人选对变更做出决定； (3)变更应及时通知所有涉及的人员； (4)项目要按一定的程序来采纳需求变更。,版本控制是管理需求的一个必要方面。需求文档的每一个版本必须被统一确定，组内每个成员必须能够得到需求的当前版本，必须清楚地将变更写成文档，并及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应仅允许指定的人来更新需求。 每一个公布的需求文档的版本应该包括一个修正版本的历史情况，即已做变更的内容、变更日期、变更人姓名以及变更原因。可以考虑给每个需求标记上版本号，当修改需求后就增加版本号。,4.4 需求分析人员,需求分析人员的工作目标是产生好的、符合规范的需求，完整地获取用户需求，认真地理解、分析和综合要解决的问题。主要包括以下几方面的活动：通过学习、请教领域专家、向用户提问等手段，了解所要解决的问题，理解用户的需要，确认谁是真正的用户及系统实现所受到的各种限制。,需求分析人员面临的三大挑战: (1)问题空间理解 (2)人与人之间的通信 (3)需求的不断变化,需求分析人员的原则和策略 将问题复杂化 划分问题 问题抽象化 投影问题,需求工作人员应采用的技术： (1) 使用易于理解的语言。 (2) 提供定义系统边界的方法。 (3) 提供定义划分、抽象和投影的方法。 (4) 用问题空间的术语而不是软件术语去思考问题和编制文档。 (5) 充分注意有多种可供选择的设计方案。 (6)适应需求的变化。,4.5 软件需求规格说明和需求评审,原则1:功能与实现分离，即描述要“做什么”而不是“怎样实现”。 原则2:要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。 原则3:如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。 原则4:规格说明必须包括系统运行的环境。 原则5:系统规格说明必须是一个认识的模型，而不是设计或实现的模型。,原则6:规格说明必须是可操作的。规格说明必须是充分完全和形式化的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。 原则7:规格说明必须容许不完备性并允许扩充。 原则8:规格说明必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只需修改某个单个段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。,软件需求规格说明的框架,需求规格说明评审 作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、 完整性和清晰性以及其他需求给予评价。,4.6 软件需求规格说明书,软件需求规格说明书（software requirements specifications，简称srs)也称软件需求分析说明书，它