[I.1] 个人作业：阅读和提问

[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2025 年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习并掌握软件工程的基本原理和实践方法，提高软件开发和管理的能力。
这个作业在哪个具体方面帮助我实现目标	通过阅读教材和提出问题，深入理解软件工程中的关键概念和挑战，培养批判性思维和解决问题的能力。

问题 1 软件需求"数学化"是否实际可行及其适用范围

第 1 章关于需求推导强调通过数学方式从实际工作中提炼需求，例如用数学公式表达用户输入与输出的映射关系。但第 5 章分析需求扩展时提到"复杂度往往超过数学公式表达能力"，例如动态显示排序过程或支持国际化多语言界面时难以完全量化。需求的非线性特征会导致数学建模成本过高。

我的困惑在于教材未明确界定数学化方法的适用范围——是否仅适合低风险核心功能（如课上讲的四则运算题生成）而不足覆盖复杂业务逻辑？实践中开发图书馆管理系统时常遇到动态权限分配或并发访问问题，这些无法单纯依靠数学推导解决，但教材未能提供数学化与工程经验结合的指导框架。

问题 2 类似"画扇面"故事的思维误区如何通过需求管理策略有效避免？

书中第三章"软件工程师的思维误区"通过"画扇面"的相声类比，描述了软件开发中常见的需求蔓延和功能膨胀问题。乙因追求技术复杂度而无节制地扩展项目功能，导致最终交付物与原始需求完全背离。例如，从"美女图"强行改动为"张飞"甚至"山水画"，类似于团队因追求功能覆盖范围的扩张而脱离用户核心价值。参考章节提到学生项目往往陷入"从头开发的 1.0 版本"陷阱，用全局变量和公有函数草草应付需求，而真正的工程实践需要应对变化的需求与历史代码的演进。

我的困惑是，具体需求管理方法如何在实际项目中防止此类问题？例如，如何在团队初期确立需求边界？是否存在类似于敏捷开发中"用户故事优先级划分"或"MVP（最小可行产品）验证"的工具？书中提到的"版本控制复用前人代码"和"模拟人员变动以强化协作"是否足以应对此类需求失控？若实践中仅依赖项目检查点和截止期限，是否会因被动"赶工"而被迫牺牲需求合理性？

问题 3 用户故事碎片化与系统需求完整性矛盾如何调和

书中第 6 章敏捷流程 提出用户故事应替代传统产品需求文档，主张以卡片式描述具体场景（As a...I want...）。然而在涉及大型复杂系统时，多维度产品需求文档（PRD）通常包含系统边界、业务流程模型等全局性描述。
现实中金融机构核心系统升级项目需要同时满足大量内部合规条款，若仅通过用户故事拼接需求，是否会遗漏法规约束与架构耦合性等隐蔽需求？这是否意味着用户故事更擅长增量型功能开发，而在重构既有系统工程时暴露出全局视角缺失的短板？

问题 4 MVP 原型的量化评估

书中第五章提到 MVP 核心是"用最小成本实现最核心功能"，但实际操作中如何界定"核心功能"的优先级与"最小成本"的边界？
例如在社交网站案例中，「VIP 链接点击量太小就放弃该功能」看似清晰，但若涉及复杂场景（如医疗系统 MVP 原型需满足基本诊断功能），是否存在通用评估框架或指标（用户行为数据/商业价值评分）来区分必要功能与过度设计？作者建议通过快速迭代收集反馈，但未说明当技术实现复杂度与用户需求权重产生冲突时（例如核心功能需要高投入的基础架构改造），应优先遵循用户数据还是架构可持续性，书中是否有成功案例说明这种权衡机制？

问题 5 场景驱动型测试能否覆盖动态交互中的涌现性缺陷

书中第十三章详述了测试用例设计需覆盖边界条件与异常场景，同时强调测试人员代码质量的重要性以避免防线漏洞。
最近恰好读了一篇关于代码调试的文章，I do not use a debugger – Daniel Lemire's blog, 给出了观点"测试优于调试", 也证明测试驱动开发 (TDD) 具备质量保障优势。

第十三章还强调场景测试需模拟用户整体功能使用模式，并通过探索式测试验证现有测试用例的完备性。然而在复杂集成系统中，模块间异步交互可能触发预期外的状态时序矛盾（并发冲突）。书中提及通过边界值分析构建确定性测试方法，但当系统涌现出模块单独测试时均合规的级联故障时，纯测试优先策略是否受限于预设场景的路径枚举能力？