1、v需求获取的难点在哪里？v需求获取的哪些内容？v需求获取的主要技术v表面上v实质上 范围问题 理解问题 易变问题v需求获取(requirement elicitation)是需求工程的主体。对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程 v需求获取是在问题及其最终解决方案之间架设桥梁的第一步 v需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面 v需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本 v无法陈述自己的需要v无法解释任务及原因v要求特定的解决方案v缺乏想象力-新方法v缺乏想象力-结果v矛盾的需求v抵制变更v过度的要求v满足
2、一些需求后,产生新的需求v先获取系统的总体目标，接着获取当前工作以及当前问题的信息，然后是系统应处理的详细问题。需求分析建议报告需求分析建议报告需求采集需求采集需求分析需求分析需求定义需求定义用户用户开发商开发商方法论方法论引导引导需求规格说明书需求规格说明书答：答：需求采集需求采集1需求分析需求分析2需求定义需求定义3采集什么内容？采集什么内容？系统建设目标系统建设目标业务项业务项业务流程业务流程非功能需求非功能需求从哪里采集？从哪里采集？横向：各业务横向：各业务科室科室纵向：省、部纵向：省、部标准规范标准规范经验：核心平经验：核心平台、同行业其台、同行业其他城市、现有他城市、现有系统系统怎
3、么采集？怎么采集？调查问卷调查问卷座谈座谈考察、培训考察、培训需求采集的定义需求采集的定义v访问并与有潜力的用户探讨v把对目前的或竞争产品的描述写成文档v系统需求规格说明v对当前系统的问题报告和增强要求v市场调查和用户问卷调查v观察正在工作的用户v用户任务的内容分析需求采集需求采集1需求分析需求分析2需求定义需求定义3不同层次的用户需求也截然不同不同层次的用户需求也截然不同v确定需求获取计划和问题清单v确定能够帮助刻画需求和了解他们组织的人员v定义系统将放置其中的技术环境（如计算体系结构、操作系统、电信需要）v确定“领域约束”（即特定于应用领域的业务环境的特征），这些约束将限制待建造系统的功能
4、和性能。v定义一种或多种需求获取方法v要求很多人员参与，以使得需求能够从不同的视角进行定义；确定每个要记录需求的理由。v确定有歧义的需求为原型实现的后选v创建使用场景，以帮助客户/用户更好地确定关键需求v相关人员是指那些直接或间接从开发的系统中受益的人。v效益：发现所有可能的需求源v识别项目相关人员的方法：系统潜在的最终用户 系统打算支持的业务过程描述以及与这些过程相关的人 与管理部门讨论，询问谁会受到系统引入的影响 考虑使用系统的组织的客户 负责开发和维护系统的工程师和维护人员 考虑可能希望给系统添加需求的监管机构和认证机构v措施：设计文档（相关人员列表和需求原因）明确各类人员的需求权威明确
5、各类人员的需求权威v决策层：系统建设目标、原则，业务流程优化程度决策层：系统建设目标、原则，业务流程优化程度v业务人员业务人员:业务的把握、政策的把握、业务流程的把握业务的把握、政策的把握、业务流程的把握v技术人员：数据项描述、性能需求技术人员：数据项描述、性能需求v操作人员：界面的操作风格、输入输出数据项操作人员：界面的操作风格、输入输出数据项决策层决策层技术人员技术人员业务人员业务人员操作人员操作人员v当前整体业务需求的目的和可行性陈述v系统或产品范围的限制性陈述v要求提供的需求功能列表和应用于每个需求的领域限制v将来发展的设想v明确服务器、客户机的软、硬件及性能要求（容量、速度、可操作性
6、等）v用户目前相关的技术人员和业务人员情况v将来最终系统操作人员的技术及业务人员情况v用户需求的系统及用户本身或其它系统的接口要求v一组使用场景，提供在不同运行条件下系统的使用情况v为更好地定义需求而开发的任意原型v需求理由是指关于某需求的原因的概要信息v效益：提高对需求的理解v实施v可能存在的问题 使人误解的理由 不一致的理由v领域约束是指来自于系统应用领域的系统需求v效益：领域约束经常会导致识别出关键需求v领域约束的种类 涉及到所有其他需求的总体约束 从领域相关事项导出的特殊需求v需要记录的领域信息 领域知识的一个非正式陈述 领域知识的较形式化描述 领域知识可适用的系统的类型 知识分类术语
7、 领域信息源v系统的操作环境是由主机、其他硬件和与该系统相互作用的软件系统组成。v效益：交付系统没有安装问题v定义系统的操作环境时，应该收集的信息：平台信息 接口信息 软件依赖性v访谈（面谈）与问卷调查v会议(需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会）v文档研究v任务示范（观察）v用例与角色扮演v原型设计（小规模试验）v研究类似公司v需求分析前最好明确系统要采用的技术体系v组织队伍v准备相应的文档v联系和了解用户方v编写计划v访谈适合于了解域中的当前工作以及当前问题.v作为主要的获取技术v局限就是需求获取障碍v访谈计划与问题清单（访谈模板）v访谈方式 开放式访谈 结构式访谈v
8、访谈问题类型 开放式问题 封闭式问题v当潜在使用者太多或分布太广时，可以考虑采用问卷调查方式。v一般来说，问卷调查适合于大型企业或公众信息系统的设计，因为它所涉及的使用范围或对象太广，需求分析人员无法逐一亲自调查，所以利用问卷调查方式来收集使用者需求比较好。v如何进行问卷调查：设计问卷、预先测试、调查对象划分、问卷总结等v一种适用于任何情景的技术。v如何计划并实施需求专题讨论会 专题讨论会准备 实施 总结v研究企业内部的规章制度、企业或部门报表、工作流程（手册）是了解企业工作流程的第一步工作。v一般来讲，企业组织内部很少有完整的文件资料来详细描述清楚企业业务工作流程的全貌，同时可能工作流程已经
9、经过多次修改，而文件往往没有及时更新，因此用这种方法收集需求信息常有过时之虑。v是交叉检查访谈信息的另一个方法。v一般來說，现场观察所获得的资料比查阅资料正确性要高，也能验证所收集资料的正确性和补充资料的不完整，通过观察可以获得第一手的资料。v观察能大大地增加对当前工作和部分相关问题的了解，也能作为其它信息的检查v观察的局限性。往往无法捕捉到一些真正关键问题。v用例描述了用户和系统之间的交互，其重点是系统为用户做什么v用例模型描述全部的系统功能性行为v软件需求原型定义为：是软件系统的部分实现，构建该原型帮助开发人员、用户以及客户更好地理解系统的需求。v原型解决“是的，但是”问题以及“尚未发现的
10、遗址”综合症尤其有效v为“模糊”需求建立原型v准备 定义项目的视图和范围 确定用户类 确定用户代表 确定需求决策者和他们的决策过程 选择所用的需求获取技术v迭代 设计用例并设置优先级 收集质量属性的信息和其他非功能需求 详细拟订用例使融合到必要的功能需求中 评审用例的描述和功能需求 如果有必要,就要开发分析模型用以澄清需求获取的参与者对需求的理解 开发并评估用户界面原型以澄清还未理解的需求 根据用例,设计测试用例 用测试用例来论证用例功能需求分析模型和原型v如果用户不能想出更多的用例v如果用户提出新的用例,但分析员可以从其他用例的相关功能需求中获得这些新用例v如果用户开始重复原先讨论过的问题v
11、如果所提出的新需求比分析员已确定的需求的优先级都低v如果用户提出对将来产品的要求v 一个约有一个约有1000名员工的保险公司订阅了大约名员工的保险公司订阅了大约50份期刊（杂志、份期刊（杂志、报刊）。期刊在公司内部传阅，员工可以要求加入传阅队列。目前报刊）。期刊在公司内部传阅，员工可以要求加入传阅队列。目前的传阅过程是：图书室登记公司收到的期刊，为期刊附上一份传阅的传阅过程是：图书室登记公司收到的期刊，为期刊附上一份传阅名单，并交给名单中的第一位员工。期刊经由公司内部邮递系统传名单，并交给名单中的第一位员工。期刊经由公司内部邮递系统传递。员工应在三个工作日完成阅读，并在名单上签名及写上日期，递
12、。员工应在三个工作日完成阅读，并在名单上签名及写上日期，然后交给名单的下一位员工。最后一位员工阅读完毕后，将期刊交然后交给名单的下一位员工。最后一位员工阅读完毕后，将期刊交还图书室以便共用。还图书室以便共用。v但是，员工经常忘记已收到期刊，或者未将其传递给名单中的但是，员工经常忘记已收到期刊，或者未将其传递给名单中的下一位员工。在一段时间后，无人知道期刊应该在谁手上。整个传下一位员工。在一段时间后，无人知道期刊应该在谁手上。整个传递过程难以记录，员工也往往互相指责健忘、粗心等。递过程难以记录，员工也往往互相指责健忘、粗心等。v 公司的公司的IT部门负责开发内部商业应用，该部门建议一个计算机部门
13、负责开发内部商业应用，该部门建议一个计算机管理系统以记录期刊的传阅情况。员工阅读完毕后通知系统，系统管理系统以记录期刊的传阅情况。员工阅读完毕后通知系统，系统回应下一位阅读者，下一位员工必须确认已收到期刊。系统也应能回应下一位阅读者，下一位员工必须确认已收到期刊。系统也应能在员工忘记传递期刊时发出提醒信息。在员工忘记传递期刊时发出提醒信息。v 管理图书室的人事部门认为这是一个很好的主意。尤其是他们管理图书室的人事部门认为这是一个很好的主意。尤其是他们系统能够根据假期（员工请假两周将无法阅读），以及根据员工是系统能够根据假期（员工请假两周将无法阅读），以及根据员工是否守时（能否在三天内将期刊传递给下一位员工），安排传阅名单否守时（能否在三天内将期刊传递给下一位员工），安排传阅名单的次序。的次序。v需求获取技术需求获取技术v需求获取哪些问题需求获取哪些问题v需求获取的步骤需求获取的步骤
