谈需求和设计

标签: IT项目管理 | 发表时间:2013-08-10 22:54 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题?如果边界不清楚则很难明确的区分。对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模。而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计。

需求的重点是描述清楚现实世界,而设计的重点则是将现实世界的需求转换为抽象的模型。这是我们说的需求和设计的大边界,但是需求里面也不是简单的需求定义和挖掘的问题,还涉及到业务建模,业务建模和架构总体可以说是衔接需求和设计的重要内容。

在面向对象的需求分析方法中,用例建模涉及到的内容包括了业务流程,业务活动和操作,异常和边界,业务规则,业务对象模型,模块和接口等各个方面的内容,也是我们常采用的系统需求定义和编写的方法。即需求重点还是定义清楚问题,而不是管具体的实现方式。在对用例建模的方法基础上,往往再加入了界面原型和通用的UI/UE规范约束等各方面的内容,以进一步的细化需求。即我们将需求更进一步,从最初的需求用例增加了界面原型建模,到基于界面原型的界面操作和业务交互操作建模。

对于传统的需求和设计边界,往往即只做到系统用例层面,而让设计和实现有更多的发挥空间。在这种场景下最容易发生的问题就是在出现偏差的时候很难真正去界定究竟是需求的问题还设计的问题。在定义需求的时候,我们强调每一个需求条目本身的完整性和可验证性,但是这本身并不代表需求本身的粒度就合适,如果说一个需求最终去追踪设计的时候,发现大量的1对多的映射关系,那么可以讲需求本身的粒度和细化程度出了大问题,对于这种粗粒度的需求最终业务系统实现为什么样子我们也很难把控。

需求本身也是渐进明细和迭代的过程,为了进一步界定需求和设计的关系,可以讲任何不设计到设计层面建模的内容的都纳入到需求范围,设计建模包括了数据库设计,核心的类设计和对象模块,模块间交互和接口设计,具体一个业务功能的更详细类交互设计等。这些很明细是抽象层面的内容,那么除掉这些内容都可以作为是需求需要去考虑的内容。一个界面上的布局,控件的选择和交互,操作的易用性全部纳入到需求范围,这些的定义不涉及到具体的实现层面的类和代码逻辑,也是一种合理的方式。需求可以渐进明细并逐步精化,但是要意识到需求必须要管到这个层面,做需求的人时刻要考虑到按你需求做完的东西真正是客户想要的东西,需求分析和开发人员必须要对最终的交付负责,而设计开发人员则更多的是为需求的实现负责而已。

需求和设计可以有边界,但是更加重要的是需求和设计之间的衔接问题,任何只懂业务或只懂技术的人往往都很难真正做好这块的内容,而这块内容往往正是传统的系统分析员的核心价值。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [需求 设计] 推荐:

谈需求和设计

- - 人月神话的BLOG
在这里再谈下需求和设计的边界问题,我们最终的业务系统实现出现的偏差,究竟是需求的问题还是设计的问题. 如果边界不清楚则很难明确的区分. 对于需求本身有原始需求,用户需求,产品需求和系统需求的各种阶段;而对于需求的过程也本身存在原始需求的收集,需求分析,需求挖掘,和需求相关的业务建模. 而对于设计同样存在总体的企业架构设计,到单个应用的总体设计和架构设计,概要设计和详细设计.

需求如何进行敏捷设计

- - 互联网的那点事
本文作者 @朱军华Ronzhu 敏捷开发其实不光光要求开发层面和测试层面的敏捷,其实对需求设计层面也是要敏捷的,这样才能配合后续的开发和测试,使之真正的敏捷起来. 我们可以通过在实际操作过程当中在需求层面进行敏捷设计的分析来了解需求的敏捷设计. 大多数情况下需求的处理过程都可以分为需求分析和需求设计两部分,前者要将业务需求转化成产品需求,后者要将产品需求转化为产品设计,也即成品的PRD.

交互探讨:以用户场景和产品需求导向的设计

- - 互联网的那点事
在对设计师而言,对自己设计最重要的就是深刻理解产品需求,深入考虑用户是如何使用产品,. 作为交互设计师,我觉得有几个发展阶段:. 初入这个领域,大部份人可能更多精力放在如何使用工具、如何画线框图、如何将想法变为实际可见的Demo;. 再往下一个阶段的设计师,可能会考虑线框图怎样做得更加合理、怎样可以有更棒的交互效果、关注任务流程和信息结构的设计以及可用性原则;.

SaaS+PaaS | 产品设计,如何满足用户个性化需求

- - 人人都是产品经理
在设计To B产品的时候,因为客户的行业,规模体量,商业模式以及内部管理流程的不同,同样的一个需求在不同的公司可能需要不同的解决方案. 所以,在产品的设计上,如何能以灵活的方式在同一个应用体系上满足不同客户的个性化需求,成了To B产品经理的必修课. 本文将基于SaaS+PaaS平台的产品设计,重点解决如何让产品满足客户个性化需求的问题.

扫盲 HTTPS 和 SSL/TLS 协议[1]:背景知识、协议的需求、设计的难点

- - 细节的力量
★HTTPS 协议的需求是啥. ★设计 HTTPS 协议的主要难点.   要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义. 大致了解 HTTP 和 TCP 的关系(尤其是“短连接”VS“长连接”). 大致了解加密算法的概念(尤其是“对称加密与非对称加密”的区别).

再谈需求

- - 人月神话的BLOG
谈需求工程方面的文章前面写过很多,本文仅做最近思考的一些点滴记录. 首先我们谈下业务建模层面,对于从用户提出最初的业务需求到交付一个完整的系统,在建模层面涉及到两个层面的抽象,其一就是业务建模解决现实世界本身的抽象描述,其二就是软件架构设计,解决从业务模型到IT架构模型的第二次转换. 在早些时候我们看到这两个层面的建模内容都由系统分析员承担或完成,在岗位不断细分后我们看到反而会出现忽视了业务建模的问题.

需求变化与IoC

- - 酷壳 - CoolShell.cn
【感谢 Todd投递本文 – 微博帐号:@ weidagang 】. 程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫. 可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀. ”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了.

进化而来的需求

- - 极客公园-GeekPark
[核心提示]需求是可以创造,可以进化的. 在需求的“博尔赫斯库”中,我们要做的,仅仅是模拟规则,让需求,优胜劣汰. 如果本文的标题和导语引起了坐在电脑前的你的兴趣,同时又产生了些许的疑惑,那么恭喜我自己,我的目的达到了 (真是恶趣味……). 那么,在对它们进行解释之前,还容我卖个关子,先从几个有趣的见闻讲起.

解决方案与需求

- - 扯氮集--上海魏武挥的博客 - 扯氮集--上海魏武挥的博客
曾经有一个很有名的段子,大致意思就是说在汽车尚未出现的马车时代,你去做消费者调研,只会得到这样的答案:我需要一匹更快的马,而不会得到:我需要汽车. 因为对于消费者来说,他从来没有看到过汽车,怎么可能回答你需要汽车呢. 这个段子,似乎充分说明了,创新,尤其是颠覆式创新、破坏性创新是不可能通过需求调研出来的.

如何做需求分析

- - 人人都是产品经理
这段时间我做了两个大项目,其中一个项目算是商业模式上和使用规范上的调整,另一个项目是之前功能的重做,为什么重做我下面会说到. 关于需求分析,我认为把需求抽象成产品功能花费的时间占到了软件开发周期的40%,产品设计到评审完的时间大概是20%,也就是说实际开发之前产品团队介入的工作占据项目的60%,在需求分析阶段我有一些个人观点.