[工学]第四章 软件需求分析.ppt

* * * * * * * * * * ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 5. 需求建模 建模可以帮助软件开发人员更好地理解需求。它着重于描述系统必须做什么、而不是如何去做系统。该过程需要给出系统的逻辑视图（逻辑模型）以及系统的物理视图（物理模型）。 逻辑模型给出软件要达到的功能和处理数据之间的关系，而不是实现的细节。 软件需求的物理模型给出处理功能和数据结构的实际表示形式，这往往是由设备决定的。 ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 常用的建模分析方法 面向数据流的结构化分析方法（SA）； 面向数据结构的Jackson方法； 面向对象的分析方法（OOA）； 建立动态模型的状态转换图、PetriNet等 ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 6. 编制需求分析文档 软件需求规格说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 好的《软件需求规格说明书》应具备如下属性： 正确、清楚、无二义性、一致、必要、完备、可实现、可验证、确定优先级、阐述“做什么”而不是“怎么做”。 ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 7. 需求确认 目的 开发方和客户对需求文档进行评审，并作书面承诺。 角色与职责 开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之具有商业合同效果。 启动准则 需求文档如《用户需求说明书》和《软件需求规格说明书》已经完成。 输入 需求文档如《用户需求说明书》和《软件需求规格说明书》 主要步骤 第一步：非正式需求评审 第二步：正式需求评审 第三步：获取需求承诺 输出 《需求评审报告》和书面的需求承诺 结束准则 需求文档通过了正式评审，并且获得开发方和客户的书面承诺。 度量 项目经理统计工作量和上述文档的规模。 ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 8. 需求分析评审 评审的主要内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求，有没有遗漏、重复或不一致的地方； 与所有其他系统成分的重要接口是否都已经描述； 所开发项目的数据流与数据结构是否足够，确定； 所有图表是否清楚，在不补充说明时能否理解； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.3 软件需求分析过程 系统的约束条件或限制条件是否符合实际； 开发的技术风险是什么； 是否考虑过软件需求的其他方案； 是否考虑过将来可能会提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 软件开发计划中的估算是否受到了影响。 评判需求优劣的主要指标有： 正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。 * * * * * * * * * * * * * * * * * * * * * * * * * * ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 * ? 2007 BUPT TSEG ? 2007 BUPT TSEG 软件工程Software Engineering 第四章 软件需求分析 黄 海 bupthuanghai@ ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 需求定义 软件需求分析的目标及任务 软件需求分析建模原则和方法 软件需求工程 软件需求分析过程 ? 2007 BUPT TSEG 北京邮电大学 通信软件工程中心 §4.1 需求定义 1. 需求的定义 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么 Boehm给出软件需求的定义：研究一种无二义性的表达工具，它能为用户和软件人员双方都接受，并能够把“需求”严格地、形式地表达出来。 “开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。” ? 2007 BUPT T