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

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

需求获取：资料收集需求工程的六个阶段需求获取系统分析人员通过与用户的交流，了解业务现状以及对待开发系统的期望确定系统或产品范围的限制性描述与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型需求获取收集的“原始材料”为进行需求分析提供了基础需求获取系统分析人员通过与用户的交流，了解业务现状以及对待需求分析与协商对需求进行分类组织，分析需求之间的关系检查需求的一致性、重叠和遗漏的情况根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题：提出的要求超出软件系统可以实现的范围或实现能力不同的用户提出了相互冲突的需求需求分析与协商对需求进行分类组织，分析需求之间的关系系统建模

建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁系统分析人员借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法系统建模建模工具的使用在用户和系统分析人员之间建立了统一的需求规约(Specification)通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求软件需求规约是分析任务的最终产物需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用需求规约(Specification)通过建立完整的信息描需求验证需求开发阶段工作的复查手段对功能的正确性、完整性和清晰性，以及其它需求给予评价为保证软件需求定义的质量，评审应以专门指定的人员负责(应该是需求分析人员之外的其他人员)，并按规程严格进行需求验证需求开发阶段工作的复查手段在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求需求管理

一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程(变更的记录、分析、变更过程管理、追踪等)需求管理一种获取、组织并记录系统需求的系统化方案：对所有需回顾：需求的各种形式从高度抽象的系统服务或系统目标到对某一系统功能的精确约束原始需求客户对软件系统及新的工作方式的期望目标客户单位已经存在的日常工作方式和业务规则系统所属领域固有的法规、标准或惯例等一般目标：更快、更好、更安全需求文档自然语言描述UML图等图形表示业务规则表格回顾：需求的各种形式从高度抽象的系统服务或系统目标到对某一系内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理内容摘要需求工程概述需求获取方法与策略1、建立与用户、开发人员、分析人员之间顺畅的通信途径2、深入客户方进行访谈与调查3、观察用户操作流程4、组成各方联合小组5、使用基于用况(UseCase)的方法需求获取方法与策略1、建立与用户、开发人员、分析人员之间顺访谈与调查的原则所提问的问题应该循序渐进不要限制用户对问题的回答提问和回答在汇总后应能够反映用户需求的全貌——不断汇总-反馈-汇总访谈与调查的原则所提问的问题应该循序渐进需求调研实例—学生选课系统第一阶段：了解基本情况请教务处老师介绍背景，如学生总数、课程数量、选课相关的基本制度等第二阶段：制订访谈计划，深入讨论相关需求除了学生还有哪些相关用户?选课规则(学分、课程人数限制等)、退课规则了解客户对系统的期望：准确、访问速度快………需求调研实例—学生选课系统第一阶段：了解基本情况需求调研实例—学生选课系统第三阶段：基本了解需求后就一些关键细节通过问卷进行明确在已经了解总体选课人数之后，需要进一步了解通常情况下的选课持续时间、是否按院系逐步开放选课、选课人数的一般分布等—与性能设计密切相关推荐关键管理人员使用USBKey设备，经济上是否可以接受……需求调研实例—学生选课系统第三阶段：基本了解需求后就一些关键内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理内容摘要需求工程概述需求分析原则

必须能够表示和理解问题的信息域(数据)必须能够定义软件将完成的功能必须能够表示软件的行为(作为外部事件的结果)必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节分析过程应该在基本信息基础上不断细化需求分析原则必须能够表示和理解问题的信息域(数据)信息域信息域：包括信息内容、信息流、以及信息结构信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等信息域信息域：包括信息内容、信息流、以及信息结构信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出例如用数据流图表示的数据加工处理的全过程信息结构表示了各种数据和控制项的内部组织(数据之间的关系)数据或控制项将被组织为n维表还是树形结构？在结构的语境内，什么信息是和其他信息相关的？信息包含在单个结构中，还是使用不同的结构？在某信息结构中的信息如何和在另一个结构中的信息相关？信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变需求描述和分析技术问题分解抽象建模多视点需求描述和分析技术问题分解整个问题子问题1子问题3子问题21、问题分解什么是问题分解降低解决问题的复杂度;获取和分析问题本身所固有的整体-部分关系图书馆系统读者管理图书管理借阅管理整个问题子问题1子问题3子问题21、问题分解什么是问题分解2、问题抽象(1/2)什么是抽象?抓住问题的本质,获取一般和特殊关系2、问题抽象(1/2)什么是抽象?问题抽象(2/2)读者抽象(提取成份)名字性别单位类别照片Email电话问题抽象(2/2)读者抽象(提取成份)3、需求建模(1/2)什么是需求模型为什么需要建模3、需求建模(1/2)什么是需求模型需求建模(2/2)注意不要涉及软件设计和实现细节需求建模方法面向数据流的结构化分析方法(SA)面向数据结构的分析方法面向对象的分析方法(OOA)需求建模(2/2)注意4、多视点分析什么是多视点分析从多个角度、不同层面上分析和描述用户需求为什么需要多视点分析人的认识具有片面性(瞎子摸象)

多视点可以帮助我们全面把握用户的需求4、多视点分析什么是多视点分析多视点分析：例如围绕着超市收银系统顾客希望？收银员希望？经理希望？系统管理员希望？最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡多视点分析：需求协商讨论需求冲突，折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素不一致的目标责任的丧失或转移组织文化组织管理态度和士气部门差异需求协商讨论需求冲突，折衷方案通常会议是解决冲突最快的方式参加者：发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段：叙述阶段讨论阶段决策阶段通常会议是解决冲突最快的方式内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理内容摘要需求工程概述需求规约的原则-1从现实中分离功能，即描述要“做什么”而不是“怎样实现”认识模型，而不是设计或实现的模型使用面向处理的规约语言(或称系统定义语言)需求规约的原则-1从现实中分离功能，即描述要“做什么”而不是需求规约的原则-2规约必须包括系统运行环境规约必须是可操作的需求规约的原则-2规约必须包括系统运行环境需求规约的原则-3规约必须允许不完备性并允许扩充规约必须局部化和松散耦合需求规约的原则-3规约必须允许不完备性并允许扩充需求规约

需求规约引言：陈述软件目标，在基于计算机的系统语境内进行描述。信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。行为描述：描述作为外部事件和内部产生的控制特征的软件操作。检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。引言：陈述软件目标，在基于计算机的系统语境内进行描述。需求验证需求验证目的是要检验需求是否能够反映用户的意愿评审人员评审时往往需要检查以下内容：系统定义的目标是否与用户的要求一致；系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；被开发项目的数据流与数据结构是否确定且充足；主要功能是否已包括在规定的软件范围之内，是否都已充分说明；设计的约束条件或限制条件是否符合实际；开发的技术风险是什么；是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。需求验证需求验证目的是要检验需求是否能够反映用户的意愿内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理内容摘要需求工程概述需求管理需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动需求跟踪有两种方式，正向跟踪与逆向跟踪正向跟踪：《需求规约》后继工作产品逆向跟踪：工作产品《需求规约》需求管理需求管理是一组用于帮助项目组在项目进展中的任何时候去需求变更的原因初期的认识不足导致错误或不完整的需求需求本身存在不一致业务变化导致的刚性需求变更外部经济、市场环境的变化客户和项目组对已确认的需求理解不一致技术制约或多目标权衡带来的需求变更需求变更的原因初期的认识不足导致错误或不完整的需求关键实践唯一标识每项需求并进行的系统管理分级的需求管理需求变更管理过程支持需求生命周期及依赖性管理变更影响分析及需求变更决策关键实践唯一标识每项需求并进行的系统管理唯一地标识每一项需求为每一项需求分配一个唯一的标识符自动编号：如word中的章节编号有意义的标识符：如pos-1,store-1,ETF-1….在他处可以明确引用该项需求使用一套基于数据库的系统管理需求系统地记录每项需求及其追踪关系方便查询和统计需求版本管理的基础唯一地标识每一项需求为每一项需求分配一个唯一的标识符分级的用户需求管理五个需求等级Urgent:必须立刻优先实现Necessary:必须实现，但不一定马上进行Needed:需要的，不过没有也还凑合Better:现在似乎也可以，但可以更好一点Useful:总会有用的正常情况下用户需求应该相对平均地分布在这五个等级上分级管理策略：满足核心的用户需求同时说服用户将其它需求搁置或纳入下一版本分级的用户需求管理五个需求等级分级需求管理的好处软件产品不是一个闭门造车、精益求精的艺术品(实验室产品)尽早取得阶段性成果有助于鼓舞项目团队和客户的信心和士气尽早让事实去验证：系统经历的实践越多需求的精确性越高严谨的需求变更管理策略将促使客户更加理性地看待需求变更分级需求管理的好处软件产品不是一个闭门造车、精益求精的艺术品需求工程实例自考学籍管理系统需求工程实例自考学籍管理系统需求获取

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

系统管理员、学生信息录入员、学生信息查询、人员交费情况录入员、考勤录入员

需求分析、协商系统角色描述需求分析、协商角色功能描述

系统管理员：有分配系统帐号，分配、修改用户权限，备份据等权限。

学生信息录入员:有录入、修改学生基本信息、学生成绩、学生选课信息，统计课程通过率等权限。

学生信息查询员:有查询学生信息,统计课程通过率的权限。

交费情况录入员：有录入、修改学生交费情况权限。(原学籍管理系统人员)考勤录入员：有录入、修改学生考勤信息权限。(原学籍管理系统人员)需求分析、协商角色功能描述系统建模-系统数据流模型系统建模-系统数据流模型系统建模-系统数据库模型系统建模-系统数据库模型需求规约-功能描述功能描述系统用户信息管理：管理系统所有用户及其权限设置1.用户帐号分配：为系统用户分配帐号。2.用户权限管理:为登陆系统的分配用户权限以及修改用户权限。3.验证用户登陆：验证即将登陆系统用户的用户名和密码正确性。

学员信息管理：管理系统所有学员信息1.学员信息查询：查询全部学员或以学号、时间段、自考类型（中文（一年报两次，春和秋），物流（按批次））查询学员。（此功能将调用原学籍管理系统数据库信息）2.学员信息录入：录入学员的基本信息。3.学员信息修改：修改学员的基本信息。（此功能将调用，修改原学籍管理系统数据库信息）需求规约-功能描述功能描述需求规约学员成绩管理：管理系统所有学员成绩１.学员成绩录入：以班（班级号）或以单个学员为单位录入成绩。２.学员成绩查询：查询学员的考试成绩。３.课程通过率计算：计算课程的通过率。４.学员通过课程数计算:计算学员通过课程数.５.学员毕业论文开写提示：当学员课程通过5科以上（含5科）给予提示可以通知开始写毕业论文。６.学员毕业提示：当学员课程全部通过给予提示通知可以毕业。课程管理：管理系统课程信息1.学员选课录入：录入学员选课信息。2.课程信息录入：录入课程信息。3.学员选课查询：查询学员所选课程信息。4.学员交费记录查询:查询学员交费记录。（原学籍管理系统录入，本系统提供查询）5.考勤记录查询：以班（班级号）或以单个学员为单位查询考勤记录。需求规约学员成绩管理：管理系统所有学员成绩需求规约-用例图系统用例图需求规约-用例图系统用例图需求规约-流程图管理员角度需求规约-流程图管理员角度需求规约-流程图学员信息录入员需求规约-流程图学员信息录入员需求规约-流程图学生信息查询员需求规约-流程图学生信息查询员性能需求与运行需求数据精确度系统输入数据必须按照规定的格式输入，否则系统显示错误或不给予响应时间特性用户的操作响应时间应在2秒以内。适应性系统能在windows系统环境下很好运行。性能需求与运行需求数据精确度性能需求与运行需求用户界面用户界面应清晰,直观,友好.采用简单界面驱动方式.硬件接口本系统无需其他硬件接口软件接口本系统需要调用原学籍管理系统学员基本信息、学员交费记录的程序接口。运行于WINDOWSXP+.NETFRAMEWORK2.0或更高环境下的操作系统上故障处理保证系统容错性和稳定性,运行时若出现不可修复的错误,也应保证数据安全。性能需求与运行需求用户界面需求验证系统定义的目标与用户的要求基本一致；系统需求分析阶段提供的文档资料齐全；文档中的描述完整、清晰、准确地反映了用户要求；被开发项目的数据流与数据结构确定且充足；主要功能已包括在规定的软件范围之内，都已充分说明；设计的约束条件或限制条件符合实际；需求验证1.一个要将中国归于中央集权下的专制一统，一个要恢复天下到