软件需求分析复习要点

本文根据华南理工大学软件学院《软件需求分析》课程及相关教材《UML和模式应用》总结，作复习回顾用。

UML是标准的图形表示法。它并不是OOA/D，也不是方法。OOD(以及所有软件设计)与作为其先决活动的需求分析(requirement analysis)具有紧密联系，而在需求分析中通常包含用例(use case)的编写。

分析(analysis)强调的是对问题和需求的调查研究，而不是解决方案。“分析”要加以限制，说清楚是“需求分析”还是“面向对象分析”。

设计(design)强调的是满足需求的概念上的解决方案(在软件方面和硬件方面)，而不是其实现。“设计”也要加以限制。

在面向对象分析(object-oriented analysis)过程中，强调的是在问题领域内发现和描述对象。

在面向对象设计(object-oriented design)过程中，强调的是定义软件对象以及它们如何协作以实现需求。

需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例(use case)。

面向对象分析的结果可以表示为领域模型(domain model)，在领域模型中展示重要的领域概念或对象。领域模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化，因此也被称为概念对象模型(conceptual object model)。

顺序图(sequence diagram，UML的一种交互图)是描述协作的常见表示法。它展示出软件对象之间的信息流，和由消息引起的方法的调用。

可以用设计类图(design class diagram)来有效地表示类定义的静态视图。这样可以描述类的属性和方法。

OO设计和语言能够缩小软件构件和我们所设想的领域模型之间的差距，即实现低表示差距(lower representational gap)。

统一建模语言(UML)是描述、构造和文档化系统制品的可视化语言。UML定义了各种UML简档(UML profile)，专用于某些常用主题领域的表示法子集。

UML表示法的基础是UML元模型(meta-model)，它描述建模元素的语义，UML元模型主要对模型驱动架构(model driven architecture, MDA)CASE工具提供商具有影响。

应用UML的三种方式：作为草图、作为蓝图、作为编程语言。

敏捷建模(agile modeling)强调了UML作为草图的方式，这也是使用UML的普通方式，而且通常对时间投入具有高回报(一般费时较短)。

UML描述的是原始图类型，如类图和顺序图。同一种表示法可以用来描述模型的三种透视图和类型：概念透视图、规格说明透视图、实现透视图。

在UP中，领域模型中的UML框架被称为领域概念(domain concept)或概念类(conceptual class)。领域模型表示的是概念透视图。设计模型中的UML框被称为设计类(design class)。设计模型依据建模者的需要，表示的是规格说明透视图或实现透视图。

概念类(conceptual class)，现实世界中的概念或事务。

软件类(software class)，无论在过程还是方法中，都表示软件构件在规格说明或实现透视图中的类。

实现类(implementation class)，特定OO语言(如java)中的类。

相对于顺序或瀑布(waterfall)生命周期，迭代和进化式开发(iterative and evolutionary development)对部分系统及早地引入了编程和测试，并重复这一循环。在迭代开发中，我们依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计。相比之下，瀑布模型提倡在编程之前就预先完成需求和设计步骤。

软件开发过程(software development process)描述了构造、部署以及维护软件的方式。统一过程(unified process)已经称为一种流行的构造面向对象系统的迭代软件开发过程。Rational统一过程(RUP)是对统一过程的详细精化。

在UP项目中可以引入XP(极限编程，extreme programming)的测试驱动开发(test-driven development)、重构(refactoring)和持续集成(continuous integration)等实践。

UP是迭代过程；UP实践提供了如何实施OOA/D的示范结构；UP具有灵活性，可以应用于轻量级和敏捷方法，这些方法包括其他敏捷方法(诸如XP或Scrum)的实现。

迭代开发(iterative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期(如三个星期)小项目，称为迭代(iteration)。每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代和增量式开发(iterative and incremental development)，也称为迭代和进化式开发(iterative and evolutionary development)。每次迭代都产生可执行的但不完整的系统，它不是已经准备好可以交付的产品。直到多次迭代之后，系统才可能合格地用于产品部署。迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型。其输出是最终系统的产品子集。

迭代开发的优点：

• 减少项目失败可能性，提高生产率，降低缺陷率。
• 在早期环节高风险。
• 早起可见的进展。
• 早起反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。
• 可控复杂性。
• 一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。

大部分迭代方法建议迭代时间在2~6周之间。小步骤、快速反馈和调整是迭代开发的主要思想，迭代时间过长会破坏迭代开发的核心冬季并增加项目风险。时间定量超长的迭代不符合迭代开发的观点。迭代的一个关键思想是时间定量(timeboxed)，或时长固定。

在瀑布生命周期过程中，视图在变成之前定义所有或大部分需求。而且通常于变成之前创建出完整的设计。

UP提倡风险驱动(risk-driven)与客户驱动(client-driven)相结合的迭代计划。风险驱动迭代开发更为明确地包含了以架构为中心(architecture-centric)迭代开发的实践，意味着早期迭代要致力于核心架构的构造、测试和稳定。

敏捷开发(agile development)方法通常应用时间定量的迭代和进化式开发、使用自适应计划提倡增量交付并包含其他提倡敏捷性的价值和实践。

采用敏捷方法并不意味着不进行任何建模；建模和模型的目的主要用于理解和沟通，而不是构建文档；只需对设计空间中不常见、困难和几首的一小部分问题建模和应用UML；不要单独一个人建模；并行地创建模型；所有模型可能是不准确的；开发者应该为自己进行OO设计建模。

UP可以采纳和应用可适应性和轻量级的精神——敏捷UP。UP是迭代和不断进化的，所以在实现前的需求和设计是不完整的。对于整个项目不应有详细的计划。

UP项目将其工作和迭代组织为四个主要阶段：

1. 初始(inception)：大体上的构想、业务案例、范围和模糊评估。
2. 细化(elaboration)：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
3. 构造(construction)：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
4. 移交(transition)：进行beta测试和部署。

初始阶段不是需求阶段，而是研究可行性的阶段，在此阶段要进行充分的调查以确定继续或终止项目。细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。

UP描述了科目(discipline)中的工作活动。科目是在一个主题域中的一组活动(及相关制品)，例如需求分析中的活动。在UP中，制品(artifact)是对所有工作产品的统称。

业务建模：领域模型制品，使应用领域中的重要概念的可视化。

需求：用以捕获功能需求和非功能需求的用力模型及其补充性的规格说明制品。

设计：设计模型制品。

在UP中，实现表示变成和构建系统，而不是部署。环境科目是指建立工具并为项目定制过程，也就是说，设置工具和过程环境。UP的一个关键内涵是，所有活动和制品都是可选的，除了代码。

书上讲了两个案例，没有知识点。

想要定义摄像并大致得出所需的预算，就必须研究需求。但是，初始阶段的目标并不是定义所有需求，或产生可信的预算或项目计划。

初始阶段作为UP的第一个阶段也不需要完成所有需求或建立可靠预算和计划。以上内容在细化工程中逐步完成。

大多数需求分析是在细化阶段进行的，并且伴以具有产品品质的早期编程和测试。

一句话概括初始阶段：遇见项目的范围、设想和业务案例。

一句话概括初始阶段要解决的主要问题：涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

需求(requirement)就是系统必须提供的能力和必须遵从的条件。

UP能够包容需求中的变更，并将其作为项目的基本驱动力。如果发现在所谓的UP或迭代项目中，试图在开始变成和测试之前指定大多数或所有的需求(用例等)，则意味着并非规范的UP或迭代项目。UP提倡使用一些有效的技巧以获得启示。

在UP中，需求按照“FURPS+”模型进行分类，这是一种有效的记忆方法：

• 功能性(functional)：特性、功能、安全性。
• 可用性(usability)：人性化因素、帮助、文档。
• 可靠性(reliability)：故障频率、可恢复性、可预测性。
• 性能(performance)：响应时间、吞吐量、准确性、有效性、资源利用率。
• 可支持性(supportability)：适应性、可维护性、国际化、可配置性。

“+”是指一些复制性的和次要的因素，比如：

• 实现(implementation)：资源限制、语言和工具、硬件等。
• 接口(interface)：强加于外部系统接口之上的约束。
• 操作(operation)：对其操作设置的系统管理。
• 包装(packaging)：例如物理的包装盒。
• 授权(legal)：许可证或其他方式。

其中某些属性可以统称为质量属性(quality attribute)、质量需求(quality requirement)。一般使用中，需求按照功能性和非功能性来分类。

UP提供了一些需求制品，关键制品包括：

• 用例模型：一组使用系统的典型场景。主要用于功能需求。
• 补充性规格说明：基本上是用例之外的所有内容。
• 词汇表：定义重要的术语，也包含数据字典(data dictionary)。
• 设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。
• 业务规则：通常描述了凌驾于某一软件项目的需求或政策。

用例是文本形式的情节描述，广泛应用于需求的发现和记录工作中。

参与者(actor)是某些具有行为的事务。场景(scenario)是参与者和系统之间的一系列特定的活动和交互，也称为用例实例(use case instance)。场景是使用系统的一个特定清洁或用例的一条执行路径。用例(use case)就是一组相关的成功和失败场景集合。

用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。

UMl用例图可以为系统及其环境提供良好的语境图(context diagram)。

用例不是面向对象的，编写用例时也不会进行OO分析。

相对于所讨论系统(system under discussion, SuD)来说，有三种外部参与者：

• 主要参与者(primary actor)：具有用户目标，并通过使用SuD的服务完成。
• 协助参与者(supporting actor)：为SuD提供服务。
• 幕后参与者(offstage actor)：在用力行为中具有影响或利益，但不是主要或协助h参与者。

详述用例(fully dressed use case)是结构化的，它展示了更多细节，并且更为深入。

通常用例描述的是对一个软件系统(或硬件加软件)的使用，这种情况下称之为系统用例(system use case)。企业级的过程描述被称为业务用例(business use case)。用户目标级别(user-goal level)是通常所使用的级别，描述了实现主要参与者目标的场景，该级别大致相当于业务流程工程中的基本业务流程(elementart business process, EBP)。子功能级别(subfunction-level)用例描述支持用户目标所需的子步骤。

用例应该包含满足所有涉众关注点的事务。

前置条件(precondition)给出在用例中场景开始之前必须永远为真的条件。在用例中不会检查前置条件，总是被假设为真。

成功保证(或后置条件)给出用例成功结束后必须为真的事务，包括主成功场景及其替代路径。

主成功场景也被称为“理想路径”场景、“基本流程”或“典型流程”。它描述了满足涉众关注点的典型成功路径，它通常不包括任何条件或分支。

扩展部分描述了其他所有场景或分支，包括成功和失败路径。扩展部分比主成功场景部分所占篇幅更长并且更为复杂。

黑盒用例(black-box use case)是最常用和推荐使用的类型；它不对系统内部工作、构建或设计进行描述，它以职责描述系统。

发现用例的基本过程：

• 选择系统边界。
• 确定主要参与者。
• 确定每个主要参与者的目标。
• 定义满足用户目标的用例。

对应用需求分析来说，表示用例的有效级别：老版测试、EBP(elementary business process，基本业务过程)测试、规模测试。

UP提倡用例驱动开发(use-case driven development)，这意味着：

• 功能需求首先记录在用例中。
• 用例是迭代计划的重要部分。
• 用例实现(use-case realization)驱动设计。
• 用例经常会影响用户手册的组织。
• 功能或系统测试应当符合用例的场景。
• 为重要用例的最常用场景创建UI“向导”或快捷方式可以方便执行常用任务。

(待续)

原文地址：https://www.cnblogs.com/JHSeng/p/11105232.html