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

用实例说明需求工程的设计原则和描述方法计算机学院关皓文201313273需求的定义用户解决一个问题或达到一个目标所需要的一种状况或能力(主观需求)系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力（客观需求）以上两种状态或能力的文档化表示（需求文档）内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理AlanDavis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”(强调做什么)HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理需求获取：资料收集需求分析与协商：理解分析整理系统建模：用模型描述(写下来)需求规约：完善需求文档并定稿需求验证：验证确认需求管理：整体规划及变更管理需求工程的六个阶段内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求获取方法与策略1、建立与用户、开发人员、分析人员之间顺畅的通信途径2、深入客户方进行访谈与调查3、观察用户操作流程4、组成各方联合小组5、使用基于用况(UseCase)的方法访谈与调查的原则所提问的问题应该循序渐进不要限制用户对问题的回答提问和回答在汇总后应能够反映用户需求的全貌——不断汇总-反馈-汇总需求调研实例—学生选课系统第一阶段：了解基本情况请教务处老师介绍背景，如学生总数、课程数量、选课相关的基本制度等第二阶段：制订访谈计划，深入讨论相关需求除了学生还有哪些相关用户?选课规则(学分、课程人数限制等)、退课规则了解客户对系统的期望：准确、访问速度快………需求调研实例—学生选课系统第三阶段：基本了解需求后就一些关键细节通过问卷进行明确在已经了解总体选课人数之后，需要进一步了解通常情况下的选课持续时间、是否按院系逐步开放选课、选课人数的一般分布等—与性能设计密切相关推荐关键管理人员使用USBKey设备，经济上是否可以接受……内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求分析原则必须能够表示和理解问题的信息域(数据)必须能够定义软件将完成的功能必须能够表示软件的行为(作为外部事件的结果)必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节分析过程应该在基本信息基础上不断细化需求描述和分析技术1.问题分解2.抽象3.建模4.多视点整个问题子问题1子问题3子问题21、问题分解什么是问题分解降低解决问题的复杂度;获取和分析问题本身所固有的整体-部分关系图书馆系统读者管理图书管理借阅管理2、问题抽象(1/2)什么是抽象?抓住问题的本质,获取一般和特殊关系问题抽象(2/2)读者抽象(提取成份)名字性别单位类别照片Email电话3、需求建模(1/2)什么是需求模型为什么需要建模需求建模(2/2)注意不要涉及软件设计和实现细节需求建模方法面向数据流的结构化分析方法(SA)面向数据结构的分析方法面向对象的分析方法(OOA)4、多视点分析什么是多视点分析从多个角度、不同层面上分析和描述用户需求为什么需要多视点分析人的认识具有片面性(瞎子摸象)多视点可以帮助我们全面把握用户的需求多视点分析：例如围绕着超市收银系统顾客希望？收银员希望？经理希望？系统管理员希望？最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡需求协商讨论需求冲突，折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素不一致的目标责任的丧失或转移组织文化组织管理态度和士气部门差异通常会议是解决冲突最快的方式参加者：发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段：叙述阶段讨论阶段决策阶段内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求规约的原则-1从现实中分离功能，即描述要“做什么”而不是“怎样实现”认识模型，而不是设计或实现的模型使用面向处理的规约语言(或称系统定义语言)需求规约的原则-2规约必须包括系统运行环境规约必须是可操作的需求规约的原则-3规约必须允许不完备性并允许扩充规约必须局部化和松散耦合需求规约Ⅰ.引言A.系统参考文献B.整体描述C.软件项目约束Ⅱ.信息描述A.信息内容表示B.信息流表示：ⅰ数据流ⅱ控制流Ⅲ.功能描述A.功能划分B.功能描述：ⅰ处理说明ⅱ限制∕局限ⅲ性能需求ⅳ设计约束ⅴ支撑图C.控制描述ⅰ控制规约ⅱ设计约束Ⅳ.行为描述A.系统状态B.事件和响应Ⅴ.检验标准A.性能范围B.测试种类C.期望的软件响应D.特殊的考虑Ⅵ.参考书目Ⅶ.附录引言：陈述软件目标，在基于计算机的系统语境内进行描述。信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。行为描述：描述作为外部事件和内部产生的控制特征的软件操作。检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。需求验证需求验证目的是要检验需求是否能够反映用户的意愿评审人员评审时往往需要检查以下内容：1.系统定义的目标是否与用户的要求一致；2.系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；3.被开发项目的数据流与数据结构是否确定且充足；4.主要功能是否已包括在规定的软件范围之内，是否都已充分说明；5.设计的约束条件或限制条件是否符合实际；6.开发的技术风险是什么；7.是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理需求管理需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动需求跟踪有两种方式，正向跟踪与逆向跟踪正向跟踪：《需求规约》后继工作产品逆向跟踪：工作产品《需求规约》需求变更的原因初期的认识不足导致错误或不完整的需求需求本身存在不一致业务变化导致的刚性需求变更外部经济、市场环境的变化客户和项目组对已确认的需求理解不一致技术制约或多目标权衡带来的需求变更关键实践唯一标识每项需求并进行的系统管理分级的需求管理需求变更管理过程支持需求生命周期及依赖性管理变更影响分析及需求变更决策唯一地标识每一项需求为每一项需求分配一个唯一的标识符自动编号：如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.系统定义的目标与用户的要求基本一致；2.系统需求分析阶段提供的文档资料齐全；文档中的描述完整、清晰、准确地反映了用户要求；3.被开发项目的数据流与数据结构确定且充足；