|
对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。 从软件架构需求逐次讨论： · 需求怎么来的？（需求开发=愿景分析+需求分析） · 如何判断掌握的需求全不全？（功能、质量、约束三类需求都不能漏） · 从需求向设计转化的关键思维是什么？（功能、质量、约束影响架构的不同原理是核心） 愿景分析，要解决项目、产品或解决方案的起源问题。所谓明确愿景，就是针对系统目标、主要特性、功能范围和成功要素等进行构思并达成一致。
上下文图是一种“辅助说明”需求范围的方式，它清晰地描述了待开发系统与周围所有事物之间的界限与联系。上下文图可以由市场部门绘制（画法相对随意例如利用PowerPoint），也可以由架构师来绘制（推荐UML用例图的顶级视图）。 上下文图的要点归纳为两点： · 内容原则。关注本系统，以及和本系统有关联的因素，但不关注本系统内部——既不关注内部功能，也不关注内部结构。 · 形式原则。明确标识出要研发的是什么系统，保持它为黑盒，将它画在上下文图的中央位置，其他相关因素环绕周围。 愿景分析实践要领 愿景分析，换个角度讲就是我们常说的需求调研（愿景分析的说法重目标，需求调研的说法重活动）。 愿景 = 业务目标 +范围 + Feature + 上下文图 什么是软件需求？简单地说，软件需求就是“这个软件到底要为用户做什么”。 · 需求捕获。 · 需求分析。 · 系统分析。 需求捕获是获取知识的过程，知识从无到有、从少到多。需求采集者必须理解用户所从事的工作，并且了解用户和客户希望软件系统在哪些方面帮助他们。 需求分析是挖掘和整理知识的过程，它在已掌握知识的基础上进行。毕竟，初步捕获到的需求信息往往处于不同层次，也有一些主观甚至不正确的信息。而经过必要的需求分析工作之后，需求会更加系统、更加有条理、更加全面。 那么系统分析呢？如果说，需求分析致力于搞清楚软件系统要“做什么”的话，那么系统分析已经开始涉及“怎么做”的问题了。系统分析是针对系统所要面临的问题，搜集相关的资料，以了解产生问题的原因所在，进而提出解决问题的方法与可行的逻辑方案，以满足系统的需求，实现预定的目标。 【1】将需求捕获和需求分析视为两个阶段，这是错误的。 需求捕获、需求分析以及系统分析是相互伴随、交叉进行的。 · 需求工作伊始，更多进行需求捕获，需求分析工作偏少； · 随着掌握的需求信息越来越多，对需求的分析才可能越来越多； · 世界不是“问题—解决方案”这么简单的模型，是“问题—解决方案—衍生问题—解决方案—……”才现实——上一级的解决方案对下一级就意味着“待解决的问题”。于是，需求分析连带出更多系统分析的工作非常正常。我们需要不断的进行发散、收敛、发散、收敛才能真正的解决问题。 【2】需求分析与系统分析混淆 实践中，需求分析和系统分析常被混淆。 为了不再混淆这两者，应明确： · 需求分析，是搞清楚系统“做什么”。 · 系统分析，关注系统“怎么做”。更直白地说，系统分析 ≈ 初步的高层设计。
对于不同的系统分析方法，其工作成果差异很大。通过结构化分析方法得到的最重要的工作成果是数据流图，而面向对象的系统分析方法得到的工作成果主要是分析类图、鲁棒图、序列图等——其中分析类图描述设计的静态方面，而鲁棒图和序列图描述设计的动态方面。 首先，需求是分层次的。本质上，我们是根据“不同层次的涉众提出需求所站的不同立场”，将需求划分为三个层次。其实，为了便于需求跟踪（核心是跟踪需求来源），我们也必然要这么做。 · 组织级需求。包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。 · 用户级需求。用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？ · 开发级需求。开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？ 其次，需求还必须从不同方面进行考虑。实践一再表明，忽视质量属性和约束性需求，常常导致架构设计最终失败。例如，一个网上书店系统： · “浏览书目”、“下订单”、“跟踪订单状态”以及“为书籍打分”等，属功能需求。 · 系统应当有良好的“互操作性”和“安全性”，这是质量属性需求。 · 系统“必须运行于Linux平台之上”，则属于约束性需求之列。 也就是说，从“直接目标还是间接限制”的角度把需求分为三类。 · 功能需求：更多体现各级直接目标要求。 · 质量属性：运行期质量 + 开发期质量。 · 约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素。
1、功能——它描述系统“应该做什么” 2、质量——它将软件的质量属性划分为三大类：产品操作、产品修改、产品改型。 · 开发期质量属性其实包含了和软件开发、维护和移植这三类活动相关的所有质量属性，可以说这里的“开发”是相当广义的； · 开发期质量属性是开发人员、开发管理人员和维护人员都非常关心的，对最终用户而言，这些质量属性只是间接地促进用户需求的满足； · 运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类属性，这些质量属性直接影响着用户对软件产品的满意度。 性能是指软件系统及时提供相应服务的能力。具体而言，性能包括速度、吞吐量和持续高速性三方面的要求： · 吞吐量通过单位时间处理的交易数来度量； · 速度往往通过平均响应时间来度量； · 而持续高速性是指保持高速处理速度的能力。 （1）性能和效率的关系 安全性 易用性 持续可用性 可伸缩性 互操作性 可靠性 鲁棒性 开发期质量属性则随着软件系统规模的日益增长。 易理解性——尤指设计被开发人员理解的难易程度。 可扩展性——可扩展性是指为适应新需求或需求的变化为软件增加功能的能力。我们在实际工作中，经常将可扩展性称为灵活性。 可重用性——可重用性是指重用软件系统或其一部分能力的难易程度。 可测试性——可测试性是指对软件测试以证明其满足需求规约的难易程度。在实际工作中主要指进行单元测试、插桩测试等的难易程度。 可维护性——可维护性是指为了达到下列三种目的之一而定位修改点并实施修改的难易程度：修改Bug；增加功能；提高质量属性。 可移植性——可移植性是指将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。 务实地，我们可以将运行期质量属性和功能性一起视为“软件的外部质量”，而将开发期质量属性视为“软件的内部质量”。无疑，软件的内部质量制约着软件的外部质量；在软件开发管理本身已经十分复杂的今天，想使内部质量很差的软件具有良好的外部质量几乎是不可能的。同时，随着商业环境变化的加剧，很多企业软件出现了“建成即废弃”的尴尬情况。于是，软件系统的内部品质越来越受到重视，通过强化软件系统的可扩展性、可重用性、易理解性等开发期质量属性，可以使软件有更多被改变、被重用的空间。 3、约束 约束不是行为，是设计或项目的某些限制条件。这些限制条件也属于需求，但通常被称为“约束”来强调其限制性。 约束需求 = 业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素。 架构师应当直接或间接（通过需求分析员）地了解和掌握上述需求和约束，并深刻理解它们对架构的影响，只有这样才能设计出合适的软件架构。 总结——软件需求 = 功能 + 质量 + 约束 功能、质量、约束这三种需求影响架构的不同原理，要进行“理性设计”，这是基础。 |
|
|
