需求工程过程RequirementsEngineeringProcess需求工程过程是发现,分析和确认系统需求的过程(Processesusedtodiscover,analyseandvalidatesystemrequirements)目标(Objectives)描述主要的需求工程活动以及它们的关系介绍需求提取(elicitation)和分析的技术描述需求确认(validation)和评审的意义讨论需求管理在支持其他需求工程过程所扮演的角色课题可行性研究需求提取和分析需求确认需求管理需求工程过程需求工程所采用的过程多种多样,它由应用领域、参与人员和开发需求的机构决定然而,在所有过程中也存在着一些相同的一般活动需求提取;需求分析;需求确认;需求管理。需求工程过程需求工程RequirementsspecificationRequirementsvalidationRequirementselicitationSystemrequirementsspecificationandmodelingSystemrequirementselicitationUserrequirementsspecificationUserrequirementselicitationBusinessrequirementsspecificationPrototypingFeasibilitystudyReviewsSystemrequirementsdocument可行性研究(Feasibilitystudies)一个可行性研究决定提出的系统是否值得去做。研究焦点在于检查该系统是否对机构目标有贡献;在既定预算和现有技术的情况下,是否能完成该系统的工程;该系统是否能与其它正在使用的系统进行集成。可行性研究的实现实现手段依赖于信息评估(需要什么),信息收集和报告编写对机构里的人来说,问题是如果系统实现不了怎么办?现有流程的问题是什么?提出的系统会有多大的帮助?集成将会遇到什么问题?需要新的技术吗?要具备什么技能?对提出的系统提供支持的必要工具有那些?提取(Elicitation)与分析有时称其为需求提取或需求发现需要技术人员与顾客一起找出应用领域,所提供的系统服务以及系统操作限制它可能涉及到最终用户,管理人员,维护工程师,领域专家,同业商会等等。这些被称为利益相关人(stakeholders)需求分析问题利益相关人不知道他们真正需要什么。利益相关人用自己的语言来表达需求。不同的利益相关人的需求可能会有冲突。机构和政治的因素可能会影响系统需求。在分析过程中需求变化了。有新的利益相关人加入进来,业务环境也发生改变。需求螺旋RequirementsclassificationandorganisationRequirementsprioritizationandnegotiationRequirementsdocumentationRequirementsdiscovery过程活动需求发现通过与利益相关人进行互动来发现需求,领域需求也要在这个阶段找出来。需求的组织和分类把相关的需求进行分组并把它们放到一个聚类中。协商和优先级排序将需求进行优先级排序并解决需求冲突。编写需求文档编写需求文档并进入下一个螺旋阶段需求发现是对现有系统和提出的系统进行信息收集以及从这些信息中提取出用户需求和系统需求的过程。信息来源包括文档、系统的利益相关者和类似系统的规格说明。银行自动取款机系统(ATM)这里所用的例子是一个自动出纳(auto-teller)系统,它能够提供某些自动银行服务。有些系统只为具有本系统的银行的顾客提供一些服务,而对其他顾客提供的服务却很少。服务包括提取现金(cashwithdrawal),传递信息(messagepassing,对一个服务请求发送一个消息),定出结算单(orderingastatement)和转账(transferringfunds)。ATM利益相关人银行顾客其他银行的代表银行管理人员柜台职员数据库管理员安全管理人员市场部门硬件和软件维护工程师银行校对员观点(Viewpoints)观点是用一种构造需求的方法来表达不同利益相关人的观念。这种多角度的分析方法是很重要的,因为没有唯一正确的分析系统需求的方法。观点的类型互动者观点人或其它系统是与系统直接互动的。在一个ATM上,客户数据库和账目数据库都代表互动者观点。间接观点那些不用系统的利益相关人也会影响到需求。在一个ATM上,管理员和保安人员就代表间接观点。领域观点领域特征和限制也会影响需求,在一个ATM上的例子就是银行间的通信标准。观点识别识别观点要采用:系统服务的提供者和接受者;与被识别的系统直接互动的系统;规则和标准;业务和非功能需求的源头;开发和维护系统的工程师;市场和其它业务观点。LIBSYS观点的层次结构ArticleprovidersFinanceLibrarymanagerLibrarystaffUsersInteractorIndirectAllVPsClassificationsystemUIstandardsDomainExternalStaffStudentsCataloguersSystemmanagers面谈(Interviewing)通过正式的或非正式的面谈,需求小组向利益相关人询问关于他们如何使用系统和怎样开发系统的问题。有两种面谈方式:限定式面谈——回答一组预先拟定好的问题。开放式面谈——没有预定的议程和议题和利益相关人交谈。面谈实践通常是限定式与开放式面谈相结合。面谈有利于收集到利益相关人的观点以及有关他们如何与系统互动的信息。面谈不利于对领域需求的理解需求工程师不理解特定领域的术语;人们认为一些领域知识太普通了,以至于不值得去考虑或讲出来。有效的面谈者面谈者应该以乐意和虚心的态度倾听利益相关人的意见,不要对需求抱有成见。他们应该用一个提问和建议来鼓励被访者,而不是期望被访者简单地回答像“你想做什么?”这样的问题。情节(Scenarios)情节是在现实生活中如何使用一个系统的例子。它们应该包括:对初始情况的一个描述;对常规事件流的一个描述;关于如何导致错误的一个描述;关于其它并发活动的信息;对情节的结束状态的一个描述。LIBSYS情节(1)Initialassumption:TheuserhasloggedontotheLIBSYSsystemandhaslocatedthejournalcontainingthecopyofthearticle.Normal:Theuserselectsthearticletobecopied.Heorsheisthenpromptedbythesystemtoeitherprovidesubscriberinformationforthejournalortoindicatehowtheywillpayforthearticle.Alternativepaymentmethodsarebycreditcardorbyquotinganorganisationalaccountnumber.TheuseristhenaskedtofillinacopyrightformthatmaintainsdetailsofthetransactionandtheythensubmitthistotheLIBSYSsystem.Thecopyrightformischeckedand,ifOK,thePDFversionofthearticleisdownloadedtotheLIBSYSworkingareaontheuserÕscomputerandtheuserisinformedthatitisavailable.Theuserisaskedtoselectaprinterandacopyofthearticleisprinted.IfthearticlehasbeenflaggedasÔprint-onlyÕitisdeletedfromtheuserÕssystemoncetheuserhasconfirmedthatprintingiscomplete.LIBSYS情节(2)Whatcangowrong:Theusermayfailtofillinthecopyrightformcorrectly.Inthiscase,theformshouldbere-presentedtotheuserforcorrection.IftheresubmittedformisstillincorrectthentheuserÕsrequestforthearticleisrejected.Thepaymentmayberejectedbythesystem.TheuserÕsrequestforthearticleisrejected.Thearticledownloadmayfail.Retryuntilsuccessfulortheuserterminatesthesession.Itmaynotbepossibletoprintthearticle.IfthearticleisnotflaggedasÔprint-onlyÕthenitisheldintheLIBSYSworkspace.Otherwise,thearticleisdeletedandtheuserÕsaccountcreditedwiththecostofthearticle.Otheractivities:Simultaneousdownloadsofotherarticles.Systemstateoncompletion:Userisloggedon.ThedownloadedarticlehasbeendeletedfromLIBSYSworkspaceifithasbeenflaggedasprint-only.用况(Usecases)用况是基于UML技术的一种情节,它识别出一个交互中的参与者并描述这个交互本身。可以用一组用况描述与系统发生的所有可能的互动情况可以用顺序图补充用况的细节,它展示了在系统中处理事件的顺序。文章打印的用况LIBSYS的用况文章打印的顺序图社会和机构因素软件系统是在一个社会和机构的环境中使用的。这个环境可以影响甚至主导系统需求社会和机构的因素不是一个单一的观点,它对所有的观点都会有影响好的分析员必须对这些因素很敏感,目前还没有系统的方法来解决他们分析中的问题。人种学(Ethnography)一些社会科学家花费了相当可观的时间来观察和分析人们实际是如何工作的。人们往往知道自己的工作而不知道他们的工作与机构中其他工作的联系。社会和机构因素的重要性是可以观察的。人种学的研究表明,工作通常远比简单的系统模型所包含的要丰富和复杂的多。聚焦人种学是在一个研究空中交通管制过程的项目中开发出来的方法。它把人种学和原型法结合起来。原型法开发引出了一些尚未回答的问题,这些问题正是人种学研究所关注的。人种学的问题是它研究的是现在的实践,它们所依赖的某些历史背景已是不再相关的。人种学和原型法人种学的范围需求来自于人们实际工作方式,而不是过程定义中所建议的工作方式。需求来自于合作以及对他人活动的认识。需求确认(validation)证明需求所描述的系统是客户所真正需要的。因为需求差错的成本很高,所以确认非常重要在交付之后修正一个需求差错(requirementserror)的成本比修正一个实现错误(implementationerror)的成本高达100倍。需求检查(checking)有效性(Validity)。系统所提供的功能是否很好地支持了客户的要求?一致性(Consistency)。需求有没有冲突?完整性(Co