软件需求实践(一)课件

1、需求分析师培训第一课需求与需求工程需求是什么?用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。 用户有不同类型： 管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人软件需求从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。有时还需要考虑相关联的硬件、环境方面的需求 业务需求 用户需求 软件需求需求定义需求捕获需求分析功能需求功能需求是需求的主体，是需求的本质功能需求

2、定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作功能需求也称为行为需求零散（需求项）整理（特性、用例、用户故事）功能需求的要点在于组织!质量属性产品必须具备的属性或品质 McCall体系：运行(正确性、可靠性、效率、完整性、使用性)、修正(维护性、测试性、灵活性)、转移(移植性、复用性、共运行性)非功能需求重在有效传递!1)定性场景定量2)全局局部+全局3)零散可追踪需求的“冰山模型 ”与应对需求开发与管理需求定义的工作内容出发点：问题/机会项目目标(业务需求) 如何破解混沌不清的项目目标?产物： 项目型：POS文档 产品型：Vision文档明确项目的范围：传统

3、模式：列出功能模块合理模式：可行性研究：技术、 经济、社会、 内部溯源 外部寻因列出涉及的人和事需求定义的时机正常模式：项目立项时负责人：由业主/产品经理完成问题：现在通常做得不好原因：立项结果较空(目标空/范围空)补救模式：项目开工前困难：大多数人感到多此一举必要性： （“六拍”项目经理）需求获取的误区应收集什么信息： 问题域的描述-业务模型 要求解决的问题列表（需求） 用户对解系统的行为或结构施加的任何约束缺乏计划性：随意、走过场，预先没计划缺乏科学性：未从本质入手捕获对象不明确，甚至造成岐义过于迷信现有文档过于迷信“听”到的东西需求获取技术阅读背景资料头脑风暴讨论分析文档考古面谈（用户访

4、谈）联合开发用户调查需求剥离现场观摩情节串联板用例和场景编写规约“正规”的开发组织都重视，但常“重视过度” 束之高阁 事后补文档规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同需求开发与需求管理的分界需求管理 vs. 项目管理需求管理的主题是“需求项”，关乎优先级、尽力满足；项目管理的主题是“项目” ，关乎成本、进度需求管理是项目管理的支撑 WBS 优先级 基线需求管理管理的是项目中的价值维需求管理是项目管理的子集需求管理的主要活动基线：救火队严谨团队变更：不是避免，而是控制。通过统一渠道、统一平台（并分类）做到避免错误产生的变更、减少变化产生的变更跟踪：高阶活动，包括用

5、户需求软件需求，软件需求软件需求、软件需求设计原则的跟踪版本控制：历史变化的管理与跟踪状态管理：管理过程中的动作需求与需求工程需求分析-内容与形式需求分析与建模不应该是孤立的行为 ，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题 团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法 对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化 ，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化信息系统的基本类型信息系统需求的本质 1流

6、程电子化-业务事件为中心 利用信息化系统改进、固化流程 事务处理系统尤其明显 工作流定义、流程改进、再造 工作流模型数据信息化-Report为中心 业务术语，业务实体 需要留存哪些数据？谁需要共享？ 需要什么报表？有哪些数据分析规则？OLTP的需求线索：业务事件传统问题2：流程太零散 流程是分层的：把握管理视野 流程基本分类：生产类、管理类、支撑类业务事件是流程的触发点BPR 、BPD？MIS的需求线索：Report何时开始梳理此类需求？实施要点：类别要点说明Why目的从管理场景出发，借助对管理控制点的理解来理解报表的目的使用部门/职位了解报表的使用者，以便有针对性地调研相关场景诸如用户数量、

7、查询频率等非功能性场景描述What关联实体以类图或E-R图表示，说明数据的来源关键指标及计算规则细化推导出关联的字段，以及派生属性的计算方法，指导报表数据视图的实现How展现形式以虚拟窗口等形式说明最终的呈现方式输入输出需要说明是否打印，以什么格式提供等其他信息报表的常见分类信息系统需求的本质 2个人知识转换为企业知识-模型为中心 将知识工作的经验转换成模型 业务场景的分析与抽象是重点 提高速度、提高质量信息决策化-决策模型为中心 业务场景的分析与抽象是重点 将非程序化问题分解 成多个子问题 提出所需的数据模型、经验模型不同视角下的信息系统需求大纲-SERU模型Subject：主题域，将一个复

8、杂的大系统分解成由确定接口相互连接的多个子系统构件图 /System（上下文关系图、事件列表、Report列表）/SubjectEvent：业务事件，信息系统行为主线条（业务流程图、领域类图E/R图、用例图opt）/EventReport：查询、分析、统计等管理动作（目的、数据、虚拟屏幕） /ReportUse case：需求管理的分子！SERU模型需求复用流程级需求复用流程内需求与需求工程需求分析师需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求

9、建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求必备技能：倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力 需求分析师必备知识：现代需求管理技术、各种软件开发生命周期、领域知识需求分析员的来源：用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统）需求相关沟通示例信息处处长1、系统部署过程汇报2、系统培训情况汇报3、系统业务试用应用情况汇报已开始应用，但还有一些未决问题，已安排人沟通、落实、解决：1)、2)、3)4、系统试用期间服务情况汇报5、进度、效果总结(良好)转换思维示例例如，经典的马的遍历问题：寻找一系列的移动步骤，使马走完每个方块，而落入任何一个方块一次本源：你的灯还亮着吗?问题：日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。解决方案一：“警告！前有隧道请打开车头灯”新问题：隧道出口风景很美，返回时发现汽车没电忘了关车头灯！解决方案二：出口处立标牌“关掉车灯”新问题：夜行车也会关掉车灯？解决方案三：建充电站新问题：维护开支大，充电站也会出故障本源：你的灯还亮着吗?解决方案四：授权私人经营充电站新问题：风景区商业化，政府与游客均不接受解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请