第2讲 需求获取.pptVIP

第3章 需求获取 第3章 需求获取 需求获取过程 第3章 需求获取 3.1 确定需求开发计划 3.2 确定项目的目标和范围 3.3 确定调查对象 3.4 实地收集需求信息 3.5 确定非功能需求 3.6 在收集需求信息中应注意的问题 3.7 使用场景技术的需求获取 3.1确定需求开发计划 确定需求开发计划的基本任务是确定需求开发的实施步骤，并给出收集需求活动的具体安排和进度 。 3.2确定项目的目标和范围 3.2确定项目的目标和范围 在收集目标需求时，目标需求会来源于各个不同的人，这些人对要开发的软件系统及该系统最终能为用户或客户提供哪些价值有比较清楚的了解。 3.2确定项目的目标和范围 P18 自动售货机的举例 3.3确定调查对象 本阶段的基本任务是明确地确定来自不同层次的需求来源和用户，并将其分类。 应根据需求的层次来区分不同的用户： （1）提出目标需求的用户，即客户； （2）提出业务需求和功能需求的用户； （3）软件开发人员，主要是指系统分析员。 3.3确定调查对象 软件系统面临的用户是很多的，而这些用户由于所在的部门、职责和掌握的知识不同而存在差异，为了避免忽视和遗漏某些用户的情况，可以根据用户的某些方面将用户分类。 3.3确定调查对象 3.3确定调查对象 3.3确定调查对象 直接和间接使用软件系统的用户； 系统需求规格说明； 市场调查和用户问卷调查； 已开发出的和待开发的同类软件系统的描述和文档； 对人工系统存在的问题的报告和增强要求； 观察正在工作的用户； 用户工作内容的分析。 3.3确定调查对象 个别用户与其他大多数同类用户需求不一致时，决策者为用户代表。 用户类间需求不一致时，决策者为领导层和高层管理人员。 同级不同类型用户（如部门不同）需求不一致时，决策者为开发人员。 部门管理者与直接用户不致时，在满足目标需求的前提下，决策者为用户代表。 开发人员与用户或市场人员不一致时，决策者为用户或市场人员。 3.4实地收集需求信息 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使用场景技术的需求获取 场景的表示 3.7使用场景技术的需求获取 场景的种类 按执行者的目标能否实现分：正常场景和失败场景； 按场景描述的内容分：正向场景和逆向场景； 场景之间亦可以建立关系以及精化处理。 3.7使用场景技术的需求获取 使用用例的需求获取 用例通常用于描述可发生的所有事件序列，而场景则是描述其中的一部分。因此，用例也可以说是场景的集合，一个场景是用例的实例。 3.7使用场景技术的需求获取 例：自动取款机用例模型 3.7使用场景技术的需求获取 其他形式： 3.7使用场景技术的需求获取 场景技术的特点 把软件系统的需求信息文本化，有助于在实现软件系统前明确