软件工程课件-07需求工程过程

6、纪律是自由的第一条件。——黑格尔7、纪律是集体的面貌，集体的声音，集体的动作，集体的表情，集体的信念。——马卡连柯8、我们现在必须完全保持党的纪律，否则一切都会陷入污泥中。——马克思9、学校没有纪律便如磨坊没有水。——夸美纽斯10、一个人应该：活泼而守纪律，天真而不幼稚，勇敢而鲁莽，倔强而有原则，热情而不冲动，乐观而不盲目。——马克思软件工程课件07需求工程过程软件工程课件07需求工程过程6、纪律是自由的第一条件。——黑格尔7、纪律是集体的面貌，集体的声音，集体的动作，集体的表情，集体的信念。——马卡连柯8、我们现在必须完全保持党的纪律，否则一切都会陷入污泥中。——马克思9、学校没有纪律便如磨坊没有水。——夸美纽斯10、一个人应该：活泼而守纪律，天真而不幼稚，勇敢而鲁莽，倔强而有原则，热情而不冲动，乐观而不盲目。——马克思软件工程课件07需求工程过程需求工程过程RequirementsEngineeringProcess需求工程过程是发现，分析和确认系统需求的过程（Processesusedtodiscover,analyseandvalidatesystemrequirements）6、纪律是自由的第一条件。——黑格尔软件工程课件07需求工1软件工程课件-07需求工程过程2软件工程课件-07需求工程过程3软件工程课件-07需求工程过程4软件工程课件-07需求工程过程5需求工程过程需求工程所采用的过程多种多样，它由应用领域、参与人员和开发需求的机构决定然而，在所有过程中也存在着一些相同的一般活动需求提取；需求分析；需求确认；需求管理。需求工程过程需求工程所采用的过程多种多样，它由应用领域、参与6需求工程过程需求工程过程7需求工程需求工程8可行性研究

（Feasibilitystudies）一个可行性研究决定提出的系统是否值得去做。研究焦点在于检查该系统是否对机构目标有贡献；在既定预算和现有技术的情况下，是否能完成该系统的工程；该系统是否能与其它正在使用的系统进行集成。可行性研究

（Feasibilitystudies）一个可9可行性研究的实现实现手段依赖于信息评估（需要什么），信息收集和报告编写对机构里的人来说，问题是如果系统实现不了怎么办?现有流程的问题是什么?提出的系统会有多大的帮助?集成将会遇到什么问题?需要新的技术吗?要具备什么技能?对提出的系统提供支持的必要工具有那些?可行性研究的实现实现手段依赖于信息评估（需要什么），信息收集10提取（Elicitation）与分析有时称其为需求提取或需求发现需要技术人员与顾客一起找出应用领域，所提供的系统服务以及系统操作限制它可能涉及到最终用户，管理人员，维护工程师，领域专家，同业商会等等。这些被称为利益相关人（stakeholders）提取（Elicitation）与分析有时称其为需求提取或需11需求分析问题利益相关人不知道他们真正需要什么。利益相关人用自己的语言来表达需求。不同的利益相关人的需求可能会有冲突。机构和政治的因素可能会影响系统需求。在分析过程中需求变化了。有新的利益相关人加入进来，业务环境也发生改变。需求分析问题利益相关人不知道他们真正需要什么。12需求螺旋需求螺旋13过程活动需求发现通过与利益相关人进行互动来发现需求，领域需求也要在这个阶段找出来。需求的组织和分类把相关的需求进行分组并把它们放到一个聚类中。协商和优先级排序将需求进行优先级排序并解决需求冲突。编写需求文档编写需求文档并进入下一个螺旋阶段过程活动需求发现14需求发现是对现有系统和提出的系统进行信息收集以及从这些信息中提取出用户需求和系统需求的过程。信息来源包括文档、系统的利益相关者和类似系统的规格说明。需求发现是对现有系统和提出的系统进行信息收集以及从这些信息中15银行自动取款机系统（ATM）这里所用的例子是一个自动出纳（auto-teller）系统，它能够提供某些自动银行服务。有些系统只为具有本系统的银行的顾客提供一些服务，而对其他顾客提供的服务却很少。服务包括提取现金（cashwithdrawal），传递信息（messagepassing，对一个服务请求发送一个消息），定出结算单（orderingastatement）和转账（transferringfunds）。银行自动取款机系统（ATM）这里所用的例子是一个自动出纳（16ATM利益相关人银行顾客其他银行的代表银行管理人员柜台职员数据库管理员安全管理人员市场部门硬件和软件维护工程师银行校对员ATM利益相关人银行顾客17观点（Viewpoints）观点是用一种构造需求的方法来表达不同利益相关人的观念。这种多角度的分析方法是很重要的，因为没有唯一正确的分析系统需求的方法。观点（Viewpoints）观点是用一种构造需求的方法来表达18观点的类型互动者观点人或其它系统是与系统直接互动的。在一个ATM上，客户数据库和账目数据库都代表互动者观点。间接观点那些不用系统的利益相关人也会影响到需求。在一个ATM上，管理员和保安人员就代表间接观点。领域观点领域特征和限制也会影响需求，在一个ATM上的例子就是银行间的通信标准。观点的类型互动者观点19观点识别识别观点要采用：系统服务的提供者和接受者；与被识别的系统直接互动的系统；规则和标准；业务和非功能需求的源头；开发和维护系统的工程师；市场和其它业务观点。观点识别识别观点要采用：20LIBSYS观点的层次结构LIBSYS观点的层次结构21面谈（Interviewing）通过正式的或非正式的面谈，需求小组向利益相关人询问关于他们如何使用系统和怎样开发系统的问题。有两种面谈方式：限定式面谈——回答一组预先拟定好的问题。开放式面谈——没有预定的议程和议题和利益相关人交谈。面谈（Interviewing）通过正式的或非正式的面谈，需22面谈实践通常是限定式与开放式面谈相结合。面谈有利于收集到利益相关人的观点以及有关他们如何与系统互动的信息。面谈不利于对领域需求的理解需求工程师不理解特定领域的术语；人们认为一些领域知识太普通了，以至于不值得去考虑或讲出来。面谈实践通常是限定式与开放式面谈相结合。23有效的面谈者面谈者应该以乐意和虚心的态度倾听利益相关人的意见，不要对需求抱有成见。他们应该用一个提问和建议来鼓励被访者，而不是期望被访者简单地回答像“你想做什么？”这样的问题。有效的面谈者面谈者应该以乐意和虚心的态度倾听利益相关人的意见24情节（Scenarios）情节是在现实生活中如何使用一个系统的例子。它们应该包括：对初始情况的一个描述；对常规事件流的一个描述；关于如何导致错误的一个描述；关于其它并发活动的信息；对情节的结束状态的一个描述。情节（Scenarios）情节是在现实生活中如何使用一个系统25LIBSYS情节(1)LIBSYS情节(1)26LIBSYS情节(2)LIBSYS情节(2)27用况（Usecases）用况是基于UML技术的一种情节，它识别出一个交互中的参与者并描述这个交互本身。可以用一组用况描述与系统发生的所有可能的互动情况可以用顺序图补充用况的细节，它展示了在系统中处理事件的顺序。用况（Usecases）用况是基于UML技术的一种情节，它28文章打印的用况文章打印的用况29LIBSYS的用况LIBSYS的用况30文章打印的顺序图文章打印的顺序图31社会和机构因素软件系统是在一个社会和机构的环境中使用的。这个环境可以影响甚至主导系统需求社会和机构的因素不是一个单一的观点，它对所有的观点都会有影响好的分析员必须对这些因素很敏感，目前还没有系统的方法来解决他们分析中的问题。社会和机构因素软件系统是在一个社会和机构的环境中使用的。这个32人种学（Ethnography）一些社会科学家花费了相当可观的时间来观察和分析人们实际是如何工作的。人们往往知道自己的工作而不知道他们的工作与机构中其他工作的联系。社会和机构因素的重要性是可以观察的。人种学的研究表明，工作通常远比简单的系统模型所包含的要丰富和复杂的多。人种学（Ethnography）一些社会科学家花费了相当可观33聚焦人种学是在一个研究空中交通管制过程的项目中开发出来的方法。它把人种学和原型法结合起来。原型法开发引出了一些尚未回答的问题，这些问题正是人种学研究所关注的。人种学的问题是它研究的是现在的实践，它们所依赖的某些历史背景已是不再相关的。聚焦人种学是在一个研究空中交通管制过程的项目中开发出来的方法34人种学和原型法人种学和原型法35人种学的范围需求来自于人们实际工作方式，而不是过程定义中所建议的工作方式。需求来自于合作以及对他人活动的认识。人种学的范围需求来自于人们实际工作方式，而不是过程定义中所建36需求确认(validation)证明需求所描述的系统是客户所真正需要的。因为需求差错的成本很高，所以确认非常重要在交付之后修正一个需求差错（requirementserror）的成本比修正一个实现错误（implementationerror）的成本高达100倍。需求确认(validation)证明需求所描述的系统是客户所37需求检查（checking）有效性（Validity）。系统所提供的功能是否很好地支持了客户的要求?一致性（Consistency）。需求有没有冲突?完整性（Completeness）。是否包含了客户所需要的全部功能?现实性（Realism）。在所获得的预算和技术条件下，需求能不能实现？可检验性（Verifiability）。需求是否可以检验?需求检查（checking）有效性（Validity）。系统38需求确认技术需求审核（reviews）对需求进行系统地人工分析。原型法（prototyping）用一个可执行的系统模型去验证需求。测试案例生成法（Test-casegeneration）为需求开发测试以检验其可测程度。一致性跟踪（consistencytracking）对需求进行一致性跟踪和检查。需求确认技术需求审核（reviews）39需求复核（reviews）当需求定义形成后，应该定期复核。客户和承包人都应该参与复核。复核可以是正式的(有完整的文档)，也可以是非正式的。开发人员、顾客和用户之间的良好沟通有助于早期解决问题。需求复核（reviews）当需求定义形成后，应该定期复核。40复核检查（Reviewchecks）可检验性（Verifiability）。

需求是否确实可测?可理解性（Comprehensibility）。

需求是否完全被理解?可跟踪性（Traceability）。需求的来源是否清楚?可裁剪性（Adaptability)。需求变化是否不会对其他需求有很大的影响?复核检查（Reviewchecks）可检验性（Verifi41需求管理需求管理是在系统开发和需求工程过程中，对变化的需求进行管理的过程。需求难免是不完整的和不一致的随着业务需求的变化和对所开发的系统的更深了解，在过程中会出现新的需求；不同观点具有不同的需求，而且它们常常是相互矛盾的需求管理需求管理是在系统开发和需求工程过程中，对变化的需求进42需求变更在开发过程中，各个不同观点的需求的优先序改变了。系统客户从业务的角度出发指定的需求可能会与最终用户的需求相冲突。在开发中，系统的业务和技术环境改变了。需求变更在开发过程中，各个不同观点的需求的优先序改变了。43需求进化需求进化44不变的和易变的需求不变需求（Enduringrequirements）。它是稳定的，它来自顾客机构的核心活动需求。例如一个医院总是有医生，护士等等。它也可以来自领域模型易变需求（Volatilerequirements）。在系统开发或使用中变化的那部分需求。例如在医院，来自保健（health-care）政策的需求。不变的和易变的需求不变需求（Enduringrequire45需求分类（Classification）易变需求（Mutablerequirements）随系统环境而变的需求。渐现需求（Emergentrequirements）随着对系统的不断理解而出现的需求。后果需求（Consequentialrequirements）由于引入计算机系统而产生的需求。兼容需求（Compatibilityrequirements）受制于机构过程或者其它系统的需求。需求分类（Classification）易变需求（Mutab46需求管理计划编制在需求工程过程中，需要规划：需求识别（Requirementsidentification）

如何逐个地鉴定需求。对一个变更的管理过程（Achangemanagementprocess）在对一个需求变化进行分析的时候所要遵循的过程。跟踪策略（Traceabilitypolicies）所需要维护的需求关系的信息数量有多大。计算机辅助软件工程的工具支持（CASEtoolsupport）管理需求变更所需要的工具支持。需求管理计划编制在需求工程过程中，需要规划：47可跟踪性（Traceability）可跟踪性涉及到需求，需求来源和系统设计之间的关系。来源可跟踪性（Sourcetraceability）从需求到提出这些需求的利益相关人的联系。需求可跟踪性（Requirementstraceability）在相关的需求之间的联系。设计可跟踪性（Designtraceability）由需求到设计的联系。可跟踪性（Traceability）可跟踪性涉及到需求，需求48AtraceabilitymatrixU—rowAusescolumnB;R—rowAisrelatedwithcolumnB.AtraceabilitymatrixU—rowAu49CASE工具支持需求存储（Requirementsstorage）需求应该在一个安全和可管理的数据存储器中来管理。变更管理（Changemanagement）变更管理过程是一个工作流过程，它的每个阶段都是可以定义的，而且在这些阶段之间有一部分信息流是自动化的。跟踪管理（Traceabilitymanagement）自动查找（Automatedretrieval）需求之间的联系。CASE工具支持需求存储（Requirementsstor50需求变更管理应该应用到所有提出变化的需求上。主要阶段（Principalstages）问题分析（Problemanalysis）。对需求问题和变更提议进行讨论；变更分析和成本计算（Changeanalysisandcosting）。评估变更对其他需求的影响。变更实现（Changeimplementation）。修改需求文档和其它与变更有关的文档。需求变更管理应该应用到所有提出变