第4章需求基础解说.ppt

4.2.3 用户和开发人员组成联合小组 选定一种易于理解、简洁、精确的表示机制作为共同语言； 确定专门的记录员； 专人负责会议的议程和资料的综合、整理。 4.3 需求建模 借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。 需求获取的内容 功能需求：开发软件在职能上应做什么。 性能需求：软件开发的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。 环境需求：软件系统运行时所处的环境要求。 用户界面需求：软件与用户界面的友好性是用户能够方便有效、愉快地使用该软件的关键之一。 需求获取的内容（续） 用户或人为因素：用户类型是什么？各种用户熟练程度如何？用户理解、使用系统的难度如何？ 文档需求：需要哪些文档？文档针对那些用户 数据需求：输入、输出数据的格式？接收、发送数据的频率？数据的精准性和精度？ 资源需求：开发软件运行时所需的数据、软件、内存空间等各项资源；软件开发、维护所需的人力、支撑软件、开发设备等。 需求获取的内容（续） 安全保密要求：把软件运行的安全需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能得到必要的保证。 软件成本消耗与开发进度需求：软件项目立项后，要根据合同规定，对软件开发的进度和各项步骤的费用提出要求，作为开发管理的依据。 质量保证：系统的可靠性、可维护性、可扩展性、可移植性如何？ 需求模型 需求分析阶段构建的模型不涉及软件实现的细节。 目标软件系统的模型是用来描述系统所涉及的信息、处理功能及实际运行时的外部行为。 软件模型是软件设计和实现的基础。 4.4 需求描述阶段 软件需求规格说明书(SRS)的作用 提供一个用户、分析人员和软件设计人员对开发软件的共同的理解； 相当于用户和开发单位之间的一份技术合同； 是今后各阶段设计的基本依据； 是今后验收测试阶段对软件进行确认和验收的基准。 4.4.1 需求规格说明书主要内容 ⑴ 概述：从系统的角度描述软件的目标和任务。 ⑵ 数据描述 ① 数据流图 ② 数据字典 ③ 系统接口说明 ④ 内部接口说明 ⑶ 功能描述 ① 功能 ② 处理 ③ 设计的限制 4.4.1 需求规格说明书主要内容（续） ⑷ 性能描述 ① 性能指标 ② 测试种类 ③ 预期的软件响应性能 ⑸ 参考文献目录 ⑹ 附录 2、需求规格说明书的基本要求 (1) 完整：问题考虑全面； (2) 一致：前后内容要一致； (3) 精确：数据、任务要精确； (4) 无二义性：不提摸棱两可的问题； (5) 符合标准：按国家、国际标准书写； (6) 易维护：应便于修改。 3、主要负责人—分析员 资历较高 熟悉计算机技术 对用户的相关业务了解 发挥中间人的作用 4、需求规格说明书举例 P47 例4.4.1 P48 例4.4.2 需求规格说明书实例 P51 4.5 “图书管理系统 ”需求规格说明书 怎样写需求分析报告 作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题 如图 S = { D1，D2，D3，… Dn } Di = { P1，P2，P3，… Pm } Pj = { F1，F2，F3，… Fk } 怎样写需求分析报告 4.4.2 需求评审阶段1、评审标准 正确性：需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。 无歧义性：对需求规格说明书中的任何语法单位只能有一个明确统一的解释。 完全性：需求规格说明书中不能遗漏任何用户需求。 可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。 1、评审标准（续） 一致性：需求规格说明书的各部分之间不能相互矛盾。 可理解性：需求规格说明书对于用户、设计人员和测试人员应便于理解。 可修改性：在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。 1、评审标准（续） 可追踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。 2、评审过程 需求评审以用户、分析人员和系统设计人员共同参与的会议形式进行。 分析人员： 软件产品的总目标； 产品的主要功能