用实例说明需求工程的设计原则和描述方法(PPT 63页).ppt

1、用实例说明需求工程的设计原则和描述方法,计算机学院 关皓文 201313273,需求的定义,用户解决一个问题或达到一个目标所需要的一种状况或能力(主观需求) 系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力（客观需求） 以上两种状态或能力的文档化表示（需求文档）,内容摘要,需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理,Alan Davis 把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动” (强调做什么) Herb Krasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与

2、验证、需求演进管理,需求获取：资料收集 需求分析与协商：理解分析整理 系统建模：用模型描述(写下来) 需求规约：完善需求文档并定稿 需求验证：验证确认 需求管理：整体规划及变更管理,需求工程的六个阶段,需求获取,系统分析人员通过与用户的交流，了解业务现状以及对待开发系统的期望 确定系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型 需求获取收集的“原始材料”为进行需求分析提供了基础,需求分析与协商,对需求进行分类组织，分析需求之间的关系 检查需求的一致

3、性、重叠和遗漏的情况 根据用户的需要对需求进行排序。 在需求获取阶段，经常出现以下问题： 提出的要求超出软件系统可以实现的范围或实现能力 不同的用户提出了相互冲突的需求,系统建模,建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁 系统分析人员借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图 常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法,需求规约(Specification),通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求 软件需求规约是分

4、析任务的最终产物 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用,需求验证,需求开发阶段工作的复查手段 对功能的正确性、完整性和清晰性，以及其它需求给予评价 为保证软件需求定义的质量，评审应以专门指定的人员负责(应该是需求分析人员之外的其他人员)，并按规程严格进行,在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。,需求管理,一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制 需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程

5、(变更的记录、分析、变更过程管理、追踪等),回顾：需求的各种形式,从高度抽象的系统服务或系统目标到对某一系统功能的精确约束 原始需求 客户对软件系统及新的工作方式的期望目标 客户单位已经存在的日常工作方式和业务规则 系统所属领域固有的法规、标准或惯例等 一般目标：更快、更好、更安全 需求文档 自然语言描述 UML图等图形表示 业务规则表格,内容摘要,需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理,需求获取方法与策略,1、建立与用户、开发人员、分析人员之间顺畅的通信途径 2、深入客户方进行访谈与调查 3、观察用户操作流程 4、组成各方联合小组 5、使用基于用况(Use C

6、ase)的方法,访谈与调查的原则,所提问的问题应该循序渐进 不要限制用户对问题的回答 提问和回答在汇总后应能够反映用户需求的全貌不断汇总-反馈-汇总,需求调研实例学生选课系统,第一阶段：了解基本情况 请教务处老师介绍背景，如学生总数、课程数量、选课相关的基本制度等 第二阶段：制订访谈计划，深入讨论相关需求 除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户对系统的期望：准确、访问速度快 ,需求调研实例学生选课系统,第三阶段：基本了解需求后就一些关键细节通过问卷进行明确 在已经了解总体选课人数之后，需要进一步了解通常情况下的选课持续时间、是否按院系逐步开放选课、选课

7、人数的一般分布等与性能设计密切相关 推荐关键管理人员使用USB Key设备，经济上是否可以接受 ,内容摘要,需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理,需求分析原则,必须能够表示和理解问题的信息域(数据) 必须能够定义软件将完成的功能 必须能够表示软件的行为(作为外部事件的结果) 必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节 分析过程应该在基本信息基础上不断细化,信息域,信息域：包括信息内容、信息流、以及信息结构 信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成 例如，数据对象“工资”是一组重要数据体的组合：领款人的

8、姓名、净付款数、付款总额、扣除额等等,信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出 例如用数据流图表示的数据加工处理的全过程 信息结构表示了各种数据和控制项的内部组织(数据之间的关系) 数据或控制项将被组织为n维表还是树形结构？ 在结构的语境内，什么信息是和其他信息相关的？ 信息包含在单个结构中，还是使用不同的结构？ 在某信息结构中的信息如何和在另一个结构中的信息相关？,需求描述和分析技术,问题分解 抽象 建模 多视点,1、问题分解,什么是问题分解 降低解决问题的复杂度; 获取和分析问题本身所固有的整体-部分关系 图书馆系统

9、 读者管理 图书管理 借阅管理,2、问题抽象(1/2),什么是抽象? 抓住问题的本质,获取一般和特殊关系,问题抽象(2/2),读者抽象(提取成份) 名字 性别 单位 类别 照片 Email 电话,3、需求建模(1/2),什么是需求模型 为什么需要建模,需求建模(2/2),注意 不要涉及软件设计和实现细节 需求建模方法 面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA),4、多视点分析,什么是多视点分析 从多个角度、不同层面上分析和描述用户需求 为什么需要多视点分析 人的认识具有片面性(瞎子摸象) 多视点可以帮助我们全面把握用户的需求,多视点分析： 例如

10、围绕着超市收银系统 顾客希望？ 收银员希望？ 经理希望？ 系统管理员希望？ 最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡,需求协商,讨论需求冲突，折衷方案 协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异,通常会议是解决冲突最快的方式 参加者：发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题 通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段,内容摘要,需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理

11、,需求规约的原则-1,从现实中分离功能，即描述要“做什么”而不是“怎样实现” 认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言),需求规约的原则-2,规约必须包括系统运行环境 规约必须是可操作的,需求规约的原则-3,规约必须允许不完备性并允许扩充 规约必须局部化和松散耦合,需求规约,引言：陈述软件目标，在基于计算机的系统语境内进行描述。 信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。 功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其

12、他系统元素间的相互影响。 行为描述：描述作为外部事件和内部产生的控制特征的软件操作。 检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。 参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。 附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。,需求验证,需求验证目的是要检验需求是否能够反映用户的意愿 评审人员评审时往往需要检查以下内容： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰

13、、准确地反映了用户要求； 被开发项目的数据流与数据结构是否确定且充足； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 设计的约束条件或限制条件是否符合实际； 开发的技术风险是什么； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。,内容摘要,需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理,需求管理,需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动 需求跟踪有两种方式，正向跟踪与逆向跟踪 正向跟踪：需求规约 后继工作产品 逆向跟踪： 工作产品 需求规约,需求变更的原因,初期的认识不足导致错误或不完整的需求 需求本身存

14、在不一致 业务变化导致的刚性需求变更 外部经济、市场环境的变化 客户和项目组对已确认的需求理解不一致 技术制约或多目标权衡带来的需求变更,关键实践,唯一标识每项需求并进行的系统管理 分级的需求管理 需求变更管理过程支持 需求生命周期及依赖性管理 变更影响分析及需求变更决策,唯一地标识每一项需求,为每一项需求分配一个唯一的标识符 自动编号：如word中的章节编号 有意义的标识符：如pos-1,store-1,ETF-1. 在他处可以明确引用该项需求 使用一套基于数据库的系统管理需求 系统地记录每项需求及其追踪关系 方便查询和统计 需求版本管理的基础,分级的用户需求管理,五个需求等级 Urgent

15、:必须立刻优先实现 Necessary:必须实现，但不一定马上进行 Needed:需要的，不过没有也还凑合 Better:现在似乎也可以，但可以更好一点 Useful:总会有用的 正常情况下用户需求应该相对平均地分布在这五个等级上 分级管理策略：满足核心的用户需求同时说服用户将其它需求搁置或纳入下一版本,分级需求管理的好处,软件产品不是一个闭门造车、精益求精的艺术品(实验室产品) 尽早取得阶段性成果有助于鼓舞项目团队和客户的信心和士气 尽早让事实去验证：系统经历的实践越多需求的精确性越高 严谨的需求变更管理策略将促使客户更加理性地看待需求变更,需求工程实例,自考学籍管理系统,需求获取,某公司原

16、本拥有统一的学籍管理系统，但由于自考培训项目与其他培训项目存在很多区别，包含很多的特殊因素，原有系统不能满足自考培训部门的需要。由于部门不能使用原系统进行工作管理，大量学籍资料都存放在Excel表格里，给数据的查询、分类、更新带来很多不便，也给工作人员带来许多工作量，自考学籍管理系统在该背景下确立项目。,需求获取,第一阶段：了解基本情况 请培训老师介绍背景，如培训学生总数、课程数量、学分等基本制度等 第二阶段：制订访谈计划，深入讨论相关需求 都哪些相关用户? 选课规则(学分、培训人数限制等)、退课规则 了解客户对系统的期望：准确、访问速度快 ,需求获取,第三阶段：基本了解需求后就一些关键细节进

17、行明确 在已经了解总体培训人数之后，需要进一步了解通常情况下的学生信息、选课人数、缴费情况的一般分布等,需求分析、协商,系统角色描述 系统管理员、学生信息录入员、学生信息查询、人员交费情况录入员、考勤录入员,需求分析、协商,角色功能描述 系统管理员：有分配系统帐号，分配、修改用户权限，备份据等权限。 学生信息录入员: 有录入、修改学生基本信息、学生成绩、学生选课信息，统计课程通过率等权限。 学生信息查询员: 有查询学生信息,统计课程通过率的权限。 交费情况录入员：有录入、修改学生交费情况权限。(原学籍管理系统人员) 考勤录入员：有录入、修改学生考勤信息权限。(原学籍管理系统人员),系统建模-系

18、统数据流模型,系统建模-系统数据库模型,需求规约-功能描述,功能描述 系统用户信息管理：管理系统所有用户及其权限设置 1.用户帐号分配：为系统用户分配帐号。 2.用户权限管理: 为登陆系统的分配用户权限以及修改用户权限。 3.验证用户登陆：验证即将登陆系统用户的用户名和密码正确性。 学员信息管理：管理系统所有学员信息 1.学员信息查询：查询全部学员或以学号、时间段、自考类型（中文（一年报两次，春和秋），物流（按批次）查询学员。（此功能将调用原学籍管理系统数据库信息） 2.学员信息录入：录入学员的基本信息。 3.学员信息修改：修改学员的基本信息。（此功能将调用，修改原学籍管理系统数据库信息）,需

19、求规约,学员成绩管理： 管理系统所有学员成绩 .学员成绩录入：以班（班级号）或以单个学员为单位录入成绩。 .学员成绩查询：查询学员的考试成绩。 .课程通过率计算：计算课程的通过率。 .学员通过课程数计算: 计算学员通过课程数. .学员毕业论文开写提示：当学员课程通过5科以上（含5科）给予提示可以通知开始写毕业论文。 .学员毕业提示：当学员课程全部通过给予提示通知可以毕业。 课程管理：管理系统课程信息 1.学员选课录入：录入学员选课信息。 2.课程信息录入：录入课程信息。 3.学员选课查询：查询学员所选课程信息。 4.学员交费记录查询: 查询学员交费记录。（原学籍管理系统录入，本系统提供查询）

20、5.考勤记录查询：以班（班级号）或以单个学员为单位查询考勤记录。,需求规约-用例图,系统用例图,需求规约-流程图,管理员角度,需求规约-流程图,学员信息录入员,需求规约-流程图,学生信息查询员,性能需求与运行需求,数据精确度 系统输入数据必须按照规定的格式输入，否则系统显示错误或不给予响应 时间特性 用户的操作响应时间应在2秒以内。 适应性 系统能在windows系统环境下很好运行。,性能需求与运行需求,用户界面 用户界面应清晰,直观,友好.采用简单界面驱动方式. 硬件接口 本系统无需其他硬件接口 软件接口 本系统需要调用原学籍管理系统学员基本信息、学员交费记录的程序接口。运行于WINDOWS XP + .NET FRAMEWORK 2.0或更高环境下的操作系统上 故障处理 保证系统容错性和稳定性,运行时若出现不可修复的错误,也应保证数据安全。,需求验证,系统定义的目标与用户的要求基本一致； 系统需求分析阶段提供的文档资料齐全；文档中的描述完整、清晰、准确地反映了用户要求； 被开发项目的数据流与数据结构确定且充足； 主要功能已包括在规定的软件范围之内，都已充分说明； 设计的约束条件或限制条件符合实际；,