随笔分类 - 读书笔记
摘要：目录一、这一章节在讲什么问题二、核心观点总结（一句话版）三、关键思想拆解（读书笔记要点）1️⃣ 高层表达是为了“隐藏不必要的细节”2️⃣ 自顶向下设计为什么能减少 bug（四个层面）（1）结构清晰 → 需求和职责更准确（2）模块划分 + 独立性 → 避免系统级 bug（3）细节隐藏 → 更容易发现结
阅读全文
摘要：目录《人月神话》：计算机产品文档的核心要素（读书笔记）一、文档的本质定位二、计算机产品文档应包含的关键内容1. 目标（Objectives / Goals）2. 预算（Budget）3. 进度计划（Schedule）4. 功能说明（Functionality）5. 设计约束（Constraints）
阅读全文
摘要：目录估算时必须首先区分“你在估什么样的任务”。2️⃣ “三倍”不是常数，而是“数量级警告” 估算时必须首先区分“你在估什么样的任务”。 生产率会根据任务本身复杂度和困难程度表现出 显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的 三倍，操作系统复杂度是编译器的三倍 “
阅读全文
摘要：目录《人月神话》读书笔记 – 概念完整性1️⃣ 核心概念2️⃣ 为什么重要3️⃣ 实现方法(1) 核心设计者主导(2) 集中控制架构(3) 统一设计原则(4) 原型驱动迭代(5) 控制设计者数量4️⃣ 图示化关系（逻辑梳理） 好的，我帮你把《人月神话》中概念完整性部分整理成一页精华读书笔记格式，图示
阅读全文
摘要：目录项目前期在特定情况下有效，在项目中后期一定无效。一、什么是“项目前期”（Brooks 语境下的定义）项目前期的定义项目前期的典型特征为什么项目前期“加人”可能有效二、什么是“项目中后期”（Brooks 语境下的定义）项目中后期的定义三、为什么项目中后期“加人”是无效甚至有害的1. 新人引入培训成
阅读全文
摘要：目录一、乐观主义（The Optimism）核心观点Brooks 的判断现实问题Brooks 的结论二、人月（The Mythical Man-Month）核心观点为什么“加人反而更慢”2️⃣ 沟通成本指数级增长三、系统测试（System Testing）核心观点Brooks 的关键论断系统测试为何
阅读全文
摘要：目录 大型编程项目碰到的管理问题和小项目区别很大 过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧 烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了 目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个 淹没在了焦
阅读全文
摘要：目录一句话结论（先给结论）一、在需求说明书（PRD / BRD）中，接口设计“应该出现到什么程度”✅ 应该包含（产品经理职责）1️⃣ 系统间的交互关系2️⃣ 业务语义层面的接口契约（Business Contract）3️⃣ 业务边界与职责归属（非常重要）4️⃣ SLA / 非功能性要求（业务视角）
阅读全文
摘要：目录一、这一章的核心结论（一句话）二、为什么“聆听”是难点（作者反复强调的误区）1️⃣ 客户说的 ≠ 客户要的2️⃣ 需求沟通中的“三层失真”三、正确“聆听需求”的 5 个关键原则（重点）原则 1：先理解业务目标，不要急着讨论功能原则 2：区分「需求」与「想法 / 解法」原则 3：用复述确认，而不是
阅读全文
摘要：目录其他 访问并与有潜力的用户探讨 为找出新软件产品的用户需求，最直截了当的方法是询问他们。本章讨论如何寻找合适 的用户代表，而在第8章讲述从这些代表中获取需求的技巧。 把对目前的或竞争产品的描述写成文档 文档可以描述一种所必须遵循的标准或产品所必须遵循的政府或工业规则。 系统需求规格说明 一个包含
阅读全文
摘要：目录一、项目视图（Project Vision）是什么二、项目视图解决的问题三、如何定义项目视图（《软件需求》标准方法）1. 业务背景（Business Background）2. 商业目标（Business Objectives）3. 主要用户和利益相关者（Users & Stakeholders
阅读全文
摘要：目录软件项目风险分类总表风险条目跟踪模板制定风险管理计划化学制品跟踪系统的风险条目样例需求风险与对应解决策略（简化版） 下面提供一份 全面、结构化的软件项目风险分类表，覆盖技术、需求、进度、质量、组织、供应链、安全、合规等主流维度，可直接用于项目管理、风险登记册或立项评审。 软件项目风险分类总表 风
阅读全文
摘要：目录1. “变更的影响是可以接受的。”理解方式典型实践2. “受到变更影响的所有人都接到通知并明白这一点。”理解方式典型实践3. “由合适的人选来作出接受变更的正式决定。”理解方式如果没有“正式决定”会发生什么？4. “资源按需进行调整。”理解方式5. “保持需求文档是最新版本并是准确的更新文档。”
阅读全文
摘要：目录背景和价值参考资料 背景和价值 将用户群分类并归纳各自特点 为避免出现疏忽某一用户群需求的情况，要将可能使 用产品的客户分成不同组别。他们可能在使用频率、使用特性、优先等级或熟练程度等方面 都有所差异。详细描述出它们的个性特点及任务状况，将有助于产品设计。 选择每类用户的产品代表 为每类用户至少
阅读全文
摘要：目录背景和价值一、为什么“只听业务部门”会导致需求失真？1. 业务部门 ≠ 最终用户2. 客户通常无法准确代表用户体验（尤其内部业务部门）3. 客户说的往往是解决方案，而不是需求二、中大型企业为何普遍忽略“用户需求采集”？1. 组织结构导致：2. 项目周期短，赶进度3. 企业文化问题三、如何解决？（
阅读全文
摘要：目录第一部分：优秀需求的 7 大特性检查清单（Checklist）1. 正确性（Correctness）检查清单2. 完整性（Completeness）检查清单3. 一致性（Consistency）检查清单4. 可验证性（Verifiability）检查清单5. 可追踪性（Traceability）
阅读全文
摘要：目录一、最核心的：什么是“概念”，什么是“需求”概念 / 方向（Concept）而需求（Requirement）必须满足三件事：1. 有清晰边界（Scope）2. 有可验证条件（Acceptance Criteria）3. 有系统间的规范定义（Contract）二、软件需求评估模型：你可以立刻掌握的
阅读全文
摘要：目录背景和价值每个项目都有需求参考资料 背景和价值 软件项目中百分之四十至百分之六十的问题都是在需求分析 阶段埋下的“祸根”（L e ffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不 合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得 到的软件
阅读全文
摘要：目录 在软件工程领域：一种需求分析框架 在软件需求分析中，SERU 是一种用于分解和组织需求的框架模型。 S：Subject Area（主题域）：指根据业务领域对系统进行划分，旨在保证各业务模块的独立性和低耦合性。 E：Event（业务事件）：指触发业务流程的事件，通过分析业务事件可以梳理
阅读全文
浙公网安备 33010602011771号