架构设计实践二：需求分析

标签：

1.1 三个问题

掌握好需求分析，需要掌握三个问题的解决方式。

• 需求如何获得？需求开发=愿景分析+需求分析
• 如何判断需求全不全？功能、质量、约束三类需求
• 如何从需求转换为设计？功能、质量、约束对架构产生不同的影响。

1.2 软件研发与交付过程总图

其中概念化阶段一般都要完成愿景分析、风险评估、可行性分析及项目进度和成本的粗略估算，输出《愿景与范围文档》；需求分析阶段则完成需求捕获、需求分析，得到《软件需求规格说明书》，一个关键的思路是需求捕获与需求分析是迭代着进行的，完成需求捕获之后再统一进行需求分析的思路是不具备可信性的；架构设计阶段完成通过关键需求确定、概念架构设计、细化架构设计和架构验证，得到架构设计说明书。

1.3 愿景分析（简要）

愿景分析的目的是明确愿景，即针对系统目标、功能范围、主要特性及成功要素等进行构思并达成一致。产出为《愿景与范围文档》，有的产品型公司会称之为《市场需求文档》MRD，有的产品型公司则称之为《产品需求文档》PRD，项目型公司则可能称之为《项目立项书》。

愿景=业务目标+范围+特性+上下文图。

• 业务目标是客户组织应用系统所需要达到的目标，例如提升组织的某种能力，简化组织的某种过程。
• 范围则是则是对需求的面状刻画，说明为实现业务目标，系统需要提供哪些主要的功能块。
• 特性是对需求的点状刻画，列举系统大致支持哪些功能组（比范围的功能块要细），强调说明某些具有特色的功能项，点出功能项的更细节优势，技术特色、其他特色的强调。
• 上下文图用于刻画系统的边界，将系统置于中央，周围环绕所有与系统相关的所有外部事物，关注本系统及与本系统相关的外部因素，但不关注本系统内部，保持本系统为黑盒，其主要目的是为保证需求发现过程中的全面性。

1.4 需求分析（简要）

需求分析的过程是需求捕获和需求分析迭代进行的过程，而不是“需求捕获->需求分析”的线性过程。

需求捕获是获取知识的过程，要求理解用户所从事的工作，并了解用户和客户希望软件系统在哪些方面帮助他们。需求捕获的输出是一系列的“需求采集卡”，记录需求类型、需求描述、需求北京、需求提出者等信息。

需求分析则是挖掘和整理知识的过程，在通过需求捕获所掌握的知识基础上进行，使得需求更系统、全面、有条理。需求分析的输出是《软件需求规格说明书》，精确阐述一个系统必须提供的功能、必须达到的质量属性及必须遵守的约束。一般使用用例技术来进行需求分析，对于重要需求，除用例图外，还需给出详细的用例规约。

1.5 如何判断需求是否全面

1.5.1       需求层次-方面矩阵

使用二维需求矩阵来判断需求是否全面。这个是目前我见到的最具可操作性的方法。

一方面，需求是分层次的，根据涉众的不同，可将需求分为三个客户级需求（也称组织级需求）、用户级需求和开发级需求；另一方面，需求可分为功能、质量和约束三个方面。通过检查层次-方面的二维矩阵，即可较好的判断需求是否全面。

1.5.2       软件质量的分类

软件质量涉及众多，但是从关注者的角度将其划分为运行期质量和开发期质量，可将其划分的很清楚。

所谓运行期质量，指系统运行期间，最终用户可以感受到的质量属性，包括性能、易用性、安全性、健壮性、可靠性、可用性、可伸缩性、互操作性。

开发期质量则指的是系统开发、维护、移植过程中所体现出来的属性，是软件的开发、构建、部署人员所关心的质量属性，包括：

• 开发人员关注的：易理解性（这个很容易被忽视）、可扩展性、可重用性、可维护性、可移植性
• 测试人员关注的：易测试性
• 部署人员关注的：易部署性

关键质量属性说明

• 性能：性能包括速度、吞吐量和持续高速型，速度使用平均响应时间来衡量，吞吐量使用单位时间交易数来衡量，持续高速性指系统保持持续高速处理速度的能力，则与实时系统有关，实时系统对每次系统响应时间都有严格要求。需要注意的是，速度快一般意味着高吞吐量，但是速度慢不见得吞吐量就低，这与网络延时与带宽的关系相似。
• 安全性：同时兼顾向合法用户提供服务，以及阻止非法用户使用的能力。高安全性意味着“同时兼顾”。
• 可用性与可靠性：可靠性是指系统在一定时间内无故障运行的能力，一般用平均无故障时间来衡量，而高可用性则指的是“系统长时间为用户提供可用服务的能力”（原书中为“系统长时间无故障运行的能力”，应当不太准确）。经常使用集群的方式来提高系统的高可用性，但是显然，如果将整个集群视为一个整体，任意一台机器宕机，则整个系统都不能判定为“无故障运行”，所以其可靠性相比于单机是下降的，但是只要集群中足够多的机器正常工作，则系统“为用户提供可用服务”的能力并不受影响，因此集群提高了系统的可用性。

1.5.3      约束

可从客户、用户、开发三个层次来分解约束，确保约束条件的完整。另一个角度，约束=业务环境因素（来自客户）+使用环境因素（来自用户）+构建环境因素（来自开发、维护人员）+技术环境因素（业界技术约束）。

1.6 如何从需求过渡至设计

• 使用功能来划分子系统、模块：功能是发现职责的依据，每个功能均由一条职责链来完成，通过为功能规划职责链，将职责划分到子系统，为子系统制定接口，确定基于接口的交互机制，来推动架构设计的进行。
• 使用质量来完善架构：必须基于当前的中间架构，进一步考虑质量要求，对中间架构进行调整、细化。
• 约束：一部分约束直接制约设计决策，例如团队成员仅掌握Java相关开发技术；一部分约束可转换为功能，例如银行系统的“本系统执行现行利率”引出“利率调整”的功能；一部分约束转换为质量属性，例如“柜员计算机水平普遍不高”引出易用性需求。

架构设计实践二：需求分析

标签：

原文地址：http://www.cnblogs.com/lidabnu/p/4321646.html