需求,这真的是“需求”吗?——论需求的层次及若干问题(1)

本文分析了需求沟通中的失真问题,通过一幅漫画揭示了从客户到开发人员的需求传递过程中可能出现的理解偏差。定义了软件需求的三层含义,并探讨了业务需求、用户需求和功能需求的层次。同时,指出了常见的需求风险,如用户参与不足、需求不断增加、模棱两可的需求和不必要的功能等,并强调了需求评审的重要性和避免“画蛇添足”的原则。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 需求的漫画:

       关于需求问题,有一幅漫画十分生动地展现了这些问题(这幅漫画我其实最早是在07年一次“敏捷中国”一次软件开发技术人员日上上见到的),如果我们认真剖析后面的东西,还是会给我们的工作带来许多启发的:

需求失真漫画

      究其原因,这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真,从客户的描述到项目经理的理解、分析员分析并文档化、程序员的编码、商业顾问的诠释,每个角色都根据自己的特点和需求对信息进行了不同的加工(想当然的去理解和发挥)。

      看了这幅漫画之后,我在思考一个问题,也就是需求工作是不是可以成为一项规范化的动作,而使得没有个需求分析员在进行分析之后都是一样的结果?在需求从客户到开发人员、测试人员如何做到不失真?如果能做到,我可以该怎么做?

      我们首先定义下,什么是软件需求:

      在定义需求的时候,我们发现需求其实也是分对象的,分层次的!

 

      一、软件需求及其层次

     1、软件需求的定义:

     IEEE 软件工程标准词汇表( 1 9 9 7 年)中定义软件需求为:
    (1)用户解决问题或达到目标所需的条件或能力( C a p a b i l i t y)。
    (

### 需求分析与需求管理的概念 需求分析是指开发团队通过详细的调查研究来理解并定义用户对于系统的期望和要求,确保这些非正式的需求能够被转换成精确的技术规格说明书。这一阶段的目标在于明确系统应该具备哪些特性以及如何运作[^1]。 需求管理则是指在整个项目生命周期内管理和控制需求变更的过程。它涉及记录初始需求、跟踪变化请求、评估影响,并维护最新的需求文档版本。有效的需求数量有助于确保最终产品满足用户的实际需要并且可以减少后期修改带来的风险。 ### 流程概述 #### 需求获取 此环节旨在收集来自不同利益相关者的输入信息,包括但不限于客户访谈、问卷调查、观察工作环境等方式获得原始资料。这一步骤至关重要因为它直接影响后续工作的准确性。 #### 分析建模 一旦获得了足够的数据之后,则进入到了更深层次理解——即构建模型以描述所要解决的问题域。这里会涉及到创建业务流程图、实体关系图表等多种可视化工具帮助澄清复杂的关系结构[^2]。 #### 文档编写 当所有的细节都被充分讨论并通过验证后,下一步就是撰写详尽的需求文档。这份文件不仅包含了功能性需求(如界面布局),还包括非功能性约束条件比如性能指标等重要参数设定。 #### 审查确认 最后,在提交给开发者之前还需要经过严格的评审会议来进行质量保证活动;邀请所有相关人员参与其中共同审查每一条陈述是否合理可行直至达成一致意见为止。 ### 方法论介绍 针对不同的应用场景可以选择合适的方法学: - **结构化分析法**:这是一种基于逻辑推理的传统方式,强调自顶向下逐步细化的原则。其核心思想是把复杂的整体分解成为若干相对独立又相互关联的部分加以处理。 - **面向对象分析法**:随着面向对象编程范式的兴起而发展起来的新一代技术路线。该方法侧重于识别现实世界中的事物作为类的对象实例看待,进而围绕着它们之间的交互行为展开设计思考。 ```python class RequirementManagementSystem: def __init__(self, requirements): self.requirements = requirements def track_changes(self, change_request): pass def evaluate_impact(self, proposed_change): pass ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值