软件需求与架构解析

# 软件需求与架构解析 ## 1. 需求的挑战与应对 ### 1.1 易变性问题 在软件开发中，需求的易变性是一个不可避免的难题，也是导致项目进度延误的主要原因。我们无法阻止变化的发生，只能学会适应并管理它。 管理需求变化的方法有： - **创建需求积压列表**：采用Scrum方法时，新需求应添加到产品积压列表中，而非当前冲刺积压列表，这样可确保当前冲刺正常进行，并在冲刺结束时统一评审需求。 - **让用户参与决策**：给用户提供选择，如告知用户实现新功能会使进度延长，让其决定是否继续；或者若要保持原进度，只能实现和测试部分功能，让用户选择最需要的。这体现了敏捷开发中勇于为项目整体利益做决策的精神。 ### 1.2 非技术问题 从开发者的角度看，需求中的非技术问题是最棘手的。这类问题本质上是政治性的，例如不同客户群体或管理者对程序需求有不同看法，或者开发的程序会影响某些部门的影响力等。遇到这类问题，建议让高层管理者处理。 ### 1.3 需求分析 记录下需求后，需要对其进行分析，确保是适合程序的正确需求。分析主要包括以下三个部分： 1. **需求分类与组织**：将需求分类并组织到相关领域，这对设计师很有帮助。 2. **需求优先级排序**：由于无法在首次产品发布时实现所有需求，因此需要对需求进行优先级排序，以此确定每个中间版本的内容。 3. **需求一致性检查**：检查每个需求与其他需求的关系，确保它们构成一个连贯的整体。可以通过以下几个问题进行检查： - 每个需求是否与项目总体目标一致？例如，若程序是用于售书，就无需计算用户的高尔夫差点。 - 该需求是否真的必要？是否可以移除某些不影响程序基本功能的内容？如首次发布版本只需让用户买书，就不必允许购买帆船。 - 该需求是否可测试？这是需求分析中最重要的问题。若无法确定如何测试一个需求，就无法知道是否正确实现以及是否完成。在大多数敏捷方法中，规则是先编写测试，再编写代码。 - 该需求在当前技术环境下是否可行？对于非功能性需求，要考虑目标平台和硬件约束。例如，目标平台是运行macOS的Macintosh，就不能使用仅适用于Windows的DirectX图形库。 - 该需求是否明确无误？需求应尽可能精确，避免出现“or”或“may”等容易引起歧义的词汇，以免在发布后才发现错误。 下面用mermaid流程图展示需求分析的流程： ```mermaid graph LR A[记录需求] --> B[需求分类与组织] B --> C[需求优先级排序] C --> D[需求一致性检查] D --> E{是否通过检查} E -- 是 --> F[需求分析完成] E -- 否 --> B ``` ## 2. 软件架构概述 ### 2.1 软件架构的定义 软件架构传达了系统核心元素的概念，这些元素难以更改，是构建其他部分的基础。它是一组理念，能为程序选择合适的基础。软件架构的出现是为了应对程序规模和复杂性的增加。所有程序都有架构，对于大型程序，更需要精心考虑架构，因为程序编写完成后，架构层面的更改非常困难。 ### 2.2 软件设计的两个层次 软件设计有两个层次： - **详细设计**：编写程序时通常考虑的层面，涉及具体的操作、数据结构、算法、数据库组织、用户界面和调用序列等详细问题，这些问题需要在编码前解决。 - **架构设计**：侧重于风格，类似于建造房屋时考虑的风格问题，如选择牧场式还是多层式、都铎式还是科德角式等。它关注的是程序的整体风格和使用方式，而非具体的技术细节。 ### 2.3 常见的软件架构模式 软件架构有多种风格，不同类型的程序会采用不同的架构模式。以下介绍几种常见的架构模式： | 架构模式 | 特点 | 适用场景 | | ---- | ---- | ---- | | 主程序 - 子程序架构模式 | 源于Niklaus Wirth的自顶向下问题分解方法，将大问题分解为多个较小的、半独立的子问题，从顶向下解决问题，从底向上编写代码 | 适用于可通过自顶向下分解解决的问题 | | 管道 - 过滤器架构 | 计算组件为过滤器，输入和输出管道为导管，过滤器独立，可按不同顺序组合以获得不同结果