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