资源预览内容
第1页 / 共30页
第2页 / 共30页
第3页 / 共30页
第4页 / 共30页
第5页 / 共30页
第6页 / 共30页
第7页 / 共30页
第8页 / 共30页
第9页 / 共30页
第10页 / 共30页
亲,该文档总共30页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
第三章 需求分析 (Requirements Analysis),1. 软件需求分析的目标和任务 软件需求分析的目标是深入描述软件的功能和性能,确定软件设计的约束和软件同其它系统元素的接口细节,定义软件的其它有效性需求。 需求分析阶段研究的对象是软件项目的用户要求。一方面,必须全面理解用户的各项要求,但又不能全盘接受所有的要求,另一方面,要准确地表达被接受的用户要求。只有经过确切描述的软件需求才能成为软件设计的基础。 通常软件开发项目是要实现目标系统的物理模型。作为目标系统的参考,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。其实现步骤下图所示。,第三章 需求分析,第三章 需求分析,1. 需求分析的任务,仍然回答“What”,而不是“How”, 但更细致、精确(合同的拟定),Final stage of Definition phase,1. 需求分析的任务,1、确定要求 功能要求(functional requirements):系统必须做什么? 性能要求(performance requirements):做得怎样? 例:response time , memory , back-up memory , security , 运行要求(operational requirements) :运行环境、软硬件配置等。 未来可能的扩充要求(possible evolution):如HDIS各组的合并,3维虚拟现实的效果等等。,1. 需求分析的任务,2、分析数据 建立概念模型(conceptual models): E-R Diagram 形象描绘数据结构: Data Hierarchy, Warnier Diagram, IPO 数据结构规范化(Normalization),3、导出逻辑模型: DFD + DD + IPO,4、修正计划:重估成本、进度等,1. 需求分析的任务,5、开发原型系统(Prototyping),“样机 试用”,C,D,G,2.分析过程,1、沿DFD回溯: DFD的输出端是系统的最终目的。向回确定每个数据元素的来源,可加细DFD及DD,并将相关算法记录在IPO图中。 2、用户复查 3、细化DFD: 加细前后的IO须相同。 分解到须考虑具体实现的代码时即可仃止,2.分析过程,4、修正计划 5、文档:需求规格说明书 6、审查和复审,需求规格说明书,封面:,需求规格说明书 需求规格说明书内容:,系统规格说明: 系统概貌 功能要求 性能要求 运行要求 可能增加的要求 DFD IPO, 数据要求: DD Hierarchy 或 Warnier Diagram, 用户系统描述 初步用户手册:从用户的观点考虑系统 系统功能、性能 使用与步骤 等,修正的开发计划: 成本估计 资源使用计划 进度计划,分层数据流图,分层数据流图 稍为复杂的实际问题,在数据流图上常常出现十几个甚至几十个加工。一个数据流图看起来很不清楚。为了表达数据处理过程的数据加工情况,用层次结构的数据流图很好地解决这一问题。按照系统的层次结构进行逐步分解,并以分层的数据流图反映这种结构关系,能清楚地表达和容易理解整个系统。 下图给出分层数据流图的示例。数据处理S包括三个子系统1、2、3。顶层下面的第一层数据流图为DFDL1。第二层数据流图DFDL2.1、DFDL2.2及DFDL2.3分别是子系统1、2和3的细化。对任何一层数据流图来说,我们称它的上层图为父图,在它下一层的图则称为子图。 初画时可以忽略琐碎的细节,以集中精力于主要数据流。 加工规格说明,2. 需求分析的过程,2. 需求分析的过程 需求分析阶段的工作,可以分成以下四个方面: (1) 问题识别 首先系统分析人员要确定对目标系统的综合要求,即软件的需求。并提出这些需求实现条件,以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求,并预先估计以后系统可能达到的目标。此外,还需要注意其它非功能性的需求。如针对采用某种开发模式,确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等,以及可维护性方面的需求。,(2) 分析与综合 问题分析和方案的综合是需求分析的第二方面的工作。分析员必须从信息流和信息结构出发,逐步细化所有的软件功能,找出系统各元素之间的联系、接口特性和设计上的限制,判断是否存在因片面性或短期行为而导致的不合理的用户要求,是否有用户尚未提出的真正有价值的潜在要求。剔除其不合理的部分,增加其需要部分。最终综合成系统的解决方案,给出目标系统的详细逻辑模型。 (3) 编制需求分析阶段的文档 已经确定下来的需求应当得到清晰准确的描述。通常我们把描述需求的文档叫做软件需求说明书。同时,为了确切表达用户对软件的输入输出要求,还需要制定数据要求说明书及编写初步的用户手册。,(4) 需求分析评审 作为需求分析阶段工作的复查手段,应该对功能的正确性、文档的一致性、完备性、准确性和清晰性,以及其它需求给予评价。为保证软件需求定义的质量,评审应以专门指定的人员负责,并按规程严格进行。评审结束应有评审负责人的结论意见及签字。除分析员之外,用户需求者,开发部门的管理者,软件设计、实现、测试的人员都应当参加评审工作。,3. 需求获取技术 需求获取技术包括两方面的工作: 建立获取用户需求的方法的框架; 支持和监控需求获取的过程的机制。 获取用户需求的主要方法是调查研究。 (1) 了解系统的需求。软件开发常常是系统开发的一部分。仔细分析研究系统的需求规格说明,对软件的需求获取是很有必要的。 (2) 市场调查。了解市场对待开发软件有什么样的要求;了解市场上有无与待开发软件类似的系统。如果有,在功能上、性能上、价格上情况如何。,(3) 访问用户和用户领域的专家。把从用户那里得到的信息作为重要的原始资料进行分析;访问用户领域的专家所得到的信息将有助于对用户需求的理解。 (4) 考察现场。了解用户实际的操作环境、操作过程和操作要求。对照用户提交的问题陈述,对用户需求可以有更全面、更细致的认识。 在做调查研究时,可以采取如下的调查方式: 制定调查提纲,向不同层次的用户发调查表。 按用户的不同层次,分别召开调查会,了解用户对待开发系统的想法和建议。 向用户领域的专家或在关键岗位上工作的人个别咨询。 实地考察,跟踪现场业务流程。 查阅与待开发系统有关的资料。 使用各种调查工具,如数据流图、任务分解图、网络图等。 为了能够有效地获取和理清用户需求,应当打破用户(需方)和开发者(供方)的界限,共同组成一个联合小组,发挥各自的长处,协同工作,分层数据流图的示例,分层数据流图的修改原则,画数据流图的基本步骤概括地说,就是自外向内,自顶向下,逐层细化,完善求精。检查和修改的原则为: 数据流图上所有图形符号只限于前述四种基本图形元素。 顶层数据流图必须包括前述四种基本元素,缺一不可。 顶层数据流图上的数据流必须封闭在外部实体之间。 每个加工至少有一个输入数据流和一个输出数据流。 在数据流图中,需按层给加工框编号。编号表明该加工处在哪一层,以及上下层的父图与子图的对应关系。,分层数据流图修改的原则, 规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。 可以在数据流图中加入物质流,帮助用户理解数据流图。 图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”,表明流动的数据是什么。加工的名字应当是“名词宾语”,表明做什么事情。 数据流图中不可夹带控制流。 初画时可以忽略琐碎的细节,以集中精力于主要数据流。,3.概念模型和规范化 对数据的分析,1、概念模型:描述从用户角度看到的数据 实体 -联系图(Entity - Relationship Diagram),3.概念模型和规范化,例:,3.概念模型和规范化,2、范式(Normal Forms):消除数据冗余的程度 IBM E. F. Godd 例:,*Keyword:可唯一地标识一个元组的属性,1 - NF:所有属性都是原子值,即不出现“表中有表”,2 - NF:在 1-NF 基础上,每个non-key-word都由整个key word 决定(而非依赖于key word 的一部分)。例:“Major”实际上由“ID”的第6、7位决定,可省去。,3 - NF:在 2-NF基础上,non-key-word之间无从属关系。,4.图形工具,1、层次方框图 (Hierarchy) 描绘数据的结构 例:A Room hierarchy based on an interior designers perspective.(组成),例:P.68 图 3.5,4.图形工具,2、Warnier Diagram:,例:P.46 图 3.4,4.图形工具,3、IPO图(Input / Process / Output):简要的算法描述,1. 校验 主记录 2. 校验 事务记录 3. 更新 主记录,旧的主文件 事务文件,有效的 主记录 有效的 事务记录 更新后的 主文件,5.验证要求(Requirements Validation),方法: 人工审查 初步用户手册 Prototyping 使用软件工具 完整性、一致性,5.验证要求,例1:Software Requirements Engineering Methodology (SREM) (TRW Corporation, 1977) SREM = Requirements Statement Language (RSL) + Requirements Engineering Validation System (REVS),5.验证要求,Project Part 需求规格说明书,上交书面报告,两星期内完成。 截止日期:10月23日。 每迟交一日,多扣1分,
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号