软件项目需求分析.ppt

目录;为什么要做需求管理？;为什么要做需求管理？;什么是《需求规格说明书》？;功能性需求：用来描述系统所应提供的功能和服务 系统功能 输入输出 异常 非功能性需求：不直接与系统的具体功能相关的一类需求 安全性 可扩展性 响应时间;用例详细描述 - 格式;用例详细描述 – 示例;为什么要用静态原型法？;什么是静态原型法？;静态原型法的实施;需求管理小结;为什么要做设计？;什么是软件设计？;概要设计 描绘出软件的概貌 详细设计 在概要设计的基础上再将其细化，得到一个非常接近于源代码的设计表达形式 ;软件概要设计;软件详细设计(1);软件详细设计(2);5.1 需求分析是软件项目的立足之本;1.软件需求在软件项目中的作用： ;2.需求分析主要工作内容;3.需求分析阶段的主要任务;这一阶段，系统分析人员应该将自己对客户需求及问题的理解与自己所拥有的软件开发经验结合起来，以便发现哪些需求是由于用户的片面理解和短期行为所提出的不合理的要求，哪些要求是由于尚未提出但拥有真正价值的潜在要求。;以需求模型为基础，考虑问题的软件可解性，生成需求规格说明书和初步的用户手册。 需求规格说明书包含对目标系统外部行为的完整描述、需求验证标准以及用户对系统在性能、质量、对维护性等方面的要求。 用户手册则包括用户界面描述以及有关目标系统使用方法的初步构想。;（3）需求验证;4．软件需求的抽象层次;一组完整的软件需求包含5项内容：;系统需求的描述语言 ;系统需求的分类 ;非 功 能 需 求 ;5.需求分析一般包含4个过程;6.需求分析的工作模式;第一步:“访谈式”;图 需求分析第一阶段角色及工作流程;第二步:“诱导式”; 配合; 在前两个阶段成果的基础上，进行具体的流程细化，数据项的确认阶段。 这个阶段的分析人员需要完成明确的业务流程报告、数据项描述，最好能够提供修改后的DEMO系统，并能清晰地向用户描述系统的业务流程设计目标。 用户可以通过审查业务流程报告、数据项描述以及通过操作开发方提供的DEMO系统，提出反馈意见，并对已经完成并可接受的报告、文档签字确认。; 配合;7.软件需求文档;8. 需求??析阶段性成果;《用户需求说明书》与《需求规格说明书》的主要区别;软件需求规格SRS说明书;5.2 需求分析阶段的团队组织;项目管理 委员会;1.在需求分析阶段参与项目的人员及工作职责如下;(5)配置管理人员:对于通过评审的需求说明书纳入软件的配置管理项; (6)用户方的技术人员:用户方参与项目的技术负责人员,通过与系统分析人员的沟通,确定系统的技术实现方案。要求该人员具有对需求说明书中系统技术方案的最终签字认可权; (7)用户方的业务人员:用户方参与项目的业务负责人员,经过与系统分析人员的沟通,确定未来软件系统实现的具体功能和业务模型。要求该类人员对需求说明说中的业务需求具有最终签字认可的权利.; 把所有与需求直接相关的活动统称为“需求工程”。 需求工程的活动分为两大类： 　一类属于需求开发； 　　　需求开发的目的是：通过调查与分析，获取用户需求并定义产品需求。 　另一类属于需求管理： 　　　需求管理的目的是：在用户与开发人员方对需求有着共同理解的基础上，维护需求的完整性和一致性，并控制需求的变更;;5.3.1 需求开发;1.需求获取的主要方法;(1)基于调查的需求获取方法 (2)基于用例的需求获取方法 (3)基于原型法的需求获取方法 ;（1）需求调查准备。一般围绕以下3个中心进行: 首先，要确定需求调查的内容； 其次，应当确定需求调查的方式； 最后，确定调查的时间、地点和人员等 （2）进行需求调查并记录。 （3）分析用户的需求信息并撰写《用户需求说明书》 （4）进行需求确认工作。;案例研究—学生管理系统;案例说明——事实的发现与收集 ;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;案例说明——事实的发现与收集;5.3.2 结构化的分析方法——数据流与数据字典;一、数据流图;3. DFD的主要符号表示;4. DFD的主要处理步骤;5. 功能建模和信息流;人事工资管理系统的顶层DFD(概图)范例;;;外部实体;二、数据流图定义及基本组成分析;（4）数据流：与所描述系统信息处理功能有关的各类信息的载体，是各加工环节进行处理和输出的数