搜索
1REvs.SystemsAnalysis需求工程vs.系统分析2需求工程vs.系统分析REvs.SystemsAnalysis•需求工程由系统分析发展而来–系统分析关注企业内部的信息系统–主要采用非形式化的需求描述，工具和方法,•例如：DFD,E-R,OO,…–80年代中期形成，90年代以来成为研究热点。–多见于管理学院，工程学科，和计算机科学的本科生和研究生教学3需求工程vs.系统分析REvs.SystemsAnalysis•需求工程超出系统分析的范围–涵盖整个形式化问题•从“企业需求”到“精确描述”–不仅限于信息系统•实时系统•嵌入系统•交互系统•基于组件的系统•webservices–相对较少关注企业管理问题和企业业务流程4But,whatisarequirement?•每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述即是需求。——HerbertSimon,1969•需求,即是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的依据。——IEEE610.12,19905将问题与解决方案分开•理解问题需求获取•问题的形式化表示形式规约，形式建模•就问题性质达成共识验证,冲突及矛盾消解,磋商需求管理–维护双方的共识6设计活动改变客观世界状态7什么是需求？（Jackson,1995）领域性质(DomainProperty)：无论系统存在与否均存在的应用领域的性质。需求(Requirements)：由系统的存在而产生的应用领域性质。规约描述(Specification)：描述系统为满足需求而应具有的行为。需求证明的标准(VerificationCriteria)：1、运行在某台机器上的程序满足规约描述；2、针对给定的领域性质，规约描述满足需求。需求验证的标准（ValidationCriteria）：1、是否已发现所有重要需求？2、是否已发现所有有关的领域性质？8实例•RequirementR需求:–只有被授权者能够访问数据库。•DomainPropertiesD领域性质:–授权者持有密码。–密码不会分享给未授权者。•SpecificationS规约描述:–用户输入密码后，将被准许访问数据库。•S+DimplyR–当领域模型出错时，会有什么后果9需求：关于为什么？做什么？不包括怎么做？（why,what,how）•…需求描述必须给出为什么需要这样一个系统。——Ross,1977•通常，需求描述系统要做什么，而不是怎么做。但是，二者不太容易区分，上一个抽象层次的“怎么做”经常在下一个抽象层次上转化为“做什么”。•Jackson给出的稍为清楚的解释：–“为什么”和“做什么”是指系统的设计目的，是置身系统外部，对应用领域性质的描述。–“怎么做”是指系统的内部结构和行为。——Jackson,199510“描述”是需求工程的核心（Jackson,1995）•用非形式化的语言指出感兴趣的主题现象，并命名(designation)。例如：Parent(x,p)：p是x的父母。Female(x):x是女性。•术语的形式化定义(definition)和使用。例如：Mother(x,m)≡Parent(x,m)andFemale(m)Sister(x,y)≡Female(y)andmother(x,m)andmother(y,m)andfather(x,f)andfather(y,f)11“描述”是需求工程的核心（Jackson,1995,p58-59）•关于领域性质的无可驳的描述(refutabledescription)。无可驳性依赖于与主题现象的一致性。例如：对所有的m和x，Parent(x，m)蕴含not(parent(m,x))•开发过程中的带有假设性质的概略描述(roughsketch)。例如：“人与人之间总是通过某种方式相互联系”“每个人实际上只能有一个家”12存在问题的需求描述实例•含糊的需求描述：–“工资总额由上一条记录获得”–“所有客户都具有同一控制域“•错误的需求描述：–“所有系统将九月作为财政年度的起始时间”•不完整的需求描述：–“出错信息显示在屏幕的第24行“•矛盾或不一致的需求描述：–“C=A+B”；“C=A-B”•无法测试的需求：–“系统应具有友好的界面“13需求的层次软件需求包括三个不同的层次•业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。•用户需求(userrequirement)描述了用户使用产品必须要完成的任务，这在使用实例（usecase）文档或方案脚本（scenario）说明中予以说明。•功能需求(functionalrequirement)（包括非功能需求）：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。14软件需求各组成部分之间的关系对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，另外一些可能属于软件部件。管理人员或市场分析人员确定软件的业务需求，使公司运作更加高效（对信息系统而言）或具有很强的市场竞争力（对商业软件产品而言）。所有的用户需求必须与业务需求一致。用户需求使需求分析者能从中总结出功能需求以满足用户对产品的要求从而完成其任务，而开发人员则根据功能需求来设计软件以实现必须的功能。15非功能性需求：作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。16需求工程17本章内容•工程与软件工程•软件需求工程•需求工程师•需求工程vs.系统分析•软件生命周期中的需求活动•关于需求的基本观点18RequirementactivitiesintheSElifecycle软件生命周期中的需求活动19瀑布模型（Waterfall/Baseline）•核心思想：–系统开发是逐步求精的过程–各步骤相对独立，便于管理•存在的问题：–忽略了需求的动态性–需求完成后，用户对项目的参与即停止–需求描述与设计分开–不支持原型的使用和软件重用（Loucopoulos&Karakostas,1995）20原型法（Prototype）•适用范围：–用于获取关于系统用户界面的需求–用于检验设计方案的可行性，或探讨系统性能问题•存在的问题：–用户将原型误认为最终系统–原型所反映的系统是不全面的（Loucopoulos&Karakostas,1995,p30）21增量式开发与演化式开发Incrementalvs.Evolutionary(Thayer&Dorfman,1997,p10)22螺旋模型(SpiralModel)•螺旋模型主要用于风险分析•每一轮开发活动具体包括:–制定下一轮计划–决定设计目标和限制条件–评估候选方案,风险降解–产品开发•需求工程有关步骤为：–需求风险分析–规划设计•可以减少需求变更所带来的风险•存在的问题：–无法应付不可预见的需求变化23V型模型（V-Model）(Macaulay,1996）24关于敏捷模型（AgileModels）基本原则：•减少沟通障碍–程序员与客户直接交流•减低繁重的文档负担–文档代价昂贵但用途有限•对开发人员给予充分信任–无需运用花样翻新的过程模型给与提示•响应客户要求–而非严格遵循合同条文缺点：依赖程序员的记忆力源代码是难于维护的依赖口头交流易发生误解假定只有唯一的客户代表不可能反映多视角制作短期计划无长期及前瞻性规划25本章内容•工程与软件工程•软件需求工程•需求工程师•需求工程vs.系统分析•软件生命周期中的需求活动•关于需求的基本观点26Viewpoints关于需求的基本观点27关于需求的基本观点•需求工程活动不总是顺序进行–问题描述不总是先于解决方案描述•在系统开发的任何阶段描述问题均是有益的–需求工程是在各开发阶段持续进行的一系列活动•问题陈述无法追求完美–需求模型是对世界的近似表示•将包括不精确和不一致性•会省略某些信息•细致的分析将降低导致严重问题的风险•…但风险永不可能降解为零28关于需求的基本观点•追求规约的描述会降低性价比–需求分析是有开销的–不同的项目，性价比的平衡点是不同的•问题描述永不可能是固定的–变化是无法避免的，因此应纳入计划之中–对变化的处理应定期进行29可能的需求来源•客户专有需求–对于有着明确问题的特定客户，最终客户享有决定权。•市场需求–对于在市场上广泛出售的产品，营销团队扮演着顾客和用户代表的角色，产品必须拥有顾客。•社会需求–系统的目的是造福社会，而不需要客户（支付报酬）–一些开源/自由软件，科学研究软件•综合–为特定客户开发，但最终希望面向市场的软件。