需求建模教程.docxVIP

----宋停云与您分享---- ----宋停云与您分享---- 软件需求（p73） 要点：要选择一个标准进行剪裁。要定制专门的需求描述标准，与需求文档相关的 IEEE 标准是个合适的起点。 ----------------摘自《Software Engineering Eight Edition》 机械工业出版社 程成 陈霞 译 需求工程过程（p87） 内容： 可行性研究 需求导出和分析 需求有效性验证 需求管理 需求工程的目标是创建和维护系统需求文档。事实上，所有的系统需求都是可变的。负责开发的软件工程人员不断地加深对软件的理解，购买系统的机构本身也在变，系统的硬件、软件和组织环境都在变。管理这些变更的过程就称为“需求管理”。 可行性研究 可行性研究的输入信息是一系列初步需求、系统的一个框架描述和希望系统如何支持业务过程的说明性信息，可行性研究的结果是给出一份报告，对需求工程和系统开发过程是否值得进行给出具体的意见和建议。 进行一项可行性研究包括信息评估、信息汇总和报告生成。信息评估阶段就是要找出与上面提出的三个问题相关的信息。一旦这些信息收集好，下一步的工作就是要在信息源中找到这些问题的答案。 需求导出和分析 在初始的可行性研究之后，下一个需求工程过程就是需求导出和分析。在这个活动中，软件开发技术人员要和客户及系统最终用户一起调查应用领域，即系统应该提供什么服务、系统应该具有什么样的性能以及硬件约束条件等。需求分类和组织主要是识别来自不同信息持有者的彼此重叠的需求并对他们进行合理归类。归类需求最常用的方法是使用一个系统结构模型来识别子系统，并将需求与各子系统相关联。它强调需求工程与体系与设计不能总是分离。 将需求写在卡片上这个方法在“极限编程中”是十分有效的。需求发现 需求发现是这样一个过程：收集准备建立的系统和正在使用的系统信息，并从这些信息当中提取用户 和系统需求。需求发现阶段的信息源包括已有文件、系统信息持有者以及类似系统的相关内容。在需求发现过程中，我们可以通过与信息持有者交谈和对他们的观察来获得信息，期间可以使用场景的方法和原型来帮助需求的发现。常用的需求发现技术包括：访谈技术、场景技术和深入实际技术。 访谈： 通过访谈来全面了解系统信息是一种很好的方法。但是，对于应用领域需求，通过访谈的方式是很难获得的。 很难从访谈中到处领域知识，有以下两个原因： 所有的应用专家都使用专业术语和行话。 有些领域知识对于这些人来说太普通了，以至于他们要么是难以找到合适的次词语来解释，要么会不自觉的认为这些概念太基本，不值得去提。 ----宋停云与您分享---- ----宋停云与您分享---- 访谈对于导出机构需求和约束来说不是一项很有效的技术，因为，在机构中这些信息持有者之间存在着一些很微妙的关系。公布出来的机构结构很少能真正反映机构中真实的决策模式，被访问者不愿以对陌生人揭露机构中真实的一面。通常，人们总是不情愿去涉及影响需求的这些政治和机构因素。 有能力的采访者通常有两个特征： 他梦思想开放，对需求没有先入之见，而且很愿意听取信息持有者的意见。如果信息持有者提出意外的需求，他们愿意主动改变自己的意见对系统原有的看法。 他们会利用问题、需求建议或者通过建议来引发被访问者开始讨论。简单的提问，比如“告诉我你需要什么?”是不会得到什么有价值的信息的。绝大多数人都认为在一个指定的情景中谈论要比泛泛地谈论容易的多。 通过访谈所获得的信息补充了通过文档、用户观察以及其他手段所获得的信息。有时，除了文档以 外访谈可能是系统需求的唯一来源。然而，访谈本身很容易漏掉一些基本的信息，所以，我们应该结合其他需求导出技术来使用它。 场景： 在把细节加入到纲要的需求描述中，场景可能特别有用。场景是对交互实例片段的描述。每个场景可能有一个或多个可能的交互。 场景开始于一个交互的框架，在到处过程中，细节被逐渐增加，直到产生交互的一个完整的描述。在绝大多数情况下，一个场景可能包括以下内容： 在场景的开始部分有一个系统状态描述。 一个关于标准事件流的描述。 一个关于哪儿会出错以及如何处理的描述。 有关其他可能在同一时间进行的活动的描述。 在场景完成后系统状态的描述。 基于场景的需求导出可以再狠随意的情况下进行，需求工程师与信息持有者共同识别出场景并捕获这些场景的细节。还有一种一种较结构化的方法，如时间场景法或用例法也可以。 用例： 用例是一种基于场景的需求导出技术。有时会产生认识上的混乱，是否一个用例本身就是一个场景，如 Fowler 所建议的，一个用例封装了一组场景，每个场景就是一个线程。在这种情况下，一个标准的交互就会有一个场景，另外，每个可能的异常会有一个场景。 用例识别与系统的单个交互。它们可以用文本记录下来或者是链接到给出更详细场景的 UML 模型