扫码获取 VIP 码
添加管理员微信获取 VIP 码
需求工程是软件工程生命周期中最早也是最重要的阶段。IEEE定义需求为系统必须满足的条件或具备的能力，通常源于用户解决实际问题的需要。需求工程的正式定义为：系统地使用经过验证的技术和方法进行需求获取、分析、规格说明、验证和管理的全过程。
在系统分析师考试的知识体系中，需求工程横跨结构化分析和面向对象分析两大方法论，是案例分析题和论文写作的高频命题方向。统计历年真题，需求工程相关试题在下午卷中的权重稳定在百分之十五到百分之二十五之间，掌握这一模块对考试通过至关重要。
需求工程的最终交付物是软件需求规格说明书，这份文档不仅是开发团队和用户之间的合同性文件，也是后续设计、编码、测试和验收的唯一依据。IEEE 830标准将一份合格的SRS特征概括为正确性、无歧义性、完整性、一致性、可验证性、可修改性和可追踪性七个维度，每个维度本身就是选择题的高频考点。
需求工程的五个子过程构成闭环：需求获取从利益相关者收集原始需求，需求分析将原始需求转化为结构化的分析模型，需求规格说明将分析模型文档化为正式SRS，需求验证确认需求质量，需求管理贯穿全生命周期提供变更控制和追溯能力。五个子过程并非严格的线性顺序，存在大量迭代和回溯——当验证发现缺陷时可能回退到获取阶段补充信息，当管理拒绝变更时必须回溯到分析阶段重新评估影响。
需求获取的核心任务是从利益相关者那里收集、发现和提取系统需求。利益相关者不仅包括直接使用系统的最终用户，还包括出资方、运维团队、监管机构和上下游接口系统的负责人。系统分析师必须识别全部利益相关者类别，遗漏任何一类都可能导致需求不完整并引发后续返工。
常用需求获取技术包括访谈、问卷调查、联合需求计划工作坊、观察法、原型法和文档分析法，每种技术各有适用场景和局限。访谈适合深度挖掘单个用户的业务逻辑和痛点，分为结构化访谈和非结构化访谈两种形式。结构化访谈使用预设问卷逐项提问，确保不同受访者回答具有可比性。非结构化访谈以开放性问题引导用户自由表述，适合项目初期探索未知业务领域。访谈局限在于成本高且信息易被个别用户观点误导，通常需结合其他技术交叉验证。问卷调查适合快速覆盖大量用户获取统计性需求分布，问题设计质量直接决定数据有效性。封闭式问题适合收集量化数据如使用频率和功能排序，开放式问题适合收集质化信息如业务痛点。局限在于无法追问细节且用户对问题的理解偏差无法及时纠正。
观察法分为被动观察和主动参与两种模式。被动观察指分析师在不干扰用户工作的前提下记录操作流程，适用于现有业务流程文档化。主动参与要求分析师亲自执行用户任务，从实践中理解隐性需求——用户认为理所当然而不会口头表达的知识。原型法通过构建可运行的简化版本来激发和澄清需求。抛弃型原型快速构建后用于需求验证随即丢弃，演化型原型从核心功能开始迭代最终演化为正式系统的首个版本。原型法特别适用于用户难以预先描述需求的创新型系统和交互密集型系统。
需求获取阶段的输出物是原始需求列表，允许以自然语言描述且允许冲突、模糊和重叠。系统分析师的核心纪律是忠实记录而非提前判断和过滤——过早筛选可能遗漏关键需求。
需求分析阶段将原始需求列表转化为结构化的分析模型，核心任务是消除冲突、消除模糊、消除冗余，并通过建模验证需求的完整性和一致性。结构化分析方法使用数据流图、实体关系图和数据字典三种工具建模，面向对象分析方法使用用例图、类图和序列图等UML工具。两种范式选择取决于项目特征——数据处理密集的系统适合结构化建模，业务逻辑复杂且需求变更频繁的系统适合面向对象建模。
需求分类是分析工作的起点。功能需求描述系统必须执行的行为，如用户登录验证、订单生成、报表导出。非功能需求描述系统的质量属性约束，包括性能指标如响应时间不大于两秒和并发用户数不低于五百、安全等级如敏感数据加密存储和等保三级合规、可用性指标如全年停机不超过五小时和故障恢复时间小于三十分钟。非功能需求经常被分析师忽略或描述过于笼统——例如写出"系统应具有良好的性能"而非"并发两百用户时查询响应不超过三秒"——考试中这类笼统表述会被明确扣分。
需求优先级排序是分析阶段的关键决策点。MoSCoW方法将需求分为四类：必须有需求是系统底线功能缺失则项目失败，应该有需求是重要但非致命的功能在资源约束时可暂缓，可以有需求是锦上添花的功能在时间和预算允许时实现，不会有需求是本次版本不实现但可纳入后续规划的功能。Kano模型从用户满意度维度将需求分为基本型、期望型和兴奋型：基本型需求满足时用户不觉得好但不满足时用户极度不满，期望型需求的满意度与实现程度成正比，兴奋型需求未被满足时用户不察觉但被满足时用户惊喜。两种排序方法互补使用——MoSCoW提供项目管理视角，Kano模型提供用户体验视角。
结构化分析建模以数据流图为核心，采用自上而下逐层分解策略。顶层上下文图定义系统边界和外部实体，零层图展开核心数据处理，底层图细化到基本加工单元。数据字典为每个数据流和数据存储提供精确定义，包括名称、类型、取值范围和业务含义。实体关系图描述数据之间的逻辑关系及基数约束和参与度模式。
面向对象分析建模以用例驱动为核心。用例图从参与者视角描述系统功能边界，每个用例代表系统为参与者提供的一项完整服务。用例规约以结构化文本描述前置条件、基本事件流、备选事件流和后置条件，是连接需求与设计的关键文档。领域类图识别问题域中的核心概念及概念之间的关联、聚合、泛化关系，不涉及编程语言和数据库表结构等实现细节。序列图描述用例执行过程中对象间的消息交互顺序，用于验证用例规约的正确性。
考试中两种范式的对比是综合题高频方向。结构化建模以处理为中心强调数据流转变换，适合数据密集型和流程稳定型系统。面向对象建模以数据为中心强调对象行为和协作，适合业务复杂且变更频繁的系统。案例分析中除非试题明确要求两种方法结合使用，否则不应混用两种范式的建模工具。
需求规格说明将分析模型转化为结构化文档，要求分析师从建模思维切换为写作思维。分析模型中的图示和数据需在SRS中以自然语言精确表述，任何建模阶段未显式化的隐含假设必须在写作阶段被揭示和确认。
SRS文档组织通常遵循IEEE 830标准的三段式框架。引言部分描述文档目的、产品范围、术语定义和参考文献。总体描述部分概述产品功能、用户特征、约束条件和假设依赖。详细需求部分是文档核心，按功能模块或用户类别组织需求条目，每条分配唯一标识号以便全生命周期精确追溯。
需求条目编号体系是SRS质量的基础。合格的需求条目必须包含唯一编号和需求描述两个要素，推荐补充来源说明和验证方法。需求描述应使用主动语态以"系统应"开头，避免使用"可能""大概""通常""适当""必要"等模糊词汇。每条需求只陈述一个事实，不应包含复合句。例如"系统应支持用户注册并在注册后自动发送确认邮件"应拆分为两条独立需求，因为注册和邮件发送的实现团队与验证方式可能不同。
完整性检查验证是否覆盖所有利益相关者需求、是否定义所有输入数据来源和格式、是否规定所有输出数据的接收者和时效。完整性不等于面面俱到，而是确保需求集合覆盖系统全部功能边界和质量属性维度，不遗漏任何一类利益相关者的核心诉求。
一致性检查验证不同需求条目间是否存在逻辑矛盾。典
本篇完！