认识达内从这里开始

随着互联网的不断发展，越来越多的人都在学习计算机编程开发技术，而今天我们就一起来了解一下，软件开发需求实践所面临的问题都有哪些。

需求完整性需要诸多用户的参与和确认，而且用户间需求本身也存在冲突的可能，因此需求更加强调角色和场景和划分，一个所有用户需要都能够满足的需求往往不是一个好需求。

需求过程缺乏用户的参与，我们往往是技术驱动，习惯性的跳到模块的划分导致需求本身验证困难，也导致了需求间耦合很紧，很难在后期组织有效的迭代开发。因此要考虑按流程和业务梳理需求。

需求无法实现也可能不是架构问题，而是需求本身不切实际。

用户想要和真正需要是有区别的，没有真正的识别需求优先级可能导致需求过量开发和需求镀金。

需求优先级识别往往并不能完全依靠用户，用户往往只会把自己关注功能讲优先级识别的很高，因此需求优先级识别应该是通过业务规则，流程和模式来确定。优先级识别方法(离主营业务的远近，发生的频率两个方面来度量)

沟通失真，要认识到文档仅仅是中介而不是全部，要通过即时的验证来减少沟通失真。

需求捕获和调研常见问题-用户告诉你的是他转化后的解决方案，而不是原始的需求。

变更频繁，但是要响应变化，比如通过对变更分类来识别哪些变更是可以通过复用和可配置解决的。

非功能性需求为有效的识别，仅仅是定性，而没有通过定性->场景->定量的路线。

需求分析的核心线索

在原有的需求分析方法中，我们往往过多的关注How，而没有关注What，或者关注了What而没有关注What背后的需求场景和背后的问题Why。这都导致我们没有进行很好的需求挖掘。需求分为业务需求，用户需求和软件需求三个层面。而我们在平时的需求分析中往往很容易直接跳到了软件需求阶段，而忽视了业务需求和业务建模。

业务需求=目标+范围

目标的表达必须包括目标+优势+度量+合理+可行，或者说SMART原则。同时在目标表达上可以考虑场景法，即问题是什么-》影响谁-》后果是什么-》解决方案优点是什么?

范围表达的两个重要方面是人和物，人包括干系人和终用户;物包括业务事件和管理控制点。

需求定义输出业务需求;需求捕获输出用户需求;需求分析输出软件需求。需求分析的本质动作就是分解，抽象和消除歧义。而对于需求分析的本质线索则是人，事(流程)，物(数据)和接口。因此需求分析不能完全等同于建模型。分析是本质，建模仅仅是手段。

需求捕获

需求捕获是一个不断的探索过程。在需求捕获中，沟通占40%，业务占30%，技术占30%。而对于沟通往往讲究的并不是单纯的技巧，而更多的是一种思维模式和顺序的问题。在这里老师引入了思维模式的话题，也通过一个案例讲解了沟通中顺序的重要性，如先将解决方案再讲具体场景和问题(类似于我上个ppt里面强调的结构化思维的一个重要原则即开门见山的逐层展开)。在沟通中讲了三个可以借鉴的方法。

未知问题->已知问题

相对重要->相当次要(创造一种比较的环境给用户)

关注点的转换->(沟通也要洞察心理学)

隐喻(将了一个用汉字的赢字来表达项目管理核心)

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。