Ch03 需求获取0.pptVIP

MPMail: zhaohui@mail.ccut .edu.cn 第3章 需求获取 3.1 确定需求开发计划 3.2 确定项目的目标和范围 3.3 确定调查对象 3.4 实地收集需求信息 3.5 确定非功能需求 3.6 收集需求信息中应注意的问题 3.7 使用场景技术的需求获取 第3章 需求获取 需求获取是软件开发中最困难、最关键、最易出错和最需要交流的活动。 需要从用户提供的大量信息中分析和理解用户真正的需要。 3.1 确定需求开发计划 基本任务： 确定需求开发的实施步骤，并给出收集需求活动的具体安排和进度 。 注意事项： 只考虑与需求开发相关的工作； 应考虑困难性和灵活性； 应考虑书写和整理需求规格说明及其文档所花费的时间。 3.2确定项目的目标和范围 基本任务： 根据项目目标把项目相关人员定位到一个共同的和明确的方向上，并决定软件系统的范围 3.2确定项目的目标和范围 注意事项： 目标需求会来源于各个不同的人； 不同人从不同角度提出目标需求； 可能会存在冲突 3.2确定项目的目标和范围 确定范围的好处： 可以判断用户所提出的需求信息是否对项目合适； 范围之外的有价值建议可以适当改变范围，适应需求。 3.3确定调查对象 基本任务： 明确地确定来自不同层次的需求来源和用户，并将其分类。 根据需求层次区分用户： 提出目标需求的用户； 提出业务需求和功能需求的用户； 软件开发人员，主要是指系统分析员。 3.3确定调查对象 3.3确定调查对象 3.3确定调查对象 几个典型的软件需求来源： 直接和间接使用软件系统的用户； 系统需求规格说明； 市场调查和用户问卷调查； 已开发出的和待开发的同类软件系统的描述和文档； 对人工系统的存在问题的报告和增强要求； 观察正在工作的用户； 用户工作内容的分析。 3.3确定调查对象 解决不一致和含糊需求的决策者： 用户代表——当个别用户与大多数同类用户不一致； 领导层和高管——用户类之间不一致； 开发人员——不同类型用户对产品设计的不一致； 用户代表——部门经理和部门真正用户不一致； 用户——开发人员与用户不一致； 市场部门为主——市场部和开发部不一致； 3.4实地收集需求信息 3.4实地收集需求信息 3.4实地收集需求信息 实地调查的步骤： 向掌握“全局”的负责人调查； 向部门负责人调查； 向业务人员调查。 3.4实地收集需求信息 实地收集需求信息的方式： 以座谈会的方式； 以书面咨询的方式； 利用用例表示方法。 3.4实地收集需求信息 需求信息分类： 目标需求； 用例说明； 业务规则； 功能需求； 性能需求； 外部接口需求； 限制； 数据定义； 解决方案。 3.5确定非功能需求 非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标，因此很难根据这些需求来评价软件系统，这也是开发出来的软件系统与用户所满足的软件系统之间存在差异的主要原因。 3.5确定非功能需求 用户所关心的非功能需求： 可靠性； 可扩充性； 安全性； 互操作性； 健壮性； 3.5确定非功能需求 收集非功能需求常用方法： 将不同用户类代表提出的可能很重要的非功能需求进行综合，并根据其中的每个需求设计出许多方法，然后根据用户的回答，使这些需求更明确化； 开发人员与用户一起对每一个非功能需求制定可测试和可验证的具体标准； 设计与非功能需求相冲突的假设示例，利用反例来提示用户。 3.6 在收集需求信息中应注意的问题 应能适当的调整收集范围； 尽量把用户所持的假设解释清楚，特别是发生冲突的部分； 尽量理解用户用于表达他们需求的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语； 在收集需求信息时，应尽量避免受不熟悉细节的影响； 应尽量避免讨论一些具体的解决方案； 需求信息收集工作的结束。 3.7使用场景技术的需求获取 场景的定义 所谓场景是指用户与软件系统实现某个目标而进行交互活动过程的描述。 场景的构成 执行者（用户） 进入场景前系统状态的描述 执行者的目的 动作和事件系列（包括正常或非正常事件） 3.7使用场景技术的需求获取 场景应具有的特征 场景代表某些用户可见的功能，实现一个具体的系统需求； 场景总是被参与者启动的，并向参与者提供可识别的信息； 场景必须是完整的。 3.7使用场景技术的需求获取 例：关于切断ＰＣ机电源的场景 3.7使用场景技术的需求获取 执行者（用户）：王某； 进入场景前系统状态的描述：使用ＰＣ机的经验是１年。几乎每天使用。另外，今日发送电子邮件的工作已结束； 执行者的目的：退出Windows98，并切断ＰＣ机的