第二章 需求工程
第一节 需求获取方法
概述
需求获取是软件开发过程中的关键环节，直接决定了系统能否满足用户的实际需求。通过有效的需求获取方法，开发人员能够准确理解用户的期望和业务目标，从而制定合理的需求规格说明。本文将深入解析各种需求获取方法，帮助考生全面掌握需求获取的理论与实践技巧，为全国计算机等级考试三级软件开发实践科目打下坚实基础。
学习目标如下：
- 理解需求获取的定义和重要性
- 掌握主流的需求获取方法及其适用场景
- 分析需求获取过程中的关键技术与挑战
- 通过典型案例理解需求获取的实际应用
- 掌握常见误区及避免策略
核心概念
需求获取（Requirements Elicitation）
指通过各种技术手段和交流方式，从用户、业务环境和其他利益相关者收集系统需求的过程。
利益相关者（Stakeholders）
包括所有对系统有影响或受系统影响的人员或组织，如用户、客户、开发团队、管理者等。
需求规格说明书（SRS, Software Requirements Specification）
是一份详细描述系统需求的文档，是软件开发的基础。
需求分析（Requirements Analysis）
对获取的需求进行分类、整理、验证的过程，确保需求的完整性和一致性。
原理分析
需求获取的核心在于沟通与理解，它不仅是信息的收集，更是需求的澄清和确认。需求获取的有效性取决于：
- 利益相关者识别：全面识别所有相关方，避免遗漏关键信息源
- 沟通技巧：采用合适的技术（访谈、问卷、观察等）促进信息流动
- 需求确认：通过原型、文档审查消除歧义，确保双方达成共识
需求获取方法需要结合项目特点、时间成本、资源条件灵活选用，常见方法包括访谈、问卷调查、观察、头脑风暴、用例分析等。每种方法有其优势和局限，合理组合能够提升需求获取质量。
详细内容
1. 访谈法
访谈是需求获取中最常用且最直接的方法，通过与利益相关者一对一或小组形式的交流，深入了解用户需求和业务背景。
优点：
- 互动性强，能深入挖掘隐性需求
- 灵活调整问题，针对性强
缺点：
- 依赖访谈者的沟通技巧和经验
- 容易遗漏未表达或被忽视的需求
实施步骤：
- 明确访谈目标和主题
- 准备访谈提纲，设计开放式问题
- 选择合适的访谈对象，安排时间和地点
- 进行访谈，做好记录
- 分析访谈内容，提炼需求
注意事项：避免引导性问题，尊重受访者意见，确保信息保密。
2. 问卷调查法
问卷法通过设计结构化问题，向大量用户收集需求信息，适合需求范围广泛且用户较多的项目。
优点：
- 能快速覆盖大量用户
- 便于量化和统计分析
缺点：
- 缺少互动，难以获得详细解释
- 设计不当可能导致数据偏差
实施步骤：
- 明确调查目标，设计问卷内容
- 选择合适的调查对象和发放方式（纸质、电子）
- 收集和整理问卷数据
- 统计分析，形成需求结论
注意事项：问题应简明易懂，避免多重含义，问卷长度适中以提高响应率。
3. 观察法
观察法通过直接观察用户的实际操作和工作环境，了解真实的业务流程和潜在需求。
优点：
- 获取真实使用情况，减少用户主观偏差
- 发现隐含需求和流程瓶颈
缺点：
- 受观察者行为可能受影响（观察者效应）
- 需要较长时间和专业经验
实施步骤：
- 选定观察对象和场景
- 制定观察计划，准备记录工具
- 进行现场观察，记录关键行为
- 分析观察数据，提炼需求
注意事项：保持低干预，尊重用户隐私和工作节奏。
4. 头脑风暴法
头脑风暴法通过团队集思广益，激发创新思维，以产生大量需求想法。
优点：
- 促进多角度思考，发现创新需求
- 快速收集多样化信息
缺点：
- 可能产生大量无关或重复信息
- 需要良好的主持技巧以控制讨论
实施步骤：
- 确定讨论主题和目标
- 组建多元化团队，明确规则（无批评、鼓励发散）
- 记录所有意见
- 归纳整理，筛选有效需求
注意事项：避免讨论偏离主题，确保每位成员均有发言机会。
5. 用例分析法
用例分析通过描述系统与用户的交互过程，明确系统功能需求和用户需求。
优点：
- 结构化且易于理解
- 促进开发团队与用户的沟通
缺点：
- 主要关注功能需求，非功能需求涉及较少
- 需要用户具备一定的系统理解能力
实施步骤：
- 识别角色（用户或外部系统）
- 描述用例场景和步骤
- 确定正常流程及异常流程
- 评审用例，确认需求准确性
注意事项：注重用例的完整性和一致性，避免遗漏关键流程。
实例分析
案例一：企业内部管理系统需求获取
背景：某企业计划开发内部管理系统，涵盖人事、财务和项目管理。
分析：
- 采用访谈法与各部门主管深入交流，了解具体需求；
- 配合问卷调查收集员工对系统期望的反馈；
- 通过观察实际工作流程，发现手工操作环节较多，提出自动化需求。
结论：多种需求获取方法结合应用，确保需求全面且真实反映业务需求，为系统设计提供坚实基础。
案例二：移动应用开发中的需求获取
背景：某创业团队开发一款社交类移动应用。
分析：
- 采用头脑风暴法激发团队创新思路，产生多样化需求;
- 利用问卷调查收集潜在用户的功能偏好;
- 用例分析明确核心交互流程，保证功能实现符合用户预期。
结论：结合用户参与和团队创新，确保应用既满足市场需求又具有竞争力。
案例三：公共服务系统的需求获取
背景：政府部门开发公共服务门户网站。
分析：
- 对不同用户群体采用观察法，理解用户操作习惯；
- 与相关部门负责人访谈，明确政策和业务需求；
- 通过用例分析，设计用户访问和服务办理流程。
结论：需求获取注重多方利益相关者，保证系统符合政策和用户需求，提升公共服务效率。
常见误区
忽视利益相关者的全面识别
- 错误做法：只关注主要用户，忽略潜在影响者
- 正确做法：全面识别和沟通，确保需求完整
过度依赖单一需求获取方法
- 错误做法：仅用访谈或问卷，导致信息片面
- 正确做法：多方法结合，互补优势
未充分验证和确认需求
- 错误做法：收集后未反馈，导致误解和遗漏
- 正确做法：通过评审和原型等手段确认需求
缺乏有效沟通技巧
- 错误做法：提问含糊或引导，影响需求质量
- 正确做法：设计开放性问题，尊重用户表达
忽略非功能需求
- 错误做法：只关注功能，忽视性能、安全等需求
- 正确做法：全面收集功能与非功能需求
应用场景
- 企业信息系统开发：通过访谈和观察了解业务流程和用户需求
- 移动应用设计：结合头脑风暴和问卷调查，挖掘用户潜在需求
- 政府公共服务平台：多方访谈与用例分析，确保政策合规和用户友好
- 医疗信息系统：观察法结合专家访谈，保证系统安全和准确性
- 电商平台功能升级：利用问卷和用户反馈，精准定位改进需求
知识拓展
- 需求验证技术：如何通过原型设计、需求评审和测试用例确保需求正确性
- 敏捷需求获取方法：用户故事、持续反馈和迭代获取需求的新思路
- 需求优先级划分：方法和工具，确保有限资源优化配置
- 需求变更管理：追踪和控制需求变更，降低开发风险
- 需求建模工具：UML用例图、流程图和需求管理软件介绍
总结回顾
本节详细介绍了需求获取方法的理论基础和实用技术，涵盖访谈、问卷、观察、头脑风暴及用例分析五大主流方法。通过案例分析，展示了如何结合多种方法提高需求获取的准确性和完整性。同时，强调了识别利益相关者、有效沟通和需求确认的重要性，指出了常见误区和避免策略。需求获取不仅是技术问题，更是沟通艺术，掌握本节内容将帮助考生打好需求工程基础，为后续的软件设计和开发奠定坚实基础。