Systems analysis in IT — IT系统分析

From Systems analysis wiki
Jump to navigation Jump to search

IT系统分析（Systems Analysis and Design）是一种从概念到运营设计和开发信息系统的方法，包括需求识别、需求规范化、领域与流程建模，以及方案与风险评估。换言之，IT系统分析是开发过程中的一个阶段，专家在此阶段研究任务，确定系统应具备的功能，并制定创建系统的解决方案。

经典系统分析涵盖了广泛的应用领域，不仅限于软件开发，还包括组织变革、战略制定及其他方面。[1] [2]

IT系统分析的对象与任务

IT系统分析的对象是信息系统（软件产品和/或服务）的整个生命周期——从概念和论证到实现和运营。

系统分析的任务是将业务需求转化为一套一致且可验证的需求和架构解决方案：识别并记录利益相关者的目标和限制，规范化需求，为领域和流程建模，评估备选方案的可行性和风险，并为所选架构提供论证。其结果是创建一致的文档，并在需求、设计决策和测试之间建立可追溯的联系。这确保了开发过程的可管理性和可控性。

系统分析的任务包括：

  • 识别利益相关者的需求和目标。分析师收集并澄清客户、用户及其他相关方的期望；采用访谈、问卷调查、观察和现有流程分析等方法。最终产出是初步的需求规格说明书，其中功能性需求（“系统应该做什么”）与非功能性需求（可靠性、性能、安全性等）分开。[1][2]
  • 需求的规范化与文档化。将请求转化为可验证的需求。一个明确表述的需求应清晰无歧义、完整、无矛盾、可验证，并可追溯至更高层次的目标；整套需求应协调一致且完整。[3][4] 实践中使用的标准化文档有：遵循ISO/IEC/IEEE 29148标准的SRS（软件需求说明书），以及在特定行业中使用的URS（用户需求说明书）和功能规格说明书。[5][6][7]
  • 系统分析与建模。为理解系统将如何工作并与外部世界交互，需要构建模型：用于使用场景的用例图（Use Case）、用于数据流和业务流程的DFD、类图/组件图等。这些模型是比较备选解决方案和架构的基础。[8][9][10]
  • 可行性评估与解决方案选择。进行可行性研究（技术、组织、经济、进度可行性）并比较架构备选方案（权衡）。为根据属性（如性能、可扩展性、可修改性）评估架构质量，可采用ATAM（架构权衡分析方法）等方法。[11][12] 例如，在单体架构和微服务架构之间的选择[3]依赖于明确的权衡（运维复杂性 vs. 独立扩展性和交付速度），并遵循行业指南的建议。[13][14]
  • 准备项目交付成果。分析结束后，形成以下成果：
    • 经批准的需求规格说明书（注明其重要性），
    • 系统的概念模型（图表/描述），
    • 架构和设计决策（数据模式、外部系统接口），
    • 实施计划（阶段/模块）。
    • 确保需求到设计元素和测试的可追溯性（双向可追溯性）至关重要。[15][4]

IT项目的成功在很大程度上取决于成熟的需求和架构工作实践。麦肯锡和牛津大学的一项研究表明，大型IT项目经常超出预算和时间表。该研究还强调了正确管理战略、与利益相关者互动以及熟练收集需求的重要性。所有这些都可能对项目的成败产生重大影响。[16]

IT系统分析中的方法与方法论

IT系统分析基于系统思维原则和为软件开发调整的方法。实践中，通常结合“硬”与“软”方法、结构化方法论、面向对象的表示法，以及流程和需求建模语言。

  • 硬方法与软方法。在IT项目中，硬方法（hard systems）假定目标和需求可以预先规范化，并进行自上而下的分解和设计。软方法（soft systems）则用于目标不明确且存在多种视角的情况：使用软系统方法论 (SSM)的元素（如富图片、根定义、CATWOE）来协调对问题和期望变化的理解；然后将结果转化为正式需求。[17][18]
  • SSM（软系统方法论）。SSM最初由彼得·切克兰德为组织变革而开发，在IT项目的预备阶段非常有用：从研究问题情境、形成根定义（包括通过CATWOE）到将概念模型与现实进行比较，并最终在利益相关者之间达成调和。[19][20]
  • 结构化方法论：SADT/IDEF0。SADT将系统建模为功能的层次结构；标准表示法IDEF0（IEEE 1320.1）记录了功能及其I-C-O-M接口（输入、控制、输出、机制）。这种方法便于进行功能分解和协调系统边界，而无需考虑算法。[21][22]
  • 面向对象分析：UML与SysML（MBSE）。UML已成为需求和设计的基础语言（用例图、类图、序列图等），并有助于与用户验证场景；SysML扩展了UML，用于系统工程（需求图、参数图），并基于MBSE方法，其中模型是贯穿从需求到测试各阶段的核心交付成果。[23][24][25]
  • 业务流程建模：BPMN。BPMN标准用于图形化描述流程（池、工作流、事件、网关），包括在需求规格和集成中比较as-is/to-be（现状/目标）模型。[26][27]
  • 与需求工程的联系。该过程包括获取-分析-规范-验证-变更管理的阶段；“好需求”的标准和SRS的结构由ISO/IEC/IEEE 29148规定。优先级排序采用MoSCoW（必须有/应该有/可以有/不会有）技术和多标准决策方法，如AHP。在敏捷流程中，系统分析活动体现在待办事项列表的细化和需求的可追溯性上。[28][29][30][31]
  • 与系统工程的联系。对于复杂（信息物理）系统，采用V模型：在“左侧”分支进行系统分析和架构设计，在“右侧”分支进行集成、验证和确认，并与左侧分支的交付成果相关联。根据质量属性评估架构的方法包括ATAM（权衡分析）。[32][33]

IT系统分析结合了从软性愿景协调方法论到正式表示法和标准的各种经过验证的方法。工具的选择取决于任务的确定性程度：在高度不确定性下，SSM和引导（facilitation）的作用增强；在边界清晰的情况下，则更依赖于正式模型（UML/SysML, IDEF0, BPMN）和规范。

与IT架构和企业架构的联系

IT项目中的系统分析与架构设计密切相关。分析师和架构师的角色有重叠之处：分析师制定需求和逻辑模型，架构师确定解决方案的目标结构和技术权衡；他们的工作是协同进行的。

  • IT系统架构。狭义上，软件架构是指组件的组织、它们之间的关系以及指导解决方案设计的原则。分析师必须考虑架构风格（分层、客户端-服务器、微服务、事件驱动等），因为非功能性需求（可靠性、可扩展性、可修改性）常常决定了架构决策及其权衡。[34][35] 在分析的早期阶段，会形成架构愿景（高层愿景）并制定解决方案的初步轮廓，以验证需求的可行性（迭代长度和详细程度取决于方法论）。[36]
  • 模式与初步决策。为满足非功能性需求，会采用架构模式。例如，对于异步交互和松耦合，可在事件驱动架构中使用基于消息代理的发布-订阅模式。[37]
  • TOGAF (The Open Group Architecture Framework)。这是最常见的企业架构框架之一；它包括ADM（架构开发方法）和架构管理交付成果（存储库、目录/矩阵、原则）。在TOGAF中，需求管理是一个贯穿ADM所有阶段的流程。[36] 为支持需求和可追溯性，使用了目录和矩阵（例如，需求↔服务、功能↔组件），并区分了架构构建块和解决方案构建块。[38][39] 企业的原则和标准记录在相应的目录中，并作为项目团队的外部非功能性需求。[40] 解决方案与目标架构的一致性通过架构合规性审查程序来确认。[41] TOGAF方法假定先有架构愿景，随后进行详细设计（数据/应用/技术），并制定迁移计划和需求变更管理。[42][43]
  • Zachman框架。这是早期且有影响力的企业架构交付成果本体论，以6×6矩阵（视角×方面“什么/如何/何处/谁/何时/为何”）的形式呈现。“设计师”行与系统分析和设计相关；各列则规定了对数据、功能/流程、角色、位置和动机的完整性审视。该框架作为一种分类法（而非方法论），有助于确保在企业环境中对解决方案的描述是完整的。[44]
  • 与企业架构（Enterprise Architecture, EA）的联系。系统分析师在EA的背景下工作：新需求需追溯到业务能力和运营模型；应用企业的标准和原则性限制（安全性、兼容性等）。[45][36] 在启动阶段，形成架构愿景（目标/限制、高层需求），然后分析师进行详细设计，同时保持与愿景和公司标准的可追溯性；不符合标准的情况会在架构审查中被发现，并可能导致解决方案的修改。[36][46]

总之：系统分析和架构设计构成了“需求→架构决策→质量属性权衡”的链条。方法的选择（风格/模式、TOGAF交付成果、Zachman分类法）取决于项目性质和企业架构的框架。

流程与实践

系统分析贯穿于软件开发和运营的整个生命周期，连接着业务目标、架构和交付。它包括项目前期研究、方法选择、可验证交付成果的形成，以及对可靠性、性能、安全性和可维护性的要求。在瀑布模型中，分析在设计和实现之前完成；在敏捷方法中，通过迭代持续进行；而在DevOps中，则侧重于运营目标。无论采用何种方法，分析都确保了可追溯性、变更和风险管理、架构权衡的记录以及法规限制的遵守，从而使开发过程可预测和可管理。

  • 经典SDLC（瀑布模型）。系统分析与需求定义阶段先于设计和实现；需求被固定在详细的SRS中，作为规划和合同的基础。这种方法在稳定和受监管的领域中很有效；“冻结”需求的风险通过SRR/评审和通过CCB进行变更管理来降低。[47][48][49]
  • 敏捷方法论 (Agile)。分析是持续进行的：用包含用户故事和验收标准的产品待办事项列表代替最终的SRS，并在待办事项列表细化会议上进行 уточнение；采用BDD（Given–When–Then）；通过早期架构设计和需求↔实现/测试的透明可追溯性来弥补失去整体架构的风险。[50][51][52]
  • DevOps与SRE。频繁的发布要求“默认”的运营需求：自动化、可观察性、回滚。非功能性需求以SLO/SLI的形式制定，并管理错误预算；待办事项列表中添加了日志/指标/追踪/警报的任务；为实现零停机发布，采用蓝/绿部署等模式。[53][54][55]
  • 需求与风险管理。在ALM中，需求具有状态并与任务/发布/缺陷相关联；版本控制、变更影响分析和定期的优先级重排是强制性的。[56][57]
  • 质量保证 (QA)。质量在需求阶段就已奠定：评审、“三剑客”会议、验收测试计划、验收标准的自动化测试（BDD/ATDD）。[58][59]
  • 可观察性与可靠性。需求中包括SLA/SLO、MTTR和MTBF，并带有可衡量的目标和控制方法；这些参数来自业务/运营，并被纳入架构和可靠性测试中。[60][61]

指标与交付成果质量

为评估系统分析师的工作及其成果的质量，采用了公认的标准。高质量的需求和模型是项目成功的基础，因此在整个生命周期中（获取→规范→验证/确认→变更管理）对其进行管理。需求的基本质量属性在ISO/IEC/IEEE 29148标准和（历史上的）IEEE 830标准中有所规定。[3][62][1]

  • 正确性 (Correctness) — 需求反映了真实的需要，并与领域专家达成一致；通过验证（评审/检查、原型、场景）来确认。[1][4]
  • 完整性 (Completeness) — 考虑了重要的方面和条件。
    • 单个需求的完整性：指明了必要的细节（例如，“当发生故障时，指示灯变为红色”，而不仅仅是“变为红色”）。
    • 规格说明书的完整性：涵盖了各种场景/角色，定义了NFR；通过检查清单和与业务目标的可追溯性来实现；独立的完整性审计（QA/评审）也很有用。[3][63]
  • 无歧义性 (Unambiguity) — 表述只有一种解释方式；使用术语表、形如“当B发生时，如果C成立，系统必须做A”的模板和示例；图表应附有图例。通过“四只眼”原则进行检查。[3][1]
  • 一致性 (Consistency) — 需求之间不相互矛盾，也不与外部限制冲突；采用结构化、属性汇总表、团队评审；核对法规/标准。[3][63]
  • 可验证性/可测试性 (Verifiability) — 实现情况可通过测试/演示/分析来确认；不可验证的表述应替换为可衡量的标准；为NFR定义指标并预先确定验收标准。[3][63]
  • 可修改性与可追溯性 (Modifiability & Traceability) — 唯一的ID，逻辑结构清晰（“一个段落一个思想”），无重复；维护“需求↔来源/目标/设计/测试”的联系，并维护可追溯性矩阵（RTM）。[64][3]
  • 排序与优先级 — 需求集的质量；使用MoSCoW技术和MCDM（例如AHP）；与业务方共同确定优先级会影响规划和风险。[65][66]

需求质量指标（示例）：[63][1]

  • 需求缺陷密度（每100个需求的意见数）；
  • 基线确定后的变更数量；
  • 覆盖率指标：有测试用例的需求比例；可追溯至业务目标的需求比例；
  • 需求稳定性（某时期内新增/删除的需求与总数的比率）；
  • 规格说明书的规模/复杂性（每个用例的平均需求数，分解深度）；
  • 利益相关者满意度（问卷调查）。

在成熟的流程中（例如CMMI 3级以上），有需求质量的规定：正式检查、模板符合性审计、指标收集/分析。[67] 在关键领域（航空、航天等），采用形式化方法来提高可靠性。[68]

典型错误

在IT项目中，系统分析的错误很常见：需求不完整和不明确、矛盾、边界模糊、忽略非功能性方面、集成遗漏和安全措施滞后。这会导致返工、延期、成本增加和缺陷。

典型问题、其后果及预防方法：

  • 不完整和遗漏的需求。忽略了有特殊权限的角色、边界情况和NFR。后果：架构重构和发布推迟。如何避免：使用检查清单、进行“如果…会怎样”的头脑风暴、尽早让测试人员参与、与业务目标保持可追溯性。[1][69]
  • 不清晰、模棱两可的表述。后果：开发人员实现了“错误”的功能，客户不满意。如何避免：使用可衡量的标准、术语表、形如“当B发生时，如果C成立，则A”的模板、同行评审。[3][69]
  • 相互矛盾的需求。后果：澄清需求导致延期，集成时需要返工。如何避免：结构化、核对业务规则/法规、召开冲突解决会议、在评审中检查一致性。[3][1]
  • “镀金”综合症 (gold‑plating)。后果：范围扩大、复杂性增加、出现新的故障点。如何避免：将每个需求与目标/指标挂钩；在敏捷中，不在待办事项列表中包含多余项；固定范围；参见YAGNI。
  • 在不必要的地方过度细化。如何避免：将什么/为什么（需求）与如何（设计/实现）分开；在适当的地方使用与设计无关的需求。[3]
  • 需求管理失控。后果：版本混乱，实现了“错误”的东西。如何避免：在ALM中使用单一事实来源、历史记录和状态管理、RTM和变更影响分析；通过CCB进行变更管理。[64][1]
  • 用户参与不足。如何避免：访谈、观察、原型、定期演示；与利益相关者进行明确的验证。[3][1]
  • 过长的“分析瘫痪”。如何避免：确定“足够好”的范围、迭代和时间盒；启动MVP/增量，并根据反馈进行调整。[1]
  • 忽略非功能性需求。如何避免：明确NFR（例如，FURPS+），设定可衡量的标准，将其纳入测试计划和架构决策。[1][3]
  • 沟通错误和“人为因素”。如何解决：发展访谈和引导技巧，保持中立，记录决策和需求来源（与目标的可追溯性）。[1]

大多数问题都归结为表述质量、完整性和需求的可管理性；应用ISO/IEC/IEEE 29148标准和SWEBOK实践（可验证性、可追溯性、迭代性）可显著降低延期和返工的风险。[3][1]

局限性

尽管系统分析在降低不确定性方面非常有效，但它也有其局限性：

  • 现实是多变且复杂的。不可能考虑到所有因素，尤其是在长期项目中。一些需求不可避免地会在系统启动后才出现。重要的是尽量减少意外，但也要准备好应对变化。
  • 需求依赖于人。业务优先级、法律和市场都可能发生变化。系统分析记录的是当前状态，无法预测所有外部变化。为了适应，需要定期更新需求并采用迭代工作方式。
  • 用户在看到之前，并不总是知道自己想要什么。这是一个众所周知的局限性。原型设计和敏捷等灵活方法有助于克服这个问题。纸上谈兵有其局限性，需要通过实际实现来获得准确的反馈。
  • 时间与质量的平衡。过于详细的分析可能会过时。在创新领域，最好快速创建一个最小可行产品（MVP）并获取真实数据。系统分析在稳定领域很有效，但在研发（R&D）项目中其作用有限。
  • 人为因素。即使是最好的方法论也无法弥补分析师能力不足或客户不可及的问题。重要的是所有参与者都应投入并有积极性。

现代技术对IT系统分析的影响

IT系统分析在技术创新的影响下不断演进。21世纪的分析师在数据爆炸式增长、AI普遍应用、快速开发周期和对安全日益关注的环境中工作。成功的系统分析实践要求掌握新知识（数据科学、网络安全、云技术）并灵活运用各种方法。

  • 数据与AI/ML：分析中新增的内容。对于包含AI的系统，在项目开始时就需确定其应用目标和背景，对数据来源和质量的要求，以及对模型决策的信任度指标（可靠性、安全性、可解释性、保密性、公平性）。需要规划TEVV（测试、评估、验证、确认），运营中的监控，以及模型的安全停用/下线。这些步骤对应于NIST AI风险管理框架中的治理-映射-测量-管理功能；它们反映在SRS、架构以及验证/运营计划中。[70]
  • DevSecOps：安全“左移”与默认安全。将安全嵌入到CI/CD的每个阶段已成为常态：自动化检查（SAST/DAST）、依赖项和容器扫描、部署策略、基础的可观察性。使用可信的构件库和标准化的“加固”镜像；应用零信任原则。在系统分析中，需要预先描述流水线控制点（通过各阶段的条件）、需求与安全控制的联系，以及环境间（dev/test/stage/prod）的转换规则。[71]
  • 文档（交付成果）的变化。在涉及大数据和AI/ML以及采用DevSecOps工作方式时，关键文档中会出现或需要详细说明哪些部分：
    • SRS / 需求规格说明书：AI的应用目标和背景；数据要求（来源、质量、伦理和法律限制）；模型指标（准确性、可靠性、响应时间）；TEVV（测试、评估、验证、确认）计划；透明度/可解释性和隐私要求；模型停用/下线标准。[70]
    • 架构与决策（Architecture, ADR）：威胁建模结果；“默认安全”措施（加密、访问控制、密钥管理、最小权限原则）；数据/模型使用限制；评估风险和权衡的ADR记录。[71][70]
    • 验证与确认计划（V&V / TEVV）：模型和数据的测试场景；质量指标的验收阈值；数据/模型漂移监控；定期重新评估和再次验证的程序。[70]
    • CI/CD策略与流水线“门禁”：自动化的SAST/DAST、SCA（依赖项）、容器扫描检查；在可信库中对构件进行签名和存储；环境间（dev/test/stage/prod）的晋升规则以及检查失败时阻止构建的条件；默认的可观察性要求。[71]
    • 数据与模型管理计划：数据源目录和血缘关系；数据质量和可用性标准；数据集/模型版本；（再）训练计划和偏差控制；访问和存储策略；必要时安全停用模型和删除数据的计划。[70]
    • 运营与可观察性（Ops/Runbook）：AI信任度指标和SLO；审计和日志记录；性能退化/异常警报；事件响应计划；AI组件的回退/紧急停止开关；报告和事后分析要求。[70][71]
    • 可追溯性（端到端）：明确的“需求↔流水线中的控制/检查”和“需求↔运营中的测试/监控”联系，以便在整个生命周期中可验证地检查安全性和质量。[71][70]
  • 系统分析师的角色。
    • 管理AI的背景和风险（参与者、应用场景、数据假设和限制）；
    • 确保“需求↔流水线中的安全控制”的可追溯性；
    • 在系统的整个生命周期中，制定可验证的非功能性需求（安全性、透明度、可观察性）。[70][71]

与经典系统分析的区别

“系统分析”一词在历史上比软件开发更广泛。经典系统分析是解决复杂跨学科问题（社会、经济、管理）的一种方法，基于系统思维和定量方法，通常用于支持管理决策。在IT领域，系统分析则指软件工程中的一门应用学科，专注于创建信息系统。

以下是关键区别：

  • 目标与分析对象。经典分析解决的是结构不良、“模糊”的问题，并改进现有的社会技术系统（城市交通网络、公司战略、环境政策）。其对象是现实系统；任务是帮助决策者选择行动方案。对于IT系统分析，目标是设计和创建一个满足需求的新信息系统或软件产品。其对象是待设计的系统；重点是用户所需的行为和特性。
  • 方法论基础。经典学派依赖于系统思维，并常常与数学相结合。硬方法（hard systems）——问题形式化、量化标准、优化（如在运筹学中）。软方法（soft systems）承认多重观点；例如软系统方法论 (SSM)，通过讨论和概念模型来协调期望的变革。在IT领域，基础是工程学科：需求工程、软件设计、架构框架。采用标准化的流程（ISO/IEC/IEEE 15288, 12207, 29148）、UML/SysML表示法和变更管理实践。
  • 角色与交付成果。在经典分析中，“系统分析师”的角色通常是非正式的；成果是分析报告、建议、数学模型、“如果-那么”情景。在IT领域，分析师（或业务分析师）的角色是正式化的；产出的是需求规格说明书、系统模型（UML, ER）、接口规范、用户故事和待办事项列表——这些是开发人员和测试人员直接使用的交付成果。
  • 生命周期与过程。经典分析没有统一的模式：步骤取决于问题（在SSM中，从研究情况到实施变革）。IT领域采用标准的SDLC周期：在瀑布模型中，有独立的需求分析阶段；在迭代和敏捷方法中，分析是每个冲刺的持续活动。现代实践（DevOps, CI/CD）将分析的范围扩展到运营：考虑了维护、可观察性和可更新性的要求。换言之，IT系统分析嵌入在开发生命周期中，而经典分析更多地作为项目/咨询活动来执行。

系统分析师

IT系统分析师是在信息系统设计和开发中负责运用系统思维的专家：形成和验证需求、建模（UML/BPMN）、协调架构决策并确保集成。该角色和资格要求在俄罗斯联邦的专业标准和联邦国家教育标准中有所规定。

该职业活动的主要目标：通过在系统的整个生命周期中制定并向相关方交付高质量且相互关联的设计方案，并协调各执行者的工作，确保IT服务、自动化系统、自动化信息系统、自动化管理系统、软件、信息产品或工具（以下简称“系统”）与环境、初始要求和限制、自动化目标及自动化活动相符（《系统分析师》专业标准（俄罗斯联邦劳动部2023年4月27日第367н号令））。[72]

关键术语表

基本概念与参与者

  • IT系统分析 — 一门学科，其研究对象是信息系统从概念到运营的整个生命周期。
  • 利益相关者 — 对项目感兴趣或受其影响的个人或团体（客户、用户、管理人员）。
  • 项目交付成果 — 在项目过程中创建的文档和结果，如规格说明书、模型、计划和决策。

需求：类型与文档

  • 功能性需求 — 描述系统应该做什么；其功能和行为。
  • 非功能性需求 — 描述系统的质量属性（可靠性、性能、安全性、易用性、可扩展性等）。
  • 需求规格说明书（初步）— 包含项目初期收集的初始需求集的文档。
  • SRS (Software Requirements Specification) — 按照国际标准（如ISO/IEC/IEEE 29148）详细描述软件需求的标准化文档。
  • URS (User Requirements Specification) — 从业务流程和最终用户期望的角度描述用户对系统需求的文档。
  • 架构显著需求 (ASR) — 对架构决策和权衡有重大影响的需求。
  • 跨功能需求 (CFR) — 非功能性需求的同义词，强调其贯穿整个系统的特性。
  • 验收标准 (Acceptance Criteria) — 可验证的条件，满足这些条件即认为需求相关的工作已完成。
  • 就绪定义 (Definition of Ready, DoR) — 关于待办事项列表中的某个条目是否已准备好进入开发的协议（清晰度、估算、标准）。
  • 完成定义 (Definition of Done, DoD) — 关于工作“完成”的协议（代码、测试、文档、部署）。
  • 约束 (Constraint) — 限制解决方案的硬性条件（时间、平台、标准、许可证）。
  • 假设 (Assumption) — 未经证实即接受的假定，需要后续验证。
  • 需求质量 — 根据ISO 29148的属性：无歧义性、完整性、一致性、可验证性、原子性。

需求的规范化、可追溯性与优先级排序

  • 需求规范化 — 将非正式请求转化为清晰、可验证且无歧义需求的过程。
  • 需求可追溯性 — 追踪需求从其来源到实现、测试和部署的整个生命周期的能力。
  • 双向可追溯性 (Bidirectional traceability) — 能够正向和反向追踪需求、设计元素和测试场景之间联系的能力。
  • MoSCoW — 一种需求优先级排序技术，将需求分为必须有 (Must-have)、应该有 (Should-have)、可以有 (Could-have) 和不会有 (Won't-have)。
  • BDD (Behavior-Driven Development) — 一种开发方法论，其中测试用例以用户视角的系统行为为导向，使用自然语言编写（Given–When–Then 格式）。

表示法与建模

  • UML (Unified Modeling Language) — 一种标准化的图形建模语言，用于软件系统组件的规约、可视化、构建和文档化。
  • SysML (Systems Modeling Language) — UML的扩展，用于系统工程，支持对复杂系统多个方面（包括需求、行为、结构和参数）的建模。
  • BPMN (Business Process Model and Notation) — 一种用于描述业务流程的图形表示法标准，能够可视化工作流、事件、网关和池。
  • MBSE (Model-Based Systems Engineering) — 一种系统工程方法，其中模型是系统生命周期所有阶段（从需求到测试）的核心交付成果。
  • ArchiMate — 一种企业架构（业务、应用、技术）及其关系的表示法。
  • DMN (Decision Model and Notation) — 用于建模业务决策和规则表。
  • DFD (Data Flow Diagram) — 数据流图（上下文、分解层次）。
  • ERD (Entity-Relationship Diagram) — 包含实体、关系和属性的领域模型。
  • CRUD矩阵 — 创建/读取/更新/删除操作与实体和角色/功能之间的对应关系。

架构风格与方案评估

  • 单体架构 — 一种架构方法，将整个系统作为单一、不可分割的模块进行开发。
  • 微服务架构 — 一种架构方法，将系统构建为一组小型的、可独立部署和扩展的服务。
  • 权衡 (Trade-off) — 在互斥或矛盾的特性或决策之间进行选择，其中改进一个特性会以牺牲另一个特性为代价。
  • ATAM (Architecture Tradeoff Analysis Method) — 一种评估软件架构的方法，用于分析质量属性（如性能、可扩展性）之间的权衡。

企业架构与框架

  • TOGAF (The Open Group Architecture Framework) — 最常见的企业架构框架之一，包括用于开发和管理架构的ADM（架构开发方法）。
  • Zachman框架 — 一种企业架构交付成果的本体论，以6×6矩阵的形式呈现，从不同视角对架构的各个方面进行分类。

分析方法与开发流程

  • 硬方法 (Hard Systems) — 一种系统分析方法论，假定目标和需求可以预先规范化，并采用自上而下的分解和设计，适用于明确定义的任务。
  • 软方法 (Soft Systems) — 一种系统分析方法论，用于目标不明确且利益相关者观点多样的情景，旨在协调对问题和期望变化的理解。
  • SSM (Soft Systems Methodology) — 由彼得·切克兰德开发的具体软系统方法，使用富图片、根定义和CATWOE等工具。
  • 瀑布模型 (Waterfall) — 经典的软件开发方法论，其中各阶段（分析、设计、实现、测试、部署）按顺序执行，前一阶段完全结束后才开始下一阶段。
  • 敏捷 (Agile) — 一组灵活的软件开发方法论，侧重于迭代开发、适应变化、与客户协作以及持续交付价值。

选择方法与典型错误

  • AHP (Analytic Hierarchy Process) — 一种多标准决策方法，允许将复杂问题结构化，并基于标准层次结构评估备选方案。
  • 镀金 (Gold-plating) — 系统分析中的一种错误，即添加了利益相关者不需要的功能，导致项目范围和复杂性增加。

链接

参考文献

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5-е изд.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. 官方免费版.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. 官方免费下载（需授权）.
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4-е изд.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3-е изд.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2-е изд.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5-е изд.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3-е изд.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4-е изд.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11-е изд.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8-е изд.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7-е изд.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3-е изд.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2-е изд.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4-е изд.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4-е изд.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2-е изд.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

注释

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. 定义“well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable”。 https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (提及URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — 对架构描述和视点的要求。 https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (综述). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (规范). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (将EA定义为“业务流程和IT能力的组织逻辑……”). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. 重印版 (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (历史标准). 学习副本 (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (关于需求/可追溯性的典型问题). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ 《系统分析师》专业标准（俄罗斯联邦劳动部2023年4月27日第367н号令）.
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systems_analysis_in_IT_—_IT系统分析&oldid=9495"