用实例说明需求工程的设计原则和描述方法课件.ppt

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

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

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

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

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

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

7、Key设备，经济上是否可以接受内容摘要v需求工程概述v需求获取v需求规约与验证v需求管理需求分析原则 v必须能够表示和理解问题的信息域(数据)v必须能够定义软件将完成的功能v必须能够表示软件的行为(作为外部事件的结果)v必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节v分析过程应该在基本信息基础上不断细化信息域 v信息域：包括信息内容、信息流、以及信息结构信息内容信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成v例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等 信息流信息流表示了数据和控制在系统中流动时的变

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

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

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

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

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

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

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

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

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

17、息、选课人数、缴费情况的一般分布等需求分析、协商系统角色描述 系统管理员、学生信息录入员、学生信息查询、人员交费情况录入员、考勤录入员 需求分析、协商角色功能描述 系统管理员：有分配系统帐号，分配、修改用户权限，备份据等权限。学生信息录入员:有录入、修改学生基本信息、学生成绩、学生选课信息，统计课程通过率等权限。学生信息查询员:有查询学生信息,统计课程通过率的权限。交费情况录入员：有录入、修改学生交费情况权限。(原学籍管理系统人员)考勤录入员：有录入、修改学生考勤信息权限。(原学籍管理系统人员)系统建模-系统数据流模型系统建模-系统数据库模型需求规约-功能描述功能描述系统用户信息管理：管理系统

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

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

20、员需求规约-流程图v学生信息查询员性能需求与运行需求数据精确度系统输入数据必须按照规定的格式输入，否则系统显示错误或不给予响应时间特性用户的操作响应时间应在2秒以内。适应性系统能在windows系统环境下很好运行。性能需求与运行需求用户界面用户界面应清晰,直观,友好.采用简单界面驱动方式.硬件接口本系统无需其他硬件接口软件接口本系统需要调用原学籍管理系统学员基本信息、学员交费记录的程序接口。运行于WINDOWS XP+.NET FRAMEWORK 2.0或更高环境下的操作系统上故障处理保证系统容错性和稳定性,运行时若出现不可修复的错误,也应保证数据安全。需求验证 1.系统定义的目标与用户的要求

21、基本一致；2.系统需求分析阶段提供的文档资料齐全；文档中的描述完整、清晰、准确地反映了用户要求；3.被开发项目的数据流与数据结构确定且充足；4.主要功能已包括在规定的软件范围之内，都已充分说明；5.设计的约束条件或限制条件符合实际；v1.一个要将中国归于中央集权下的专制一统，一个要恢复天下到六国时代诸侯联盟的松散政制。这看上去好像只是一个是否认同统一的历史趋势的问题，现代人常常站在统一的立场上去批判项羽，仿佛只有用铁骑扫平了六国的秦王才算是一个民族英雄，其实问题并不这么简单。v2.诵读识记能力。不少学生虽然能对课文进行朗读，但大多是“小和尚念经有口无心”，不能通过诵读去纠正预习偏差，正字音、明

22、字形，把握好句读、停顿、重音、节奏、语气等，疏通文义，理解大意，变成了“为读而读”；有的则是“为背而读”，要求背诵的段落就去诵读，反之则抛掷一边，这种支离破碎、割裂全篇、只言片语的背诵，将严重影响到对全篇文章的理解v3.可以设想，即使没有秦的武力，天下也终将归于一体，这也为汉以后的历史实际所一次次证明。无可否认的是，秦王的铁骑确实使这一过程大大简化了。看上去，历史似乎少走了许多弯路，细想来却又未必。v4.先不说铁骑下呻吟的民众，是否也有追求自己那一点卑微的生活自由的权力，就是从文明的发展来说，统一的后果也有许多地方值得怀疑。v5.中央集权确实加强了国家的权力，使秦汉帝国成为当时世界上少有匹敌的

23、强大力量。但是，作为代价，从原始社会时代开始积累起来的那一种有限民主（哪怕是统治阶级内部民主），也彻底丧失了。v6.春秋战国时期纵横捭阖的士，逐渐变成了可以“倡优畜之”的文人。当秦军焚烧着六国的宫殿，将天下一切珍奇全都劫掠汇聚向咸阳时，中华文明也就从多元变成了一元，从多中心变成了一个或最多两三个中心（所谓“两都”或“三都”）。v7.这篇文言文深刻揭露“宫市”对劳动人民的残酷剥削，同时反映了古代时宦者（太监）对贫苦农民百姓的收费的贪婪！选文中的卖柴翁却表现出强烈的反抗精神，在被逼走投无路的情况下，奋起反抗，怒殴宦者，是因为长期被压迫，内心积压的愤恨都发泄了出来。v8.文言文要掌握的知识点确实比较多，实词、虚词、通假字、古今义、词类活用、特殊句式，还有相关的文体文化常识等，都是要求学生识记的内容，但从学生课堂活动的表现来看，他们文言知识掌握之薄弱令人担忧。