原试题
- 结构化分析需求有哪些步骤？
- 需求变更有哪些步骤？
- 找出示例案件中存在的哪些问题。
- 如果你是像案例中的项目经理，遇到了这些问题，你会怎么去做？
- 还有软考部分的知识，比如软件网络层、数据链路层的作用。
- 软件中项目管理的内容。
- 需求分析里面的5W2H是指什么？
- 需求分析的原则是什么？
思考
以下为针对产品经理笔试的专业答卷，结合行业方法论和实战经验系统化作答：
1. 结构化分析需求的步骤
- 需求收集：用户访谈、问卷、竞品分析、业务文档梳理
- 需求分类：功能性需求（如登录功能）、非功能性需求（如响应速度≤1s）
- 需求建模：
- 数据流图（DFD）：描述信息流动
- 实体关系图（ERD）：定义数据对象关系
- 状态转换图：系统状态变化逻辑
- 需求规格化：编写SRS文档（含用例、用户故事）
- 需求验证：原型测试、需求评审会、Traceability Matrix（追溯矩阵）确保无遗漏
关键工具：用例图（角色-功能-交互）、流程图（业务逻辑可视化）
2. 需求变更管理流程
需求变更需严格遵循变更控制流程，降低项目风险：
- 变更申请
提交正式变更请求（Change Request），描述变更背景、影响范围及预期收益。 - 影响评估
分析对进度、成本、质量、资源的影响，评估技术可行性及与其他需求的关联性。 - 变更审批
由变更控制委员会（CCB）或项目负责人决策是否批准，明确变更范围及优先级。 - 变更实施
调整设计文档、开发计划及测试用例，同步更新需求跟踪矩阵。 - 变更验证与交付
通过回归测试、用户验收确保变更正确性，记录变更日志并通知相关方。
核心原则：所有变更必须书面化、通过CCB决策、同步更新基线文档
3. 案例问题诊断（假设案例描述为：需求频繁变更、开发延期、用户投诉）
- 需求模糊 ：未明确用户角色与核心场景，导致功能偏离业务实际。
- 沟通断裂 ：开发团队与业务方缺乏协同，需求传递失真。
- 变更失控 ：频繁需求变更未评估影响，引发进度延误与成本超支。
- 缺乏验证 ：未通过原型或测试用例验证需求，上线后出现严重缺陷。
- 文档缺失 ：需求文档未更新，导致团队依赖口头沟通，信息不对称。
4. 问题解决策略
- 建立需求基线
明确需求优先级，冻结核心功能，通过迭代开发逐步实现次要需求。 - 强化沟通机制
每周召开跨部门站会，使用协作工具（如Notion、Trello）同步进展；关键需求由BA撰写用户故事并组织评审。 - 引入变更控制流程
设立CCB，强制要求所有变更提交书面申请并评估影响，拒绝“口头变更”。 - 分阶段验证需求
设计阶段输出高保真原型供用户确认，开发阶段采用自动化测试覆盖核心流程。 - 知识管理
每日更新Wiki文档，记录决策过程与需求变更记录，确保信息透明可追溯。
5. 网络分层核心功能
| 层级 | 核心作用 | 协议/设备示例 |
|---|---|---|
| 数据链路层 | 相邻节点帧传输、MAC寻址、差错检测 | 交换机、MAC地址 |
| 网络层 | 端到端路由选择、IP寻址、拥塞控制 | 路由器、IP协议 |
关键区别：数据链路层解决“同一局域网内如何送”，网络层解决“跨网络如何送”
6. 软件项目管理核心内容
- 范围管理：WBS分解、需求跟踪矩阵，定义项目边界，防止范围蔓延。
- 进度管理：制定甘特图、关键路径分析，跟踪里程碑。
- 成本管理：预算规划、资源分配与成本控制。
- 风险管理：风险登记册（概率/影响矩阵）
- 质量保障：测试用例覆盖率≥90%、代码Review
- 干系人管理：权力利益矩阵定制沟通策略
- **沟通管理 ** ：定期同步进展，确保干系人知情权。
敏捷重点：通过Burndown Chart监控迭代健康度
7. 需求分析中的5W2H
| 维度 | 含义 | 示例问题 |
|---|---|---|
| Why | 为什么需要此功能？业务价值或用户动机？ | “用户为何需要一键分享功能？” |
| What | 需求是什么？目标功能或问题本质？ | “分享支持哪些平台？” |
| Who | 涉及哪些用户角色？利益相关方？ | “由谁操作分享？普通用户or管理员？” |
| When | 使用场景/触发时机 | “用户在哪个环节触发分享？” |
| Where | 使用场景或环境是什么？ | “功能入口在详情页还是个人中心？” |
| How | 如何实现？技术方案或流程步骤？ | “通过API调用还是本地生成？” |
| How Much | 成本、资源投入及优先级？ | “支持同时多少人分享？响应时间？” |
8. 需求分析七大原则
- 价值导向：每个需求需关联业务目标（如提升转化率5%）
- 用户中心原则 ：以用户场景为核心，避免主观臆断。
- 可验证性：需求必须可测试（例：“搜索结果加载≤2s”）
- 一致性：与系统架构/业务规则无冲突
- 优先级量化：MoSCoW法则（Must/Should/Could/Won’t）
- 避免镀金：拒绝无核心价值的“锦上添花”需求
- 干系人共识：所有方签字确认需求基线
- 渐进细化 ：从高阶需求（Epic）逐步拆解为用户故事（User Story）。