【建模教程】-需求建模教程

----宋停云与您分享--------宋停云与您分享----软件需求（p73）要点：要选择一个标准进行剪裁。要定制专门的需求描述标准，与需求文档相关的IEEE标准是个合适的起点。----------------摘自《SoftwareEngineeringEightEdition》机械工业出版社 程成陈霞译需求工程过程（p87）内容：可行性研究需求导出和分析需求有效性验证需求管理需求工程的目标是创建和维护系统需求文档。事实上，所有的系统需求都是可变的。负责开发的软件工程人员不断地加深对软件的理解，购买系统的机构本身也在变，系统的硬件、软件和组织环境都在变。管理这些变更的过程就称为“需求管理”。可行性研究可行性研究的输入信息是一系列初步需求、系统的一个框架描述和希望系统如何支持业务过程的说明性信息，可行性研究的结果是给出一份报告，对需求工程和系统开发过程是否值得进行给出具体的意见和建议。进行一项可行性研究包括信息评估、信息汇总和报告生成。信息评估阶段就是要找出与上面提出的三个问题相关的信息。一旦这些信息收集好，下一步的工作就是要在信息源中找到这些问题的答案。需求导出和分析在初始的可行性研究之后，下一个需求工程过程就是需求导出和分析。在这个活动中，软件开发技术人员要和客户及系统最终用户一起调查应用领域，即系统应该提供什么服务、系统应该具有什么样的性能以及硬件约束条件等。需求分类和组织主要是识别来自不同信息持有者的彼此重叠的需求并对他们进行合理归类。归类需求最常用的方法是使用一个系统结构模型来识别子系统，并将需求与各子系统相关联。它强调需求工程与体系与设计不能总是分离。将需求写在卡片上这个方法在“极限编程中”是十分有效的。需求发现需求发现是这样一个过程：收集准备建立的系统和正在使用的系统信息，并从这些信息当中提取用户和系统需求。需求发现阶段的信息源包括已有文件、系统信息持有者以及类似系统的相关内容。在需求发现过程中，我们可以通过与信息持有者交谈和对他们的观察来获得信息，期间可以使用场景的方法和原型来帮助需求的发现。常用的需求发现技术包括：访谈技术、场景技术和深入实际技术。访谈：通过访谈来全面了解系统信息是一种很好的方法。但是，对于应用领域需求，通过访谈的方式是很难获得的。很难从访谈中到处领域知识，有以下两个原因：所有的应用专家都使用专业术语和行话。有些领域知识对于这些人来说太普通了，以至于他们要么是难以找到合适的次词语来解释，要么会不自觉的认为这些概念太基本，不值得去提。----宋停云与您分享--------宋停云与您分享----访谈对于导出机构需求和约束来说不是一项很有效的技术，因为，在机构中这些信息持有者之间存在着一些很微妙的关系。公布出来的机构结构很少能真正反映机构中真实的决策模式，被访问者不愿以对陌生人揭露机构中真实的一面。通常，人们总是不情愿去涉及影响需求的这些政治和机构因素。有能力的采访者通常有两个特征：他梦思想开放，对需求没有先入之见，而且很愿意听取信息持有者的意见。如果信息持有者提出意外的需求，他们愿意主动改变自己的意见对系统原有的看法。通过访谈所获得的信息补充了通过文档、用户观察以及其他手段所获得的信息。有时，除了文档以外访谈可能是系统需求的唯一来源。然而，访谈本身很容易漏掉一些基本的信息，所以，我们应该结合其他需求导出技术来使用它。场景：在把细节加入到纲要的需求描述中，场景可能特别有用。场景是对交互实例片段的描述。每个场景可能有一个或多个可能的交互。场景开始于一个交互的框架，在到处过程中，细节被逐渐增加，直到产生交互的一个完整的描述。在绝大多数情况下，一个场景可能包括以下内容：在场景的开始部分有一个系统状态描述。一个关于标准事件流的描述。一个关于哪儿会出错以及如何处理的描述。有关其他可能在同一时间进行的活动的描述。在场景完成后系统状态的描述。基于场景的需求导出可以再狠随意的情况下进行，需求工程师与信息持有者共同识别出场景并捕获这些场景的细节。还有一种一种较结构化的方法，如时间场景法或用例法也可以。用例：用例是一种基于场景的需求导出技术。有时会产生认识上的混乱，是否一个用例本身就是一个场景，如Fowler所建议的，一个用例封装了一组场景，每个场景就是一个线程。在这种情况下，一个标准的交互就会有一个场景，另外，每个可能的异常会有一个场景。用例识别与系统的单个交互。它们可以用文本记录下来或者是链接到给出更详细场景的UML模型。如序列图可以添加信息到用例。UML是面向对象的一个事实上的标准，因此，在需求导出中，用例和基于用例的需求导出使用的越来越多。UML主要用于系统建模。场景和用例是现象交互者视点的需求导出的有效技术，这里每一种交互类型可以标示为用例。它们也可以与某些间接视点结合使用，这种间接视点接受某些来自系统的结果（比如管理报告。然而，因为它们集中在交互上，它们对于约束、来自间接视点的高层业务和非业务功能需求、抑或是领域需求发现都是不凑效的。----宋停云与您分享--------宋停云与您分享----深入实际：软件系统不是孤立存在的，它们是在一个社会的和机构的环境中使用的、软件需求来自于这样的环境并受到这个环境的制约。满足这些社会的和机构的需求对系统的成功至关重要，许多软件系统被交付但是从未使用过，其中一个原因就是这些系统没有考虑到这类系统需求的重要性。深入实际是一项能用来了解社会和机构需求的观察技术。一个分析人员把自己放在待建系统的工作环境中，日常工作得以观察并记录参与的实际任务。深入实际的价值是它能帮助分析人员发现隐性的系统需求，这些需求是实际存在但却非规范化的过程。深入实际不是一个完全的导出方法，它应该和其他方法（如用例分析）结合使用。需求有效性验证：需求有效性验证是要检查需求能否反映客户的意愿。它和分析有很多共性，都是要发现需求中的问题。需求有效性验证很重要，由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。理由是需求的变化总是使系统设计也跟着改变，从而使系统重新测试。在需求有效性验证过程中，要对需求文档中定义的需求执行多种类型的检查。这些检查包括：有效性检查某个用户可能认为系统应该执行某项功能。然而经过进一步的思考和分析，可能发还需要添加另一些功能，或是发现系统需要的是完全不同的功能。系统有很多用户，而这些用户可能需要不同的功能，因此，任何一组需求都不可避免地要在不同用户之间协商。2．一致性检查在文档中，需求不应该冲突。即对同一个系统功能不应该出现不同的描述或相互矛盾的描述。完备性检查 需求文档应该包括所有系统用户想要的功能和约束。现实性检查可检查性检查 为减少在客户和开发商之间可能的争议，描述的系统需求应该总是可以检查的。这意味着能设计出一组检查方法来验证交付系统是否满足需求。有许多能联合使用或单独使用的需求有效性验证技术，主要有：需求评审 由一组评审人员对需求进行系统性分析。原型建立 在这个方法中，为系统客户和最终用户提供一个可执行的系统模型。他们能在这个模型上实际检验系统是否符合他们的真正需求。测试用例生成 在理想情况下，需求应该是可测试的。如果将测试作为需求有效性验证的方法，测试方法能发现需求中的很多问题。如果一个测试的设计很困难或是不可能的，那通常意味着需求的实现将会很困难，应该对此重新考虑。在编写任何代码之前就对用户需求开发测试用例是极限编程的一个完整部分。需求评审：需求评审是个手工过程，需要有客户方和承包方的人员共同参与，检查文档中的不规范处和遗漏之处。这个评审过程可以与程序审查过程一样来管理，也可以将文档中的不同部分分发给每个人，对文档进行大规模的撒网式检查。需求评审可以是正式的也可以非正式的。非正式的评审时有承包商人员与尽可能多的系统信息持有者讨论需求。在需求导出后，开发者可能要与信息持有者进行多次的谈论，信息持有者可能也没有对文章中的----宋停云与您分享--------宋停云与您分享----需求是否正确给出一个肯定的答复。即使这样，还是通过与信息持有者交谈来发现问题。这是进入下一阶段正式的评审前需要做的工作。正式评审时，开发团队要拿着需求“遍访”客户，逐条解释需求的含义，评审团队应该检查需求的一致性和作为一个整体的完备性。除此之外，评审人员还要检查一下内容：1．可检查性 描述的需求是否可实际测试？2．可理解性 需求能否被系统的购买者和最终用户所理解？3．可跟踪性 需求的出处是否清晰地记录？你可能需要会到需求的源头以便评估变更带来的影响。跟踪能力很重要，它能为评估变更系统其他部分带来的影响提供帮助。4．适应性 需求是可调节的吗？即需求变更能否不对其他系统带来大规模的影响？冲突、矛盾、错误和遗漏在需求评审期间应该能找出并正式地记录下来，然后由系统用户、系统购买者和开发商三方协商这些问题的解决方案。需求管理持久和易变的需求在需求工程过程中及系统交付后，需求进化都是不可避免的。初始理解变更了对问题的理解初始的需求变更的需求时间从进化的角度看，需求不外乎两类：持久的需求易变的需求----宋停云与您分享--------宋停云与您分享----需求管理规划需求规划在需求管理过程中是第一个基本阶段。对每个项目，规划阶段都要建立需求所需细节的层次结构。在需求管理阶段，必须决定以下内容：需求识别 每个每个需求要有一个唯一的标识以便可以被其他需求交叉索引同时可以用到可追溯的评估中。变更管理过程这是一组对变更带来的影响和成本做评估的活动。可追溯性策略这些策略定义了需求之间的关系以及需求和系统设计之间的关系，这些关系是要被记录下来的，对此要给出记录的维护方法。CASE工具支持 需求管理涉及对大量需求信息的加工。是需求描述的一个总体特性，它反映了发现相关需求的能力。需要需要维护的3类信息时：源可追溯性需求可追溯性设计可追溯性可追溯性信息通常用可追溯性矩阵来表示，可追溯性矩阵在需求、信息持有者和设计模块之间建立关联。考虑需求与需求之间关联的可追溯性矩阵，每个需求在矩阵中有一行和一列，当存在一个需求依赖时，在两个需求相应的行列交叉处做一记录。需求变更管理----宋停云与您分享--------宋停云与您分享----问题分析和变更描述问题分析和变更描述变更分析和成本计算变更实现

修正后的需求----宋停云与您分享--------宋停云与您分享----需求变更管理----宋停云与您分享--------宋停云与您分享----需求变更应该处理全部的需求变更。一个需求变更过程有三个基本阶段：问题分析和变更描述过程始于一个被识别的问题或是一份明确的变更提议。在这个阶段，要对问题或变更提议进行分析以检查它的有效性。分析结果反馈给变更的请求者，有时会产生一个更明确的需求变更提议。变更分析和成本计算 使用可追随性信息和系统需求的一般知识对被提议的变更产生的影响进行评估。变更的成本计算不仅要估计对需求文档的修改，而且在适当的时候，还要估计系统设计和实现的成本。一旦分析完成，就有了对此变更是否执行的决策意见。3．变更实现必要的话，需求文档，系统设计和实现都要做修改。需求文档应该有一个很好的形式，使得变更需求不会带来大量文字的修改。对于程序，文档的可变性通过最小化外部引用和尽量使之模块化来实现。因此，部分的改变和重写不会影响文档的其他部分。快速软件开发（p240）----宋停云与您分享--------宋停云与您分享----内容：

敏捷方法极限编程

摘自 《SoftwareEngineeringEight》机械工业出版社----宋停云与您分享--------宋停云与您分享----快速应用开发软件原型构造事实上，很多业务都宁愿牺牲一些软件质量并降低某些需求来赢得快速软件的移交。，其描述、设计、开发和测试是交织在一起的。，每一个增量包括新的系统功能。尽管有很多快速软件开发的方法，但是它们都有一些基本的特性：描述、设计和实现过程是并发的。没有详细的系统描述，设计文档得到了最少化，或者是由实现----宋停云与您分享--------宋停云与您分享----定义系统可交付的增量定义系统可交付的增量设计系统体系结构定义系统增量构建系统增量验证增量否移交最后的系统是系统完成验证系统集成增量系统通过一系列增量开发出来。Web的界面或者是为专门的系统比如微软的视窗所设计的界面。增量式开发包括用增量来生产和移交软件而不是单个包来完成。每个过程循环产生一个新的软件增量。采用增量方法进行软件开发有两个优点：1．客户服务的加速移交 系统的早期增量可以移交高优先级的功能，这样用户就能在系统开发的早期从系统中受益。客户能在实际中看到他们的需求，并可以进一步对系统后面的版本提出变更意见。2．用户的参与系统用户必须参与到增量开发过程中来，这是因为他们必须向开发团队提出有关所移交的增量的反馈意见。他们不仅仅意味着更容易达到他们的需求；同时也意味着系统的最终用户对系统承担了义务，由此更愿意看到系统发挥作用。增量式开发的通用过程模型如下图：迭代式开发过程就作者的观点，增量式软件开发对于绝大多数业务、电子商务和个人系统来说是很好的一种方法，因为它反映了我们解决问题的基本方式。我们很少事先给出问题的完全解，而是一步一步地朝正确的解迈进，在我们意识到做错了的时候采取回溯的方法。然而，采用此方法也存在一些实际的困难，特别是在有相当僵化程序的大型企业中，或者是对那些通常都通过外部采购来完成软件开发的机构而言。迭代式开发和增量式移交面临的主要困难有：----宋停云与您分享--------宋停云与您分享----管理问题合同问题有限性证明问题维护问题 连续的变更使得任何软件系统的结构变坏。这意味着除了最初的开发人员外，任何其他嗯都会发现软件十分难以理解。减轻问题的方法是对软件重新分解，即在开发过程中持续地改善软件结构（论文切入点）当然，也存在某些类型的系统，在其中采用增量式开发和移交是不太合适的。大型系统，它的开发团队可能遍布各地；一些嵌入式系统，他的软件是依赖于硬件开发的；而有些要求极高的系统，所有需求必须分析，以检查是否有系统的安全性和信息安全性受到交互的影响。这些系统当然也受到不确定性和变更需求的困扰。因此，要解决这些问题并获得增量式开发的好一种混成过程，即迭代地开发一个系统原型，并把它作用于平台来试验系统的需求和。增量式开发和原型构造有多种目标：增量式开发的目标是向用户移交一个可用的系统。这意味着一般应当从用户需求开始，这些需求被理解得最好且优先级最高。低优先级和模糊的需求在用户要求它们的时候再去实现。进化式开发进化式开发交付的系统概要需求抛弃式原型构可执行原型+系统描述增量式开发和原型构造软件原型的构造原型是软件系统的初始版本，用来演示概念并尝试设计选择，通常用来发现更多的问题和可能的解决方案。快速的、迭代式原型开发是很必要的，这样能得到控制，系统信息持有者能噶偶在软件的早期阶段对系统进行系统是试验。----宋停云与您分享--------宋停云与您分享----建立原型目标定义原型功能建立原型目标定义原型功能开发原型评估原型原型构造计划概要定义可执行原型评估报告组件与对象之间的区别：组件式可部署的实体组件不定义类型组件实现是不透明的组件式于语言的组件式标准化的----宋停云与您分享--------宋停云与您分享----组件模型OMGCORBA组件模型、SunEJB和微软公司的COM+等。P274 关于组建模型的详细定义----宋停云与您分享--------宋停云与您分享----矿脉样本点回归模型讨论分析问题提出：13x，yx,yx,yyx：注：散点的程序如下：>>x=[2,3,4,5,7,8,10,11,14,15,15,18,19];>>y=[106.42,109.20,109.58,109.50,110.00,109.93,110.49,110.59,110.60,111.90,110.76,111.00,111.20];>>plot(x,y),stem(x,y);由散点图可看出，yx二次函数模型为：y=a0+a1*x+a2*x^2+n双曲线模型为：y=b0+b1/x+n当n大致服从均值为零的正态分布时,则说明该模型选择是合适的。建模思想：通过散点图和比较建立的两个可能的回归模型的结果，找出最适合的模型来表示此矿脉金属含量y与到原点距离x的关系。模型求解：直接利用MATLAB统计工具箱重的命令regress求解,程序如下：1．二次函数模型：1----宋停云与您分享--------宋停云与您分享----y=[106.42;109.20;109.58;109.50;110.00;109.93;110.49;110.59;110.60;110.90;110.76;111.00;111.20];x=[122^2;133^2;144^2;155^2;177^2;188^2;11010^2;11111^2;11414^2;11515^2;11515^2;11818^2;11919^2];[b,bint,r,rint,stats]=regress(y,x,0.05)b=106.95220.5271-0.0170bint=105.4769 108.42750.1896 0.8645-0.0329 -0.0011r=-1.51820.81980.79190.33800.1923-0.1495-0.0310-0.1007-0.3956-0.1292-0.26920.07440.3769rint=-1.7369 -1.2995-0.3263 1.9660-0.4503 2.0341-1.0463 1.7223-1.2036 1.5881----宋停云与您分享--------宋停云与您分享-----1.5331 1.2341-1.3968 1.3348-1.4645 1.2631-1.7621 0.9709-1.5276 1.2693-1.6566 1.1183-1.1713 1.3200-0.6496 1.4035stats=0.7759 17.3112 0.0006 0.41822．双曲线模型：y=[106.42;109.20;109.58;109.50;110.00;109.93;110.49;110.59;110.60;110.90;110.76;111.00;111.20];x=[11/2;11/3;11/4;11/5;11/7;11/8;11/10;11/11;11/14;11/15;11/15;11/18;11/19];[b,bint,r，rin