软件工程的需求分析.ppt

软 件 工 程 * 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 求职应注意的礼仪 求职时最礼貌的修饰是淡妆 面试时最关键的神情是郑重 无论站还是坐，不能摇动和抖动 对话时目光不能游弋不定 要控制小动作 不要为掩饰紧张情绪而散淡 最优雅的礼仪修养是体现自然 以一种修养面对两种结果 必须首先学会面对的一种结果----被拒绝 仍然感谢这次机会，因为被拒绝是面试后的两种结果之一。 被拒绝是招聘单位对我们综合考虑的结果，因为我们最关心的是自己什么地方与用人要求不一致，而不仅仅是面试中的表现。 不要欺骗自己，说“我本来就不想去”等等。 认真考虑是否有必要再做努力。 必须学会欣然面对的一种结果----被接纳 以具体的形式感谢招聘单位的接纳，如邮件、短信 考虑怎样使自己的知识能力更适应工作需要 把走进工作岗位当作职业生涯的重要的第一步，认真思考如何为以后的发展开好头。 Thank you * * 软 件 工 程 * 在数据库分析过程中所考虑的因素之间存在着复杂的相互关联。改变其中的任何一个因素都会（潜在地）影响其它的因素。所以必须在各个因素之间进行折衷。 这种折衷包括专用性和通用性的折衷、信息关联程度、扩充潜力及操作特性等方面的折衷。 考虑信息关联程度和扩充潜力（包括信息规模和信息内容两方面）主要基于需求分析和设计阶段分派给数据库的任务。 软 件 工 程 * 第三章 需求分析 获取需求 1.需求获取原则 2.需求获取技术 3.需求调研方法 4.需求获取步骤 5.需求表达与整理 6.需求确认 需求分析 1.需求分析目标 2.需求分析任务 3.需求分析方法 4.需求分析过程 5.需求建模 1）功能建模 2）数据建模 3）行为建模 6.结构化分析方法 - E-R图 - 数据字典 - 状态-迁移图 7.实例 需求规格说明书 需求评审 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软件需求规格说明的基本原则： 功能与实现分离，描述要“做什么”而不是“怎样实现” 要求使用面向处理的规格说明语言，从而得到“做什么”的规格说明。 如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 规格说明必须包括系统运行的环境。 3.6 需求规格说明的原则 软 件 工 程 * 系统规格说明必须是一个认识的模型，而不是设计或实现的模型。 规格说明必须是可操作的。 规格说明必须容许不完备性并允许扩充。 规格说明必须局部化和松散的耦合。当信息被修改时，只要修改某个单个的段落，能够很容易地加入和删去一些段落。 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 软 件 工 程 * 需求评审的内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求； 与所有其它系统成分的重要接口是否都已经描述； 3.7 需求评审 软 件 工 程 * 原型开发技术 可执行规格说明 基于场景 (scenario) 的设计 自动程序设计 专用语言 可复用(reusable)的软件 简化假设 软 件 工 程 * 1. 可执行规格说明 可执行规格说明是用于需求规格说明的一种自动化技术。使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。包括 代数规格说明 有限状态模型 可执行的数据流图 软 件 工 程 * (1) 代数规格说明 使用集合、定义于这些集合上的函数和定义于这些函数上的方程来描述对象。规格说明的操作语义用这些方程表示。 举例：定义一个无界的栈及其操作 NEW_STACK：→ Stack PUSH：Stack，Element → Stack POP： Stack → (Element | Undefined) POP( NEW_STACK ( ) ) ＝ Undefined POP( PUSH( Stack，elem) ) ＝ elem 软 件 工 程