3-1 需求分析.pptx

软件需求分析;软件需求分析;对软件需求的认识;4;项目成败因素分析;需求错误的频率;在生命周期不同阶段修复缺陷的相对成本;;为什么会导致发生不合格的需求说明 ;无足够用户参与;用户需求的不断增加 ;变更影响;模棱两可的需求 ;过于精简的规格说明 ;忽略了用户分类 ;不准确的计划;不准确的计划;高质量的需求过程带来的好处 ;什么是好的需求;软件需求分析;软件需求工程的概念;需求获取、需求分析、需求定义、需求验证;软件需求过程;需求工程过程的主要活动;需求开发过程;需求开发过程;基本的软件需求过程;需求开发与需求管理之间的界限 ;需求获取的目的;需求获取面临的挑战：;需求获取的主要步骤;定义项目的视图和范围 在项目开始之前，在所有干系人中竖立一个共同的愿景，明确供需各方的权利和义务，并发布得到共识的、对项目目标的理解。 在共同愿景的确立过程中要做两件事情: 定义项目范围：项目范围描述项目该做什么，不该做什么，可通过陈述和图表（如用例图或数据流图）来表达； 定义高层需求：高层需求不涉及过多的细节，主要通过它表示系统的概貌，从而建立需求模型。;寻求需求的来源 软件需求的来源取决于目标系统的性质和开发环境。典型的需求来源是： 与潜在用户进行交谈和讨论 描述现有产品或竞争产品的文档 系统需求规格说明 当前系统的问题报告和改进要求 市场调查和用户问卷调查 观察用户如何工作 用户工作的场景分析 事件和响应;根据所受限制不同，不同类型的应用系统能够从用户那里获取需求的比例也不同。 所谓限制，是指受客观物理规律的限制。;如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求依赖人，因为它是一个想象出来的产品。 应用受到的限制越少，能从人们那里获得的需求比例越大。 识别用户类和用户代表 确定目标系统的不同用户类型； 挑选出每一类用户和其他项目相关者的代表并与他们一起工作; 商定谁是项目需求的决策者。;不同用户类可能还有不同的非功能需求。 不同用户类的需求甚至可能发生冲突，导致需求不一致。 即使所有利益相关者的需求一致，也可能由于实现代价高昂，需求不能得到完全满足。 用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。 分析员必须在项目初期便确定产品有哪些不同的用户类，并描述它们的特点，这样就能从每个重要用户类的代表那里获取用户需求。;每一个项目，包括企业信息系统、商业应用软件、数据包、集成系统、嵌入式系统、互联网Internet应用程序等，都需要有合适的用户来提供用户需求。 确定目标系统的业务工作流 具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则。 例如，针对信息系统的需求调研方法如下： 1) 调研用户组织结构、岗位设置、职责定义，从功能上区分子系统，明确系统范围和目标。 ;调研每个子系统的处理流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。 对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。 对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。 需求调研的形式可根据需求的来源来确定。 ;访谈和文档记录 大部分需求获取是人与人沟通的活动，这些活动经过精心组织，以准确获得最好的效果。 准备和访谈客户的过程如下： 访谈之前 策划访谈的目标和内容： 通过查阅组织的组织结构图，搞清业务部门的各种角色，选择访谈的主要对象 预约访谈时间 准备访谈内容，拟定一些具体问题 ;访谈过程中 引导访谈对象。发现业务流程背后的用户需求： What：系统要处理的业务内容是什么。 When：系统业务过程的主要活动什么时候发生，持续时间有多长。 Who：系统业务过程的各个活动中会有哪些相关的人、物、事（系统）。? Why：为什么会出现这样的问题。? Where How：为完成系统的业务目标所采用的方法。 数据流 数据元素;不管用户说什么，分析员首先要分析，然后置疑，从而引导用户说出他们真正的需求所在。 访谈之后 根据标准模版撰写软件需求规格说明SRS，拟定客户需求草稿 通过电子邮件征求客户意见 ;需求调研完成的信号;需求的整理与描述 开发反映主要业务规则的用例（或数据流图或状态图），与用户沟通。 收集用户的质量属性信息和其他非功能需求，将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。 分类在用例（或数据流图）中涉及的数据，包括数据的组成和数据之间的关系。 详细拟订用例（或数据流图）的规格说明，建立功能模型，并进行审查。 开发并评估界面原型，建立接口规范和信息流传输规则。 从功能描述中开发概念测试用例，验证用例（或数据流图）、功能需求和原型。;需求