《软件需求分析建模.ppt》由会员分享，可在线阅读，更多相关《软件需求分析建模.ppt（42页珍藏版）》请在三一办公上搜索。
1、学习任务3 软件需求分析建模,主讲：陈荣保,需求分析,需求分析是指理解用户需求，就软件功能和性能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到用户需求说明书和需求规格说明书两份文档。广义上，需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程；狭义上，需求分析是指需求的获取、分析及定义的过程。需求分析的任务就是软件系统解决“做什么”的问题，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求的过程。,需求分析
2、,如果投入大量的人力、物力、财力和时间，而开发出的软件却没人要，那么所有的投入都是徒劳。如果费了很大的精力开发一个软件，最后却不能满足用户的要求，而要重新开发，那么这种返工是让人痛心疾首的。例如，用户需要一个响应时间快的软件，而在软件开发前期忽略了软件的性能要求，忘了向用户询问这个问题，想当然地认为是开发无响应时间这一性能要求的软件，如果当你千辛万苦地开发完成向用户提交时才发现出了问题，是要付出很大的代价的。所以，需求分析在软件开发过程中具有举足轻重的地位，具有决策性、方向性、策略性的作用，我们应对需求分析具有足够的重视。在一个大型软件系统的开发中，需求分析的作用要远远大于程序设计。,需求分析
3、建模,1.需求获取,3.需求分析,4.需求文档的编写,2.需求捕获技术,需求获取,开发软件项目关键的第一步工作是什么？软件的需求分析理解用户对软件提出的要求,需求获取,需求获取可能是软件开发中最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈，从他们那里得到需求；只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了。但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。,需求获取,首先，需求获取要定义问题范围，而系统的边界往往是很难明确的，用户不了解技术实现的细节，这样将造成系统目标的混
4、淆。其次，是对问题的理解。任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况；他们不知道系统作为一个整体怎么样工作效率更好，也不太清楚哪些工作可以交给软件完成；他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求；他们需要开发人员的协助和指导，但是用户与开发人员之间的交流很容易出现障碍，往往忽略了那些被认为是“很明显”的信息。最后，是需求的确认。需求的不稳定性往往随着时间的推移产生变动，使之难以确认。为了克服以上的问题，必须有组织地执行需求的获取活动。,需求获取,1）确定需求开发过程：确定需求开发过程确定如何组织需求的收集、分析、细化并核
5、实的步骤，并将它编写成文档。对重要的步骤要给予一定指导，这将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。2）编写项目视图和范围文档：项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须遵从能达到的业务需求。项目视图说明使所有项目参与者对项目的目标能达成共识。,需求获取,3）用户群分类：产品的用户在很多方面存在着差异，例如：用户使用产品的频度、他们的应用领域和计算机系统知识、他们所使用的产品特性、他们所进行的业务过程、他们在地理上的布局以及他们的访问优先级。根据这些差异，你可以把这些不同的用户分成小组。用户类不一定都指人，你可以把其它应用程序或系
6、统接口所用的硬件组件也看成是附加用户类的成员。以这种方式来看待应用程序接口，可以帮助你确定产品中那些与外部应用程序或组件有关的需求。将用户群分类并归纳各自特点为避免出现疏忽某一用户群需求的情况，要将可能使都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。,需求获取,4）选择产品代表：择每类用户的产品代表为每类用户至少选择一位能真正代表他们需求的人作为那一类用户的代表并能作出决策。这对于内部信息系统的开发是最易实现的，因为此时，用户就是身边的职员。而对于商业开发，就得在主要的客户或测试者中建立起良好的合作关系，并确定合适的产品代表。他们必须一直参与项目的开发而且有权作出决策。每一
7、个产品代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口。,需求获取,5）建立核心队伍：建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求。这样的核心队伍对于商业开发尤为有用，因为你拥有一个庞大且多样的客户基础。与产品代表的区别在于，核心队伍成员通常没有决定权。6）确定使用实例：让用户代表确定使用实例从用户代表处收集他们使用软件完成所需任务的描述-使用实例，讨论用户与系统间的交互方式和对话要求。在编写使用实例的文档时可采用标准模版，在使用实例基础上可得到功能需求。,需求获取,7）召开应用程序开发联系会议：召开
8、应用程序开发联系会议应用程序开发联系会议是范围广的、简便的专题讨论会，也是分析人员与客户代表之间一种很好的合作办法，并能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。8）分析用户工作流程：分析用户工作流程观察用户执行业务任务的过程。画一张简单的示意图（最好用数据流图）来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的使用实例和功能需求。你甚至可能发现客户并不真地需要一个全新的软件系统就能达到他们的业务目标。,需求获取需求人员,谁参加需求？,需求获取功能,功能性需求软件必须实现的软件功能 非功能性需求系
9、统的易用性、反应速度、容错性、健壮性等等质量属性,需求获取非功能,需求获取-功能实例,需求获取参与者,角色及其职责描述 角色获取职责描述,谁使用了系统的主要功能？谁来维护和管理系统使系统正常工作？哪些人对系统产生的结果感兴趣？,角色要求系统提供哪些功能？角色在系统中的工作是什么？角色的某些功能是否必须被系统自动实现？,需求获取-角色职责分析实例,需求获取业务数据、流程,业务流程描述业务处理过程 业务数据及关系 找出元数据：数据的数据 找出中间数据：描述统计数据的数据 找出元数据和中间数据的关系,需求获取-报表,学生成绩统计表,需求捕获技术,用户访谈收集资料问卷表小组会议,需求捕获技术用户访谈,
10、准备访谈计划访谈日程访谈开始和结束引导访谈,需求捕获技术用户访谈,准备访谈在进行访谈前，需求分析者应该很好的理解行业的组织结构，行业定位、项目范围和项目目标，访谈会涉及下面内容：组织结构报告年度报告长期发展计划部门目标的陈述已有程序手册已有系统的演示已有系统文档需求分析者应该理解一般的行业术语（术语表）并且还要熟悉行业上的业务问题,需求捕获技术用户访谈,计划访谈日程准备列表，列出主要话题或问题。这些问题可以找出未意识到的重点，还能有逻辑的引导访谈进行。安排访谈应遵循自上而下的进行。首先访谈部门或地区的领导，然后才是他们下属的雇员。在邀请对方进行会谈时，要解释这次会谈的目的，一般会涉及哪些领域，
11、以及大致需要的时间等。,需求捕获技术用户访谈,访谈开始和结束陈述访谈的目的，谈谈被访谈者关心的事。讨论他们所熟悉的日常工作的过程。怎样的变化将使你的工作更简单或更有效？暗示被访谈者提出改进意见。当列表中的所有领域都讨论过后，提出下面问题：“还有什么问题我们没有讨论吗？”或是“我们还需要讨论些别的内容吗？”结束会谈时，简短的总结讨论过的问题，重点指出会谈的要点，并说出你的理解。最后，你必须感谢被访谈者参加这次访谈。,需求捕获技术用户访谈,引导访谈避免提封闭性的问题 询问开放性的问题使用适当的表达 重述被访谈者的回答 有效的使用沉默,需求捕获技术收集资料,收集用户的书面需求文档收集用户现在的业务操
12、作流程及其改进意见文档收集用户现在使用的数据表和文件及其格式，并确定数据的来源,需求捕获技术问卷表,需访谈的个体太多需要回答容易确定的细节问题当你希望有个详细的结果时 使问卷表尽可能的简短。用多个短小的问卷表替代一个长的问卷表。如果在回答了前15-20个问题后，长的问卷表会使用户感觉厌烦，他们就不会对其余的问题做出正确的判断。通常，一个问卷表包含的问题不超过10-15。,需求捕获技术小组会议,小组会议一般在下列情况中使用：信息平均的分布一小部分人中。无法个别的会见所有的涉众。一系列的访谈已经结束，团队需要在同一平台下得到所有的回答者。,需求分析,用例分析 建立用例模型 编写用例描述 数据流程分
13、析 数据流程图实体-关系分析（1）数据对象、属性与关系（2）实体-关系图,获取角色 获取用例 创建用例图,需求分析-用例图实例,需求分析-用例描述实例,需求分析-用例描述实例,需求分析,数据流程图的基本图例符号数据流程图画法,工具Microsoft Office VisioPowerDesigner,需求分析-实例,0 层数据流图,需求分析-实例,1 层选课数据流图,需求分析-实例,1 层成绩数据流图,需求分析,实体-关系图,需求文档的编写,编写用户需求报告系统概述（目标、名词解释、产品应当遵循的标准或规范）功能需求非功能需求功能需求描述（业务流程分析、数据需求、用户权限、报表需求）编写需求规
14、格说明书概述（产品范围、产品中的角色）目标系统的功能需求 目标系统的非功能性需求 目标系统的界面与接口需求 目标系统的约束条件需求建模与分析报告 实例,小结,在需求获取和分析过程中，要对问题进行评估，对方案进行综合。在整个过程中，分析师关注的焦点是“做什么”，而不是“怎么做”，系统必须完成什么功能，会产生什么数据，将定义什么界面，会遇到什么约束等。总之，在这一阶段主要经历集中在获取和分析系统的逻辑功能上。不要把“用计算机如何实现”这样的物理因素牵扯进来，影响逻辑功能的分析。,练习,1、完善选课系统的功能性需求；获取学生工作管理系统的功能性需求。2、获取学生工作管理系统完善选课系统的非功能性需求。3、完善选课系统的角色；获取学生工作管理系统的角色。4、完善选课系统角色的职责描述；描述学生工作管理系统角色及其职责。6、写出需求捕获技术。7、完善选课系统业务流程；画出学生工作管理系统业务流程。8、完善选课系统用例建模；实现学生工作管理系统用例建模。9、完善选课系统的数据流图；实现学生工作管理系统分层次数据流图。10、完善选课系统主要数据的实体-关系图；编写学生工作管理系统的实体-关系图。11、完成完整的选课系统需求分析和文档编写。初步实现学生工作管理系统的需求分析文档编写。,谢谢,
