扫码阅读
手机扫码阅读
漫谈需求与设计的区别:做什么与怎么做

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

需求与设计的界线摘要
本文通过两个日常生活例子,阐述了需求与设计的区别和联系,并展开了对概要描述和详细描述的分层次讨论。
案例一:DIY一台PC
- 做什么:需求是DIY一台PC,包含显示器、键盘、主板等配件,特定硬盘和内存规格。
- 怎么做:设计涉及采购、组装、监测和软件安装等步骤,以及每个步骤的具体细节,例如选择品牌、供应商,安装CPU和内存,连接显示器等。
案例二:从北京到天津
- 做什么:需求是一家三口从北京西单到天津劝业场,3小时内到达。
- 怎么做:设计包括选择出行方法、出城、上下高速等步骤,及其决策指标如时长、成本、交通风险,并具体化到自驾的详细过程。
在这两个案例中,"做什么"代表需求,是站在责任者以外的角度看待的目标或结果。而"怎么做"代表设计,从责任者的角度出发,描述实现结果的方法和步骤。设计有多种可能性,而不是唯一解决方案。
需求和设计都可以进行分层描述,既有概要描述也有详细描述。需求的概要描述指向宏观的目标和结果,即客户需求,而详细描述则指向目标的具体化和交付物的特性,即产品需求。设计的概要描述偏向技术方法选择和接口设计,详细描述则涉及每个组件的内部实现。
需求与设计是相对的,详细设计的"怎么做"在更高层次上可以视为"做什么"。在提出需求时,可能会包含一部分设计内容,因为提出需求的人可能对设计有所了解。
想要了解更多内容?


麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 241.7K
麦哲思科技任甲林的其他文章
决策与解决方案练习结果分析
2008年3月4日对15人进行了DAR过程域的培训,针对一个设计方案选择的场景进行练习。划分为3个小组,每组5人。练习持续45分钟,点评45分钟。第1组练习的结果:评价指标权重方案1方案2方案3开发时间3321系统收益3
对软件开发过程可重复性的思考
硬件的生产过程是可重复的。因为对产品功能、质量的要求是相同的、生产设备是相同的,生产流程也是相同的,硬件的生产力来自于设备,因此硬件的生产可以要求生产能力又准又稳,要求生产系统可以持续地生产出满足需求的产品。而每个软件项目的需求是不同的、人员的经验与数量是不同的、开发方法与开发过程是不同的、外部干扰的频次是不同的,软件的生产力来自于人,因而软件过程满足需求的能力相对于硬件的生产过程是偏弱的。人操作硬件,硬件生产产品,人对生产质量有影响,但更重要的是硬件。需求是原材料,是抽象的,每个项目的原材料是不同的。
何谓根本原因?
最后一个可控原因就是根因!何谓可控原因?即在原因分析的责任主体内可以改变的因素就是可控原因,反之责任主体无法改变的因素就是不可控因素,不可控因素应该做为原因分析的外部条件,前提条件。
白话SCRUM 之二:product backlog
在SCRUM方法中明确要求了3个文档: 1 product backlog 2 sprint backlog 3 burn-down chart Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲
为什么必须首先做规模估计?
这个问题客户问过我,我也解答过多次,但是我一直没有更直接的理由说服我自己,认为必须先做规模估计再做工作量估计。 比如:对维护类的项目,或者是维护类的活动,为什么要估计规模呢?项目组的人没有技术风险,对需求很熟悉。 我总结了如下的理由: (1) 以规模来估计工作量与成本 (2) 规模估计与实现的人与技术无关,比较客观 (3) 可以度量项目的开发效率:规模/工作量 (4)
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线