软件需求分析建模

上传人:xzh****18 文档编号:49814224 上传时间:2018-08-03 格式:PPT 页数:42 大小:735KB
返回 下载 相关 举报
软件需求分析建模_第1页
第1页 / 共42页
软件需求分析建模_第2页
第2页 / 共42页
软件需求分析建模_第3页
第3页 / 共42页
软件需求分析建模_第4页
第4页 / 共42页
软件需求分析建模_第5页
第5页 / 共42页
点击查看更多>>
资源描述

《软件需求分析建模》由会员分享,可在线阅读,更多相关《软件需求分析建模(42页珍藏版)》请在金锄头文库上搜索。

1、项目开发实践简勇 陈荣保 编著工业出版社学习任务3软件需求分析建模主讲:陈荣保需求分析n 需求分析是指理解用户需求,就软件功能和性能与客户达成 一致,估计软件风险和评估项目代价,最终形成开发计划的 一个复杂过程。在这个过程中,用户处在主导地位,需求分 析工程师和项目经理要负责整理用户需求,为之后的软件设 计打下基础。需求分析阶段结束后,要求得到用户需求说 明书和需求规格说明书两份文档。广义上,需求分析 包括需求的获取、分析、规格说明、变更、验证、管理的一 系列需求工程;n狭义上,需求分析是指需求的获取、分析及定义的过程。需 求分析的任务就是软件系统解决“做什么”的问题,就是要全 面地理解用户的

2、各项要求,并准确地表达所接受的用户需求 的过程。 需求分析n如果投入大量的人力、物力、财力和时间,而开发出的软件 却没人要,那么所有的投入都是徒劳。如果费了很大的精力 开发一个软件,最后却不能满足用户的要求,而要重新开发 ,那么这种返工是让人痛心疾首的。例如,用户需要一个响 应时间快的软件,而在软件开发前期忽略了软件的性能要求 ,忘了向用户询问这个问题,想当然地认为是开发无响应时 间这一性能要求的软件,如果当你千辛万苦地开发完成向用 户提交时才发现出了问题,是要付出很大的代价的。所以, 需求分析在软件开发过程中具有举足轻重的地位,具有决策 性、方向性、策略性的作用,我们应对需求分析具有足够的

3、重视。在一个大型软件系统的开发中,需求分析的作用要远 远大于程序设计。需求分析建模1.需求获取 3.需求分析 4. 需求文档的编写 2.需求捕获技术需求获取 n开发软件项目关键的第一步工作是什么?n软件的需求分析n理解用户对软件提出的要求需求获取 n需求获取可能是软件开发中最困难、最关键、 最易出错及最需要沟通交流的活动。对需求的 获取往往有错误的认识:用户知道需求是什么 ,我们所要做的就是和他们交谈,从他们那里 得到需求;只要问用户系统的目标特征,什么 是要完成的,什么样的系统能适合商业需要就 可以了。但是实际上需求获取并不是想象的这 样简单,这条沟通之路布满了荆棘。需求获取 n首先,需求获

4、取要定义问题范围,而系统的边界往往是很 难明确的,用户不了解技术实现的细节,这样将造成系统 目标的混淆。n其次,是对问题的理解。任何一个系统都会有很多的用户 或者不同类型的用户,每个用户只知道自己需要的系统, 而不知道系统的整体情况;他们不知道系统作为一个整体 怎么样工作效率更好,也不太清楚哪些工作可以交给软件 完成;他们不清楚需求是什么,或者说如何以一种精确的 方式来描述需求;他们需要开发人员的协助和指导,但是 用户与开发人员之间的交流很容易出现障碍,往往忽略了 那些被认为是“很明显”的信息。n最后,是需求的确认。需求的不稳定性往往随着时间的推 移产生变动,使之难以确认。 为了克服以上的问题

5、,必 须有组织地执行需求的获取活动。需求获取 n1)确定需求开发过程:确定需求开发过程确定如 何组织需求的收集、分析、细化并核实的步骤,并 将它编写成文档。对重要的步骤要给予一定指导, 这将有助于分析人员的工作,而且也使收集需求活 动的安排和进度计划更容易进行。n2)编写项目视图和范围文档:项目视图和范围文 档应该包括高层的产品业务目标,所有的使用实例 和功能需求都必须遵从能达到的业务需求。项目视 图说明使所有项目参与者对项目的目标能达成共识 。需求获取 n3)用户群分类:产品的用户在很多方面存在着差异,例如 :用户使用产品的频度、他们的应用领域和计算机系统知 识、他们所使用的产品特性、他们所

6、进行的业务过程、他 们在地理上的布局以及他们的访问优先级。根据这些差异 ,你可以把这些不同的用户分成小组。用户类不一定都指 人,你可以把其它应用程序或系统接口所用的硬件组件也 看成是附加用户类的成员。以这种方式来看待应用程序接 口,可以帮助你确定产品中那些与外部应用程序或组件有 关的需求。将用户群分类并归纳各自特点为避免出现疏忽 某一用户群需求的情况,要将可能使都有所差异。详细描 述出它们的个性特点及任务状况,将有助于产品设计。需求获取 n4)选择产品代表:择每类用户的产品代表为每类用户至少 选择一位能真正代表他们需求的人作为那一类用户的代表 并能作出决策。这对于内部信息系统的开发是最易实现的

7、 ,因为此时,用户就是身边的职员。而对于商业开发,就 得在主要的客户或测试者中建立起良好的合作关系,并确 定合适的产品代表。他们必须一直参与项目的开发而且有 权作出决策。每一个产品代表者代表了一个特定的用户类 ,并在那个用户类和开发者之间充当主要的接口。需求获取 n5)建立核心队伍:建立起典型用户的核心队伍把同类产品 或你的产品的先前版本用户代表召集起来,从他们那里收 集目前产品的功能需求和非功能需求。这样的核心队伍对 于商业开发尤为有用,因为你拥有一个庞大且多样的客户 基础。与产品代表的区别在于,核心队伍成员通常没有决 定权。n6)确定使用实例:让用户代表确定使用实例从用户代表处 收集他们使

8、用软件完成所需任务的描述-使用实例,讨论用 户与系统间的交互方式和对话要求。在编写使用实例的文 档时可采用标准模版,在使用实例基础上可得到功能需求 。需求获取 n7)召开应用程序开发联系会议:召开应用程序开发联系会 议应用程序开发联系会议是范围广的、简便的专题讨论会 ,也是分析人员与客户代表之间一种很好的合作办法,并 能由此拟出需求文档的底稿。该会议通过紧密而集中的讨 论得以将客户与开发人员间的合作伙伴关系付诸于实践。n8)分析用户工作流程:分析用户工作流程观察用户执行业 务任务的过程。画一张简单的示意图(最好用数据流图) 来描绘出用户什么时候获得什么数据,并怎样使用这些数 据。编制业务过程流

9、程文档将有助于明确产品的使用实例 和功能需求。你甚至可能发现客户并不真地需要一个全新 的软件系统就能达到他们的业务目标。需求获取需求人员角色职责职责需求分析员调查、分析用户的需求、定义产品需求、 撰写用户需求规格说明书客户与最终 用户提供必要的需求信息;确认最终需求项目组参与需求评审谁参加需求?需求获取功能n功能性需求n软件必须实现的软件功能 n非功能性需求n系统的易用性、反应速度、容错性、健壮性等等质量属性 需求获取非功能主要质质量属性详细详细 要求 正确性数据输入输出保持正确,界面显示无误。 可靠性本系统操作的数据是财务 数据,因此必须保证所有数据 的可靠性和正确性 易用性本系统用户界面简

10、单 ,用户在经过 培训以后,就能很快 上手使用。 安全性所有操作人员都要通过用户名和密码登陆系统,特别是 B/S端用户还 必须通过证书验证 ,才能进去系统, 保证了数据的安全性。 可扩展性本系统对 于用户的需求,在功能上可以进行扩展,能满 足各级财 政业务 上的需求。 可移植性本系统在数据库上可以进行移植,支持Oracle,Sybase等 数据库。需求获取-功能实例需求获取参与者n角色及其职责描述n角色获取n职责描述谁使用了系统的主要功能? 谁来维护和管理系统使系统正常工作? 哪些人对系统产生的结果感兴趣? v角色要求系统提供哪些功能? v角色在系统中的工作是什么? v角色的某些功能是否必须被

11、系统自动 实现? 需求获取-角色职责分析实例序号角色职责职责 描述1学生选课申请考试查询成绩单2教师录入成绩查询、统计成绩3教务人员开设新课程审核选课申请结束课程统计分析4系统管理者设置角色设置权限设置统计类 型需求获取业务数据、流程n业务流程描述n业务处理过程 n业务数据及关系 n找出元数据:数据的数据 n找出中间数据:描述统计数据的数据 n找出元数据和中间数据的关系 需求获取-报表学号学生平均分名次2009010500120090105002200901050032009010500420090105005学生成绩统计表需求捕获技术 n用户访谈n收集资料n问卷表n小组会议 需求捕获技术用户

12、访谈n准备访谈n计划访谈日程n访谈开始和结束n引导访谈需求捕获技术用户访谈n准备访谈在进行访谈前,需求分析者应该很好的理解 行业的组织结构,行业定位、项目范围和项目目 标,访谈会涉及下面内容:n组织结构报告n年度报告n长期发展计划n部门目标的陈述n已有程序手册n已有系统的演示n已有系统文档n需求分析者应该理解一般的行业术语(术语表) 并且还要熟悉行业上的业务问题需求捕获技术用户访谈n计划访谈日程准备列表,列出主要话题或问题 。这些问题可以找出未意识到的重点 ,还能有逻辑的引导访谈进行。安排 访谈应遵循自上而下的进行。首先访 谈部门或地区的领导,然后才是他们 下属的雇员。在邀请对方进行会谈时 ,

13、要解释这次会谈的目的,一般会涉 及哪些领域,以及大致需要的时间等 。需求捕获技术用户访谈n访谈开始和结束n陈述访谈的目的,谈谈被访谈者关心的事。n讨论他们所熟悉的日常工作的过程。n怎样的变化将使你的工作更简单或更有效?暗 示被访谈者提出改进意见。n当列表中的所有领域都讨论过后,提出下面问 题: “还有什么问题我们没有讨论吗?”或是 “ 我们还需要讨论些别的内容吗?”n结束会谈时,简短的总结讨论过的问题,重点 指出会谈的要点,并说出你的理解。n最后,你必须感谢被访谈者参加这次访谈。需求捕获技术用户访谈n引导访谈n避免提封闭性的问题 n询问开放性的问题n使用适当的表达 n重述被访谈者的回答 n有效

14、的使用沉默 需求捕获技术收集资料n收集用户的书面需求文档n收集用户现在的业务操作流程及其改 进意见文档n收集用户现在使用的数据表和文件及 其格式,并确定数据的来源需求捕获技术问卷表n需访谈的个体太多n需要回答容易确定的细节问题n当你希望有个详细的结果时 n使问卷表尽可能的简短。用多个短小的问 卷表替代一个长的问卷表。如果在回答了 前15-20个问题后,长的问卷表会使用户感 觉厌烦,他们就不会对其余的问题做出正 确的判断。通常,一个问卷表包含的问题 不超过10-15。 需求捕获技术小组会议 小组会议一般在下列情况中使用:n信息平均的分布一小部分人中。n无法个别的会见所有的涉众。n一系列的访谈已经

15、结束,团队需要在 同一平台下得到所有的回答者。 需求分析 n用例分析 n建立用例模型 n编写用例描述 n数据流程分析 n数据流程图n实体-关系分析 (1)数据对象、属性与关系 (2)实体-关系图 v获取角色 v获取用例 v创建用例图 需求分析-用例图实例需求分析-用例描述实例需求分析-用例描述实例需求分析 n数据流程图的基本图例符号n数据流程图画法 n工具 Microsoft Office Visio PowerDesigner 需求分析-实例n0 层数据流图需求分析-实例n1 层选课数据流图需求分析-实例n1 层成绩数据流图需求分析 n实体-关系图需求文档的编写 n编写用户需求报告n系统概述

16、(目标 、名词解释 、产品应当遵循的标准或规范 )n功能需求n非功能需求n功能需求描述(业务流程分析、数据需求 、用户权限 、报表需求 ) n编写需求规格说明书n概述(产品范围 、产品中的角色 )n目标系统的功能需求 n目标系统的非功能性需求 n目标系统的界面与接口需求 n目标系统的约束条件n需求建模与分析报告 实例小结 n 在需求获取和分析过程中,要对问题进行 评估,对方案进行综合。在整个过程中,分 析师关注的焦点是“做什么”,而不是“怎 么做”,系统必须完成什么功能,会产生什 么数据,将定义什么界面,会遇到什么约束 等。n 总之,在这一阶段主要经历集中在获取和 分析系统的逻辑功能上。不要把“用计算机 如何实现”这样的物理因素牵扯进来,影响 逻辑功能的分析。 练习n1、完善选课系统的功能性需求;获取学生工作管理系统的功能性需求。n2、获取学生工作管理系统完善选课系统的非功能性需求。n3、完善选课系统的角色;获取学生工作管理系统的角色。n4、完善选课系统角色的职责

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 其它办公文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号