《第2章需求获取（2）》
n本节主要学习以下内容：
² 实地收集需求信息
² 确定非功能需求
² 在收集需求信息中应注意的问题
² 使用场景技术的需求获取
本节重点
需求信息的分类、需求获取的方法。
本节难点
需求获取中场景技术的应用方法。
授课课时
2课时
教法建议
首先介绍需求最开始是编写需求调研计划，按照调研计划中的内容展开课程内容，然后讲解如何完成各项的编写任务和注意问题。
回顾上节课的主要内容。
本节主要讲解使用实地收集需求的方法和内容以及步骤。
引入：
实地收集需求信息的意义。 [直述]
内容：
实地收集需求信息的任务：实地收集需求信息阶段的任务就是到现场实地调查和与用户交流，收集和理解用户需求信息。
实地收集需求信息可能面临的困难：
（1）能提出软件需求的用户可能觉得他们没有充分的时间与开发人员进行交流和讨论；
（2）有时用户希望通过简单的方法和说明，或者通过简单回答开发人员的询问后，软件开发人员就能清楚地理解他们的需求，而不需要花费太多的时间进行讨论；
（3）用户和开发人员都只考虑自己的利益；如：有些用户由于缺乏使用计算机的经验，导致产生畏难情绪；有些用户认为开发软件系统自己的关系不大，对待需求信息的收集工作采取消极的态度。
（3）用户本身不能提出明确的需求；开发人员缺乏用户的业务知识，而用户也缺乏计算机方面的知识，导致双方在交流中产生许多的困难，以至收集工作难以进行。
实地调查的步骤：
（1）向掌握“全局”的负责人调查；
（2）向部门负责人调查；
（3）向业务人员调查。
实地收集需求信息的方式
（1）以座谈会的方式；
（2）以书面咨询的方式；
（3）利用用例表示方法。
需求信息可大致分类如下：
目标需求；用例说明；业务规则；功能需求；性能需求；外部接口需求；限制
[详细讲解，并举例说明]
内容：
非功能需求是衡量软件能良好运行的定性指标。由于缺乏定量指标，因此很难根据这些需求来评价软件系统，这也是开发出来的软件系统与用户所满足的软件系统之间存在差异的主要原因。
用户所关心的非功能需求主要有：
可靠性；可扩充性；安全性；互操作性；健壮性；易使用性；可维护性
在收集非功能需求信息时常用的方法：
将不同用户类代表提出的可能很重要的非功能需求进行综合，并根据其中的每个需求设计出许多方法，然后根据用户的回答，使这些需求更明确化；
开发人员与用户一起对每一个非功能需求制定可测试和可验证的具体标准；
设计与非功能需求相冲突的假设示例，利用反例来提示用户。
[详细讲解，并举例说明]
内容：
应能适当的调整收集范围；尽量把用户所持的假设解释清楚，特别是发生冲突的部分；
尽量理解用户用于表达他们需求的思维过程，特别是尽量熟悉和掌握用户具有的一些专业知识和术语；
在收集需求信息时，应尽量避免受不熟悉细节的影响；
应尽量避免讨论一些具体的解决方案；需求信息收集工作的结束。
[详细讲解，并举例说明]
内容：
场景：所谓场景是指用户与软件系统实现某个目标而进行交互活动过程的描述。
场景的构成：执行者（用户）；进入场景前系统状态的描述；执行者的目的；动作和事件系列（包括正常或非正常事件）
场景应具有的特征：
（1）场景代表某些用户可见的功能，实现一个具体的系统需求；
（2）场景总是被参与者启动的，并向参与者提供可识别的信息；
（3）场景必须是完整的。
场景的种类：
按执行者的目标能否实现分：正常场景和失败场景；
按场景描述的内容分：正向场景和逆向场景；
场景之间亦可以建立关系以及精化处理。
需要注意的问题
场景的数量，即一个软件项目应该写多少个场景没有一个限制标准，主要视项目的规模和复杂性而定。但如果场景数量过大，往往也易加大分析和理解的难度。
场景的冗余问题。应尽量避免场景描述的内容发生重叠，可根据实际情况合并和去掉一些内容重叠的场景。
应防止场景描述内容的冗长。
[详细讲解]
本节学习了以下主要内容：
2. 确定非功能需求
3. 在收集需求信息中应注意的问题
4. 使用场景技术的需求获取
考核点1：实地收集需求信息的步骤
考核点2：场景技术的概念
总结实地考察的方法。
总结实地考察的方法
（注：在此写上个人在授课过程中所遇到的教案中所没有涉及到的特殊问题及其解决方法或解决方案，也可以总结自己的授课体会，课程体系、教材的不足等。）
授课教师（签名）： 授课时间： 授课班级：
